
So, it looks like this extension is quite controversial. To summarize the
main points raised in this discussion:
Pro: (+9)
- It's easier to read than the alternative.
- This extension removes syntactic noise.
- This makes basic do-syntax more approachable to newbies; it is a
commonly asked question as to why the $ is necessary.
- This simplifies the resulting AST, potentially making it simpler for
editors and other tools to do refactoring.
- It's something that belongs in the main language, and if its
something we'd consider for a mythical Haskell', it has to start as an
extension.
- It gets rid of some cases where using $ doesn't work because $
interacts with other infix operators being used in the same expression.
- This would make do blocks consistent with record creation, where
parentheses are skipped, allowing things such as "return R { x = y}"
- This does not change the meaning of any old programs, only allows new
ones that were previously forbidden.
- This gets rid of the need for a specially-typed $ allowing "runSt $
do ..."
Con: (-9)
- It's harder to read than the alternative.
- Creating a language extension to get rid of a single character is
overkill and unnecessary.
- You can already get rid of the $ by just adding parentheses.
- More and more syntactic "improvements" just fragment the language.
- Although this is consistent with record syntax, record syntax without
parents was a mistake originally.
Questions:
- Why doesn't this apply to case, let, if, etc?
- Should this apply to case, let, if, etc?
I would say people on /r/haskell and haskell-cafe seem fairly evenly split,
perhaps somewhat favoring *not* including this extension.
1. How representative are the opinions expressed through these media of the
general Haskell community? (If one exists...)
2. What, historically, has been the GHC policy on including
questionable/controversial extensions?
3. We do have another option: with the advent of ghc-exactprint, we could
probably write a preprocessor that emulates this extension, parsing as if
ArgumentDo is enabled and then inserting a $ where necessary. This would
allow us to test out this extension without modifying GHC and thus being
stuck with the extension in mainline GHC indefinitely (since, as I
understand it, there's not really a process for *removing* extensions from
GHC).
On Mon, Sep 7, 2015 at 5:10 AM, Joachim Breitner
Hi,
Am Sonntag, den 06.09.2015, 11:28 -0700 schrieb Andrew Gibiansky:
3. It does make some cases cleaner. Consider the following code: [1, 2, 3] ++ concat (do { .... }). This can be written with parentheses, bit it cannot be written with $, because [1, 2, 3] ++ concat $ do { .... } would parse as ([1, 2, 3] ++ concat) $ do { ... }. This is sometimes annoying behaviour. (I used the list monad here just for demo purposes. I find it is more common with applicative operators.)
good point! This has bitten me before.
I believe that the language would be better with the proposed syntax change being the default. So the way forward is to indeed add this extension, see how people use it, and if Haskell' ever goes somewhere, it might include this as the default – all alike to DoAndIfThenElse.
Also note that this does not change the meaning of any existing program, AFAIK. So it is not that you might be reading existing code wrongly if you are not aware that this extension is being used; you will just find code that looks like invalid syntax to you – until you check the list of extensions (or just deduce that ArgumentBlock is used here).
Therefore, +1 from me.
Greetings, Joachim
-- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe