Nitpicks

From HaskellWiki
Revision as of 16:01, 4 September 2015 by Cblp (talk | contribs) (Syntax-related nitpicks: style)

Jump to: navigation, search


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.

Syntax-related nitpicks

  example1 = do
     params <- loadParams
      letrequest = buildRequest params
     response <- remoteCall request
      letJust theValue = responseValueMay response
      return theValue
  example2 = do
     params <- loadParams
     request = buildRequest params
     response <- remoteCall request
     Just theValue = responseValueMay response
      return theValue

Syntactic-sugar related nitpicks

  • 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

Semantics-related nitpicks

Base-related nitpicks