# Difference between revisions of "Nitpicks"

From HaskellWiki

(scheme-like identifiers) |
(→Base-related nitpicks) |
||

Line 28: | Line 28: | ||

* 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. Also, <hask>fromIntegral</hask> is useful for some types where the full complement of numeric operators aren'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. |
||

+ | * <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. |

## Revision as of 23:23, 30 August 2015

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.

- 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. - 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`

.

- 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.