# Difference between revisions of "Nitpicks"

From HaskellWiki

(→Syntax-related nitpicks) |
m (Reference for "do"-notation nitpick added) |
||

(28 intermediate revisions by 7 users not shown) | |||

Line 17: | Line 17: | ||

* Replace the special if-then-else syntax with a standard prelude function. See https://wiki.haskell.org/If-then-else . | * Replace the special if-then-else syntax with a standard prelude function. See https://wiki.haskell.org/If-then-else . | ||

* Introduce a newtype/data with the symbol <hask>::=</hask> instead of <hask>=</hask>, as this is confusing with the equal sign. See https://mail.haskell.org/pipermail/haskell-cafe/2015-August/120724.html | * Introduce a newtype/data with the symbol <hask>::=</hask> instead of <hask>=</hask>, as this is confusing with the equal sign. See https://mail.haskell.org/pipermail/haskell-cafe/2015-August/120724.html | ||

− | * A type should be introduced with the symbol <hask>:</hask> instead of <hask>::</hask> as in many other languages and mathematical papers. Conversely <hask>::</hask> should be used as the cons operator. | + | * A type should be introduced with the symbol <hask>:</hask> instead of <hask>::</hask> as in many other languages and mathematical papers. Conversely <hask>::</hask> should be used as the cons operator. See https://neilmitchell.blogspot.com/2018/11/counting-cost-of-colons-in-haskell.html |

* The kind for inhabited types <hask>*</hask> is not an operator. See https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase1#ishardtoparse | * The kind for inhabited types <hask>*</hask> is not an operator. See https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase1#ishardtoparse | ||

* <hask>default</hask> is a useful name for a variable, but it's taken up as a keyword for the rarely used defaulting declaration. DefaultSignatures adds a more useful use though. | * <hask>default</hask> is a useful name for a variable, but it's taken up as a keyword for the rarely used defaulting declaration. DefaultSignatures adds a more useful use though. | ||

+ | * Allow hyphenated (à la scheme) identifiers like <hask>example-identifier</hask>, which some of us prefer to <hask>uglyCamelCase</hask>. | ||

+ | * Make <hask>let</hask> keyword optional in <hask>do</hask> blocks for visual clarity, unifying the two kinds of variable bindings — pure (<hask>let ... =</hask>) and monadic (<hask><-</hask>), decreasing syntactic noise, decreasing nested code depth. Compare: | ||

+ | {| | ||

+ | |<haskell> | ||

+ | example = do | ||

+ | ╎params <- loadParams | ||

+ | let╎request = buildRequest params | ||

+ | & fixRequest | ||

+ | ╎response <- remoteCall request | ||

+ | let╎Just theValue = responseValueMay response | ||

+ | ╎return theValue | ||

+ | </haskell> | ||

+ | |<haskell> | ||

+ | example = do | ||

+ | ╎params <- loadParams | ||

+ | ╎request = buildRequest params | ||

+ | & fixRequest | ||

+ | ╎response <- remoteCall request | ||

+ | ╎Just theValue = responseValueMay response | ||

+ | ╎return theValue | ||

+ | </haskell> | ||

+ | |} | ||

+ | : See https://mail.haskell.org/pipermail/haskell-cafe/2012-August/102741.html | ||

+ | * Add "monad extraction" operator (I used a "!" one, because it's present in Idris ). Often you don't care in which order monad values are "extracted", and you just want to use their values in parameters to function-call or <hask>return</hask>. Compare: | ||

+ | :* "do" syntax | ||

+ | <haskell> | ||

+ | do params <- loadParams | ||

+ | time <- getCurrentTime | ||

+ | user <- getCurrentUser | ||

+ | getExampleData params time user | ||

+ | </haskell> | ||

+ | :* monad extraction | ||

+ | <haskell> | ||

+ | getExampleData !loadParams !getCurrentTime !getCurrentUser | ||

+ | </haskell> | ||

+ | :* Applicative lift | ||

+ | <haskell> | ||

+ | bind3 getExampleData loadParams getCurrentTime getCurrentUser | ||

+ | where bind3 f x y z = join (liftA3 f x y z) | ||

+ | </haskell> | ||

+ | : See https://mail.haskell.org/pipermail/haskell-cafe/2014-May/114287.html | ||

+ | * Change <code>do</code>-notation to more closely resemble list-comprehensions: | ||

+ | :<haskell> | ||

+ | do info | params <- loadParams, | ||

+ | time <- getCurrentTime, | ||

+ | user <- getCurrentUser, | ||

+ | info <- getExampleData params time user | ||

+ | </haskell> | ||

+ | :See <i>Use more existing sugar</i> in [[Do notation considered harmful]]. | ||

+ | |||

+ | == Syntactic-sugar related nitpicks == | ||

+ | |||

+ | * It is not possible to create non-recursive bindings in do-blocks. Some syntactic sugar, say, an "assignment arrow" <code>foo <-= modify foo</code> which desugars to <code>foo' (modify foo) where foo' foo = ...</code>, would solve this problem, and can be used instead of <code>let</code>. The primary motivation for this is that it is currently not possible to "mutate" bindings in do-blocks, for example - <code>let foo = modify foo</code> would be interpreted as a recursive definition instead. So we have to invent new variable names to refer to the mutated values (suffixing (') being the most common), and since the old binding is still in scope there is no way to ensure that the old value will not be accidentally used, causing bugs. A universal non-recursive <code>let</code> would also solve this problem but it has its own issues, and is a much bigger change to the language. Some relevant discussion here - http://permalink.gmane.org/gmane.comp.lang.haskell.cafe/117846 | ||

== Semantics-related nitpicks == | == Semantics-related nitpicks == | ||

Line 26: | Line 79: | ||

* Re-naming <hask>fmap</hask> to <hask>map</hask>. This has been discussed at length; see http://stackoverflow.com/questions/6824255/whats-the-point-of-map-in-haskell-when-there-is-fmap/6824333 and https://mail.haskell.org/pipermail/haskell-prime/2006-August/thread.html | * Re-naming <hask>fmap</hask> to <hask>map</hask>. This has been discussed at length; see http://stackoverflow.com/questions/6824255/whats-the-point-of-map-in-haskell-when-there-is-fmap/6824333 and https://mail.haskell.org/pipermail/haskell-prime/2006-August/thread.html | ||

− | * Cutting up <hask>Num</hask>, which is a mess of various operations one may not want to all define on some type; for example <hask>(+)</hask> makes sense for vectors in ℝ³ but <hask>(*)</hask> doesn't. | + | * Cutting up <hask>Num</hask>, which is a mess of various operations one may not want to all define on some type; for example <hask>(+)</hask> makes sense for vectors in ℝ³ but <hask>(*)</hask> doesn't. Also, <hask>fromIntegral</hask> is useful for some types where the full complement of numeric operators aren't. |

+ | :* ...or just drop type classes altogether and use e.g. System CT [https://homepages.dcc.ufmg.br/~camarao/CT/ :] for top-level definitions by default and use annotations elsewhere, like polymorphic let-expressions [https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.187.9508 :]. An account of a more modest implementation is also available (see chapter 7)[http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.628.7053 :]. | ||

+ | * <hask>Data.List.nub</hask> and other "Set" operations should be restricted to <hask>Ord</hask> not <hask>Eq</hask> in order to reduce their complexity. It is very unlikely for anyone to create a datatype that can support <hask>Eq</hask> but not <hask>Ord</hask>. <hask>Data.Set</hask> in the "container" package assumes <hask>Ord</hask> as well. | ||

+ | * Partial functions like <hask>head</hask> and <hask>tail</hask> in Prelude. The problem is in their partiality. | ||

+ | * The proliferation of questions, guides, tutorials, lessons, introductions '''et al''' about the topic indicates that I/O being both ''abstract'' and ''monadic'' is at best pedagogically dubious. Instead, I/O should be defined more directly in standard Haskell: | ||

+ | <haskell> | ||

+ | -- this is merely a suggestion... | ||

+ | -- | ||

+ | type IO# a = (a -> IOCall#) -> IOCall# | ||

+ | data IOCall# -- abstract | ||

+ | </haskell> | ||

+ | :which allows beginners to acquire a better understanding of how I/O works - the monadic abstraction can then be taught later in an intermediate or advanced course. |

## Latest revision as of 01:16, 27 September 2021

This page is for people to record nitpicks about the Haskell language.

A "nitpick", in this case, is something that is annoying or could be improved, but is probably not important enough to justify the added complexity of tacking it on as an extension or breaking existing code.

In other words, if we could go back in time and fix it before it happened, we probably would, but now it would probably be too onerous.

Ideally, these nitpicks could help to inform future proposals or compatibility-breaking changes to the language. Even if they may be too onerous to change right now, it's possible that it would make sense to address them at some other time.

If the nitpick has been discussed at length, please post a link to the discussion.

## Contents

- Re-naming
`data`

,`newtype`

, and`type`

to`type`

,`newtype`

, and`alias`

, respectively. See https://mail.haskell.org/pipermail/haskell-cafe/2015-August/120724.html . - Replace the special if-then-else syntax with a standard prelude function. See https://wiki.haskell.org/If-then-else .
- Introduce a newtype/data with the symbol
`::=`

instead of`=`

, as this is confusing with the equal sign. See https://mail.haskell.org/pipermail/haskell-cafe/2015-August/120724.html - A type should be introduced with the symbol
`:`

instead of`::`

as in many other languages and mathematical papers. Conversely`::`

should be used as the cons operator. See https://neilmitchell.blogspot.com/2018/11/counting-cost-of-colons-in-haskell.html - The kind for inhabited types
`*`

is not an operator. See https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase1#ishardtoparse `default`

is a useful name for a variable, but it's taken up as a keyword for the rarely used defaulting declaration. DefaultSignatures adds a more useful use though.- Allow hyphenated (à la scheme) identifiers like
`example-identifier`

, which some of us prefer to`uglyCamelCase`

. - Make
`let`

keyword optional in`do`

blocks for visual clarity, unifying the two kinds of variable bindings — pure (`let ... =`

) and monadic (`<-`

), decreasing syntactic noise, decreasing nested code depth. Compare:

```
example = do
╎params <- loadParams
let╎request = buildRequest params
& fixRequest
╎response <- remoteCall request
let╎Just theValue = responseValueMay response
╎return theValue
``` |
```
example = do
╎params <- loadParams
╎request = buildRequest params
& fixRequest
╎response <- remoteCall request
╎Just theValue = responseValueMay response
╎return theValue
``` |

- Add "monad extraction" operator (I used a "!" one, because it's present in Idris ). Often you don't care in which order monad values are "extracted", and you just want to use their values in parameters to function-call or
`return`

. Compare:

- "do" syntax

```
do params <- loadParams
time <- getCurrentTime
user <- getCurrentUser
getExampleData params time user
```

- monad extraction

```
getExampleData !loadParams !getCurrentTime !getCurrentUser
```

- Applicative lift

```
bind3 getExampleData loadParams getCurrentTime getCurrentUser
where bind3 f x y z = join (liftA3 f x y z)
```

- Change
`do`

-notation to more closely resemble list-comprehensions:

do info | params <- loadParams, time <- getCurrentTime, user <- getCurrentUser, info <- getExampleData params time user

- See
*Use more existing sugar*in Do notation considered harmful.

- It is not possible to create non-recursive bindings in do-blocks. Some syntactic sugar, say, an "assignment arrow"
`foo <-= modify foo`

which desugars to`foo' (modify foo) where foo' foo = ...`

, would solve this problem, and can be used instead of`let`

. The primary motivation for this is that it is currently not possible to "mutate" bindings in do-blocks, for example -`let foo = modify foo`

would be interpreted as a recursive definition instead. So we have to invent new variable names to refer to the mutated values (suffixing (') being the most common), and since the old binding is still in scope there is no way to ensure that the old value will not be accidentally used, causing bugs. A universal non-recursive`let`

would also solve this problem but it has its own issues, and is a much bigger change to the language. Some relevant discussion here - http://permalink.gmane.org/gmane.comp.lang.haskell.cafe/117846

- Re-naming
`fmap`

to`map`

. This has been discussed at length; see http://stackoverflow.com/questions/6824255/whats-the-point-of-map-in-haskell-when-there-is-fmap/6824333 and https://mail.haskell.org/pipermail/haskell-prime/2006-August/thread.html - Cutting up
`Num`

, which is a mess of various operations one may not want to all define on some type; for example`(+)`

makes sense for vectors in ℝ³ but`(*)`

doesn't. Also,`fromIntegral`

is useful for some types where the full complement of numeric operators aren't.

`Data.List.nub`

and other "Set" operations should be restricted to`Ord`

not`Eq`

in order to reduce their complexity. It is very unlikely for anyone to create a datatype that can support`Eq`

but not`Ord`

.`Data.Set`

in the "container" package assumes`Ord`

as well.- Partial functions like
`head`

and`tail`

in Prelude. The problem is in their partiality. - The proliferation of questions, guides, tutorials, lessons, introductions
**et al**about the topic indicates that I/O being both*abstract*and*monadic*is at best pedagogically dubious. Instead, I/O should be defined more directly in standard Haskell:

```
-- this is merely a suggestion...
--
type IO# a = (a -> IOCall#) -> IOCall#
data IOCall# -- abstract
```

- which allows beginners to acquire a better understanding of how I/O works - the monadic abstraction can then be taught later in an intermediate or advanced course.