What makes
f do{x} do{y}
any harder to read than similar record syntax?
f Foo{foo=3} Foo{foo=4}
On Thu, Jul 7, 2016 at 1:15 PM, Carter Schonwald
<carter.schonw...@gmail.com> wrote:
> agreed -1,
> ambiguity is bad for humans, not just parsers.
>
> perhaps most damningly,
>>
>>
>> f do{ x } do { y }
>
>
> is just reallly really weird/confusing to me, and as the proposal itself
> says at the end as the cons:
>
>
>> 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.
>
> which kinda kills any benefit in my mind. thats a HUGE complexity vs
> alternative ratio. I'm all in favor of doing engineering work to *improve*
> our parser error messages and suggestions, but not stuff that complicates
> parsing for humans as well as machines
>
>
> On Wed, Jul 6, 2016 at 9:50 PM, Evan Laforge <qdun...@gmail.com> wrote:
>>
>> On Wed, Jul 6, 2016 at 10:39 AM, Bardur Arantsson <s...@scientician.net>
>> wrote:
>> > On 07/04/2016 12:31 PM, Akio Takano wrote:
>> >> Hi glasgow-haskell-users,
>> >>
>> >> I have written a wiki page about a proposed extension called
>> >> ArgumentDo. It's a small syntactic extension that allows "do"
>> >> expressions, lambdas and a few other kinds of expressions to be used
>> >> as function arguments, without parentheses.
>> >>
>> >> https://ghc.haskell.org/trac/ghc/wiki/ArgumentDo
>> >>
>> >> Any feedback is appreciated. In particular, since the idea has
>> >> received mixed support (see the "Discussion" section on the wiki
>> >> page), I'd like to make sure that there is enough support for this
>> >> feature to justify an implementation in GHC.
>> >>
>> >
>> > -1
>> >
>> > Reasons have already been given in previous threads on this. However,
>> > I'd point especially to the fact that people don't *agree* that this is
>> > more readable as a very strong point against -- regardless of whether
>> > any one individual thinks it's more readable or not. The point is the
>> > there seems to be a lot of disagreement -- that indicates to me that
>> > this cannot by definition be a "clear win"[1]. Disclosure: I personally
>> > find it less readable because of the implicitness. Implicitness which
>> > has a non-trivial probability of affecting semantics is bad in my book.
>> > Frankly, if it came to it, I'd rather just remove $ and deal with the
>> > parentheses.
>>
>> I'm -1 because I think there are already too many styles. So I don't
>> agree with the general sentiment that the parser should accept lots of
>> stuff and to rely on style guides to specify something, because in
>> practice everyone has their own style guide.
>>
>> I trained myself to see juxtaposition as highest precedence (which
>> newcomers still struggle over) and it's confusing to see juxtaposition
>> that has higher precedence because one of them is a keyword. In the
>> same way I'm confused by 'f a { b = c }', but it's too late to change
>> that one. I suppose this is already on the wiki page in the "cons"
>> section.
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
