<div dir="ltr">the fact that its perilously close to looking like <b>1 typo</b> away from a parser error about record syntax makes me <div><b>-1000</b> now</div><div><br></div><div>thanks for pointing this out! </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 7, 2016 at 1:32 PM, Brandon Allbery <span dir="ltr"><<a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Didn't they already say they disliked record syntax for exactly that reason?</div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Thu, Jul 7, 2016 at 1:23 PM, David Feuer <span dir="ltr"><<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What makes<br>
<span><br>
f do{x} do{y}<br>
<br>
</span>any harder to read than similar record syntax?<br>
<br>
f Foo{foo=3} Foo{foo=4}<br>
<div><div><br>
On Thu, Jul 7, 2016 at 1:15 PM, Carter Schonwald<br>
<<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>> wrote:<br>
> agreed -1,<br>
> ambiguity is bad for humans, not just parsers.<br>
><br>
> perhaps most damningly,<br>
>><br>
>><br>
>> f do{ x } do { y }<br>
><br>
><br>
> is just reallly really weird/confusing to me, and as the proposal itself<br>
> says at the end as the cons:<br>
><br>
><br>
>> It's harder to read than the alternative.<br>
>><br>
>> Creating a language extension to get rid of a single character is overkill<br>
>> and unnecessary.<br>
>><br>
>> You can already get rid of the $ by just adding parentheses.<br>
><br>
> which kinda kills any benefit in my mind. thats a HUGE complexity vs<br>
> alternative ratio. I'm all in favor of doing engineering work to *improve*<br>
> our parser error messages and suggestions, but not stuff that complicates<br>
> parsing for humans  as well as machines<br>
><br>
><br>
> On Wed, Jul 6, 2016 at 9:50 PM, Evan Laforge <<a href="mailto:qdunkan@gmail.com" target="_blank">qdunkan@gmail.com</a>> wrote:<br>
>><br>
>> On Wed, Jul 6, 2016 at 10:39 AM, Bardur Arantsson <<a href="mailto:spam@scientician.net" target="_blank">spam@scientician.net</a>><br>
>> wrote:<br>
>> > On 07/04/2016 12:31 PM, Akio Takano wrote:<br>
>> >> Hi glasgow-haskell-users,<br>
>> >><br>
>> >> I have written a wiki page about a proposed extension called<br>
>> >> ArgumentDo. It's a small syntactic extension that allows "do"<br>
>> >> expressions, lambdas and a few other kinds of expressions to be used<br>
>> >> as function arguments, without parentheses.<br>
>> >><br>
>> >> <a href="https://ghc.haskell.org/trac/ghc/wiki/ArgumentDo" rel="noreferrer" target="_blank">https://ghc.haskell.org/trac/ghc/wiki/ArgumentDo</a><br>
>> >><br>
>> >> Any feedback is appreciated. In particular, since the idea has<br>
>> >> received mixed support (see the "Discussion" section on the wiki<br>
>> >> page), I'd like to make sure that there is enough support for this<br>
>> >> feature to justify an implementation in GHC.<br>
>> >><br>
>> ><br>
>> > -1<br>
>> ><br>
>> > Reasons have already been given in previous threads on this. However,<br>
>> > I'd point especially to the fact that people don't *agree* that this is<br>
>> > more readable as a very strong point against -- regardless of whether<br>
>> > any one individual thinks it's more readable or not. The point is the<br>
>> > there seems to be a lot of disagreement -- that indicates to me that<br>
>> > this cannot by definition be a "clear win"[1]. Disclosure: I personally<br>
>> > find it less readable because of the implicitness. Implicitness which<br>
>> > has a non-trivial probability of affecting semantics is bad in my book.<br>
>> > Frankly, if it came to it, I'd rather just remove $ and deal with the<br>
>> > parentheses.<br>
>><br>
>> I'm -1 because I think there are already too many styles.  So I don't<br>
>> agree with the general sentiment that the parser should accept lots of<br>
>> stuff and to rely on style guides to specify something, because in<br>
>> practice everyone has their own style guide.<br>
>><br>
>> I trained myself to see juxtaposition as highest precedence (which<br>
>> newcomers still struggle over) and it's confusing to see juxtaposition<br>
>> that has higher precedence because one of them is a keyword.  In the<br>
>> same way I'm confused by 'f a { b = c }', but it's too late to change<br>
>> that one.  I suppose this is already on the wiki page in the "cons"<br>
>> section.<br>
>> _______________________________________________<br>
>> Glasgow-haskell-users mailing list<br>
>> <a href="mailto:Glasgow-haskell-users@haskell.org" target="_blank">Glasgow-haskell-users@haskell.org</a><br>
>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Glasgow-haskell-users mailing list<br>
> <a href="mailto:Glasgow-haskell-users@haskell.org" target="_blank">Glasgow-haskell-users@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users</a><br>
><br>
_______________________________________________<br>
Glasgow-haskell-users mailing list<br>
<a href="mailto:Glasgow-haskell-users@haskell.org" target="_blank">Glasgow-haskell-users@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div data-smartmail="gmail_signature"><div dir="ltr"><div>brandon s allbery kf8nh                               sine nomine associates</div><div><a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a>                                  <a href="mailto:ballbery@sinenomine.net" target="_blank">ballbery@sinenomine.net</a></div><div>unix, openafs, kerberos, infrastructure, xmonad        <a href="http://sinenomine.net" target="_blank">http://sinenomine.net</a></div></div></div>
</font></span></div>
</blockquote></div><br></div>