I worry that this thread is turning into a bit of bike shed before we have
a good sense of what construction tools we have on hand!
One side consideration we might want to keep in mind is what spaces of
parser tech can work off the shelf in various juxtapositions of code and
features.
The more context sensitive a grammar is, the more humans Pay too!
I've certainly seen agressive amounts of tuple sections in industrial code.
Another meta question / challenge that this thread has posed is : given
Haskell as it is today / will be in the future, is there a meaningfully
better language tuned diff tool that could exist ?
On Saturday, May 7, 2016, Kosyrev Serge <_deepf...@feelingofgreen.ru> wrote:
> Bardur Arantsson <s...@scientician.net <javascript:;>> writes:
> > Actually, thinking about it a little further... TupleSections is already
> > opt-in, so this needn't conflict per se.
>
> Isn't this dangerous, in how it now gives a trivial piece of code
> two very different interpretations, in a plausibly unintentional way?
>
> > {-# LANGUAGE TupleSections #-}
> > (x, y, ) :: t -> (a, b, t)
>
> > {-# LANGUAGE LaxCommas #-}
> > (x, y, ) :: (a, b)
>
> I understand that we have OverloadedStrings, viz:
>
> > {-# LANGUAGE NoOverloadedStrings #-}
> > "a" :: [Char]
>
> > {-# LANGUAGE OverloadedStrings #-}
> > "a" :: IsString a => a
>
> and yet, the differences in this respect seems significant:
>
> The unintentionality of change in interpretation effected by the
> transition NoOverloadedStrings -> OverloadedStrings is implausible.
>
> Whereas with the LaxCommas -> TupleSections transition I guess it would
> be fair to say that it is plausible.
>
> Moreover, OverloadedStrings doesn't disallow using string literals as
> string literals, whereas LaxCommas and TupleSections are mutually
> exclusive.
>
> --
> с уважениeм / respectfully,
> Косырев Сергей
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime@haskell.org <javascript:;>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
