Proposal: ArgumentDo

Sven Panne svenpanne at gmail.com
Fri Jul 8 06:35:18 UTC 2016


[ There is a trend to repeat one's argument about this proposed extension
in various mailing lists/wiki pages/etc., so let's repeat myself, too... :-]

2016-07-07 19:44 GMT+02:00 Carter Schonwald <carter.schonwald at gmail.com>:

> the fact that its perilously close to looking like *1 typo* away from a
> parser error about record syntax makes me
> *-1000* now [...]
>

-1000 for exactly the same reason, and more: If you look at the "Block as a
LHS" section on the wiki, things get insame IMHO:

   do f &&& g
   x

should mean "(f &&& g) x"? It's probably 99% more likely that somebody
didn't get the indentation right for the "do". And what about:

   foobar
      do f &&& g
      x

Should the x now be an argument of foobar (as it is currently) or the "do"?
If it is not an argument of the "do", suddenly things get very
context-dependent. Computers are good at handling context-dependent things,
humans are quite bad at it.

Taking one step back: I think a lot of the discussion is based on the false
assumption that "something can be parsed in an unambiguous way by some more
or less random parsing technology" means "it can easily be parsed by a
human". This is a fundamental misconception, otherwise reading programs in
Brainfuck or Whitespace would be easy, too. In our case at hand, visually
determining what is an argument of a function in a quick way is *supported*
by some (perhaps) redundant syntactic stuff. That's exactly the reason why
the current record syntax is a big mistake: Normally, an argument is
beginning after a whitespace (unless there are other syntactic clues like
'$', '(', etc.), but

   foo bar { baz = blah }

runs against this intuition and one has to mentally backtrack. The proposal
at hand would enshrine this kind of broken syntax in more places. As has
already been said in another thread, the goal of language design is not to
make writing correct programs easier (by allowing more and more syntax),
but to make writing wrong programs harder.

And a note about counting votes: I think normal democrating voting
procedures simply don't apply here. Even if e.g. 80% of the voters find
something OK while the other 20% find it confusing, the majority vote
doesn't make the confusion of a fifth of the people go away. For a change
like this, I would expect near unanimous consent, but I think we are very,
very far away from that...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20160708/168604ee/attachment.html>


More information about the Glasgow-haskell-users mailing list