<div dir="ltr">I'm coming from a less-informed background than most people, but isn't the fact that we need parentheses in the first place a bit odd?<br><br> If Haskell's grammar went something like expression := (literal+) | doBlock, wouldn't the presence of the `do` keyword be enough for the parser to acknowledge the presence of a do block, and use the curly brackets inserted by the indent parser step to denote where the expression ends? In that case , it seems like that would solve the need for the $ issue, and make the parser simpler...<div><br></div><div> Apologies if this is what's actually happening in this extension, but most people against this extension seem to say that it adds complexity. Could someone point out how things end up being more complex?</div><div><span style="font-size:13.2px;line-height:1.5"> </span></div><div><span style="font-size:13.2px;line-height:1.5"> My impression is that in the current state there's a difference in treatment between a do block and other expressions that is more complex than it should be.</span><br></div><div><span style="font-size:13.2px;line-height:1.5"><br></span></div><div><span style="font-size:13.2px;line-height:1.5"><br></span></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Sep 7, 2015 at 8:44 AM Tikhon Jelvis <<a href="mailto:tikhon@jelv.is">tikhon@jelv.is</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div>+1 from me. At a high level, one of the things that attracts me to Haskell over other languages is that it's willing to change and improve at a faster rate (although, in absolute terms, it's still pretty slow and concerned about backwards compatibility). Assuming a tweak makes sense, rolling it out as an extension and then folding it into the language (maybe as part of the mythical Haskell 2020 standard :)) is perfect. DoAndIfThenElse is a reasonable point of comparison and seems to be a good deal.<br><br></div>And I *do* think this tweak makes sense. The new behavior is more inline with my expectations. I feel that do and lambdas are self-contained expressions and inherently group their contents together; needing an extra set of parentheses or a $ does not make sense. A good way to think about it is that I see do as having braces semantically even when they're syntactically optional. I think most people would agree that requiring parentheses aroud<br><br></div> foo (do { x; y; z })<br></div><br></div>is redundant and not useful.<br><br></div>However, I would feel even better if this applied evenly to *all* syntactic elements that worked this way including case expressions. Were they left out just to make the proposal simpler? If you could change the grammar to support this for all the relevant syntactic constructions and it worked reasonably well, I would be significantly more enthusiastic about it. That would feel like a significant simplification of the syntax.<br><br></div>Also, it's worth noting that, as somebody pointed out in the Reddit thread, this extension would make the impredicativity magic around $ less necessary, which feels like a pointer that it *is* a simpler design.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Sep 6, 2015 at 3:08 PM, Francesco Ariis <span dir="ltr"><<a href="mailto:fa-ml@ariis.it" target="_blank">fa-ml@ariis.it</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Sun, Sep 06, 2015 at 02:33:28PM -0430, Manuel Gómez wrote:<br>
> It seems to me that lately the community’s visible attitude has<br>
> shifted toward a heightened value of stability and uniformity for<br>
> Haskell and its software ecosystem, and experimentation, fragmentation<br>
> and diversity in styles and dialects are now viewed as threatening.<br>
> This drives us to reject the process of gradual improvement that has<br>
> made Haskell great over the years. Other similarly purely syntactic<br>
> extensions seem to me to have been met with less resistance in the<br>
> past. It appears we’re now far more concerned with the pursuit of<br>
> success.<br>
><br>
> +1<br>
<br>
</span>Hello Manuel,<br>
your post made me clearly realise why I am sometimes unhappy about<br>
syntactic extensions, so I'll take advantage of this discussion to<br>
illustrate my point.<br>
<br>
I don't recall the exact details, but a few months ago I was writing a<br>
small patch for a Haskell project I liked. Datatypes were simple, e.g.:<br>
<br>
data SomeData = SomeData {<br>
somedataName :: String<br>
, somedataVersion :: Int<br>
, somedataSynopsis :: Maybe String<br>
, somedataDescription :: Maybe String<br>
, somedataHomepage :: Maybe String<br>
, somedataBugReports :: Maybe String<br>
-- etc, etc.<br>
<br>
In the where part of the (long) top level function, I found an<br>
expression similar to this:<br>
<br>
-- there was no type sig there<br>
alfa = ("version", somedataVersion)<br>
<br>
A tuple with a String and an accessor `SomeData -> Int`, ok.<br>
Somewhere else this pops out:<br>
<br>
let beta = 7 + snd alfa<br>
<br>
What? For sure something is wrong, this program shouldn't compile! It<br>
should be:<br>
<br>
let beta = 7 + (snd alfa) myData<br>
<br>
I fired ghci, loaded the project and it turns out I was right and ghc wrong!<br>
<br>
λ> :t ("s", somedataVersion)<br>
("s", somedataVersion) :: (String , SomeData -> Int)<br>
<br>
What was happening? A conspicuous bug in ghc (which was exploited in<br>
a weird way by the project developer)? Hallucinations? Not really!<br>
It turns out that in the top of the file, which looked like:<br>
<br>
{-# LANGUAGE CPP #-}<br>
{-# LANGUAGE OverloadedStrings #-}<br>
{-# LANGUAGE QuasiQuotes #-}<br>
{-# LANGUAGE RecordWildCards #-}<br>
{-# LANGUAGE ViewPatterns #-}<br>
<br>
I missed the `RecordWildCards` extension. RecordWildCards allows these<br>
kind of patterns:<br>
<br>
f (C {a = 1, ..}) = b + c + d<br>
-- shame on me for not checking extensions first!<br>
<br>
This long introduction to make my point :P<br>
<span><br>
> It seems to me that lately the community’s visible attitude has<br>
> shifted toward a heightened value of stability and uniformity for<br>
> Haskell and its software ecosystem, and experimentation, fragmentation<br>
> and diversity in styles and dialects are now viewed as threatening.<br>
> This drives us to reject the process of gradual improvement that has<br>
> made Haskell great over the years.<br>
<br>
</span>Even though they aren't as 'dangerous' as other well known extensions,<br>
5 small syntactic extensions potentially create 31 dialects which will<br>
make me trip in many different ways. One of the reason I like Haskell is<br>
because it's a joy to read other people's code (unlike other languages<br>
where I don't even try, so daunting is the challenge).<br>
<br>
I think it is healthy to have a thorough discussion for each one of the<br>
proposed extensions and most importantly study what we are trying to<br>
accomplish and see if there is a way to reach the same goal(s) with a<br>
smaller set of orthogonal changes.<br>
And yes, to err on the conservative side and say 'no' if the benefit<br>
isn't worth the additional fragmentation.<br>
<br>
I understand the fact that Haskell is meant to be an always evolving<br>
language: this is awesome and I like it. I like it even more when<br>
the community goes forward *together*! [1]<br>
<br>
<br>
Sorry for the long rant (phew, it took more words than necessary)!<br>
As written above, your message cleared my mind so I decided to share my<br>
thoughts, maybe they can be helpful to the discussion.<br>
<br>
<br>
[1] be it a Standard like H2010, a well thought out migration-path<br>
for changes like BPP, a stricter and curated selection for<br>
extensions, etc.<br>
<br>
<br>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
<br></blockquote></div><br></div>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
</blockquote></div></div>