
Haskell ArgumentDo Proposal - adamnemecek
https://ghc.haskell.org/trac/ghc/wiki/ArgumentDo
======
chriswarbo
Hmm, this doesn't sit well with me.

    
    
        atomically do
          v <- readTVar tv
          writeTVar tv $! v + 1
    
        withForeignPtr fptr \ptr -> c_memcpy buf ptr size
    

Since whitespace is used for function application "f x", code like this would
require mental effort on my part to realise that, for example,
"withForeignPointer" isn't being called with 7 arguments.

I really don't see why so much effort is spent on infix syntax, precedence
rules, fully-applied "$", etc. (not to mention the associated bikeshedding),
all to remove the requirement of a few parentheses.

Whilst I can perhaps entertain the notion that Lisp-style, fully-parenthesised
syntax might annoy some people (personally I find it quite pleasing), I think
this level of syntax-fiddling is a solution worse than the problem.

Keeping track of precedence rules is the kind of task computers are good at
but humans not so much; I don't know why we invent these schemes to impose on
ourselves, when we could just wrap a couple of parens around the tricky bits.
(In fact, I do this; but hlint tells me off!)

~~~
chadaustin
People spend time on this because Haskell syntax is deeply unpleasant to a lot
of people, including myself. I love the capabilities and expressiveness of
Haskell, but I find the syntax annoying, and it hasn't gotten better even
coming on three years of active Haskell programming.

I've forgotten the $ in some usage of do or a final argument lambda twice in
the last week even.

I think it's worth solving these (superficial?) syntax issues even if they
only affect the comfort of a third of all Haskell programmers.

~~~
cfallin
I wonder if anyone is working on a full rework of Haskell's syntax, a la
Facebook's Reason for OCaml? I'm a big fan of the semantics but not as much
the syntax of Haskell, too, and it would be interesting to see what a more...
current-day-mainstream... syntax (Rust-like braces-and-semicolons-expression-
based-language style, perhaps) would do for it.

~~~
DanWaterworth
This is what I'm doing with plastic [1], though it also has some semantic
differences: strict instead of lazy, monads become objects.

[1]
[https://github.com/DanielWaterworth/plastic](https://github.com/DanielWaterworth/plastic)

~~~
taylorfausak
That doesn't compile to Haskell.

~~~
DanWaterworth
I'm surprised that you expected it to.

edit: Having looked at Reason more closely, I now see where the confusion came
from. Sorry, I didn't mean to deceive you.

------
thinkpad20
I'm curious as to what the author means when discussing whether the extension
makes the language "more regular". I thought regularity of languages was a
binary thing; either a language is or isn't regular. And since all languages
with recursive grammars are not regular (if I'm correct in that statement),
why does it matter?

Regarding this particular extension it seems more or less fine to me; I'm not
sure if it's really worth the effort just to remove a single character
(usually) but it doesn't seem like a bad thing overall. I think the resulting
syntax would be quite familiar to ruby programmers and could make it easier
for newcomers to grok the syntax.

~~~
tikhonj
Regular as in "uniform", not as in "regular expression". The question is
whether this extension conceptually feels like adding an edge case to the
syntax or removing one. Does it make the syntax simpler over all?

~~~
wyager
That's what I thought too, but if you read the page they're talking about the
number of nonterminal symbols in the same sentence...

~~~
tikhonj
That's a decent measure of how complex a grammar is. It also highly hints that
the language in question is at least context-free: you probably wouldn't use
the word "nonterminal" to describe a regular language. (Unless you were
specifying a language that happened to be regular as a context-free grammar, I
suppose.)

------
dmix
> Cons

> 2\. Contributes to a proliferation of extensions that other tools must
> support. (NB: This is just a parser change so should be easy for all tools
> to support.)

In Haskell are libraries isolated in the sense that 3rd-party libraries can
have their own language extensions without affecting other programs that
import them? Or does it get pushed up the chain to all code using it?

Or is this "con" just related to syntax when using other libraries APIs or
some GHC versioning dependency risk.

~~~
gizmo686
Language extensions are generally enabled on a per file basis. This complaint
seems to be talking about tools for working with Haskell source code (such as
an IDE). If these tools try to work with a file that has this extension
enabled, then it has to be aware of what effect this extension will have, or
else it may mis-parse the file.

As an example, here is the first example config file for XMonad [0]. Note the
"LANGUAGE" pragma, which enables a number of extensions for this file.

[0]
[https://wiki.haskell.org/Xmonad/Config_archive/adamvo%27s_xm...](https://wiki.haskell.org/Xmonad/Config_archive/adamvo%27s_xmonad.hs)

~~~
dmix
Makes sense, thanks. There are so many extensions where I could see this
adding a lot of overhead for tooling.

Still, I love the experimental nature of the language which this promotes. A
worthy tradeoff given Haskell is typically an experience developers language
who (should) know how to handle such responsibility.

