<br><br>On Saturday, May 7, 2016, Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com">carter.schonwald@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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!<div><br></div><div>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.  </div><div><br></div><div>The more context sensitive a grammar is, the more humans Pay too! </div><div><br></div><div>I've certainly seen agressive amounts of tuple sections in industrial code.  </div><div><br></div><div>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 ?<span></span><br><br><br><br>On Saturday, May 7, 2016, Kosyrev Serge <_<a href="javascript:_e(%7B%7D,'cvml','deepfire@feelingofgreen.ru');" target="_blank">deepfire@feelingofgreen.ru</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Bardur Arantsson <<a>spam@scientician.net</a>> writes:<br>
> Actually, thinking about it a little further... TupleSections is already<br>
> opt-in, so this needn't conflict per se.<br>
<br>
Isn't this dangerous, in how it now gives a trivial piece of code<br>
two very different interpretations, in a plausibly unintentional way?<br>
<br>
> {-# LANGUAGE TupleSections #-}<br>
> (x, y, ) :: t -> (a, b, t)<br>
<br>
> {-# LANGUAGE LaxCommas #-}<br>
> (x, y, ) :: (a, b)<br>
<br>
I understand that we have OverloadedStrings, viz:<br>
<br>
> {-# LANGUAGE NoOverloadedStrings #-}<br>
> "a" :: [Char]<br>
<br>
> {-# LANGUAGE OverloadedStrings #-}<br>
> "a" :: IsString a => a<br>
<br>
and yet, the differences in this respect seems significant:<br>
<br>
The unintentionality of change in interpretation effected by the<br>
transition NoOverloadedStrings -> OverloadedStrings is implausible.<br>
<br>
Whereas with the LaxCommas -> TupleSections transition I guess it would<br>
be fair to say that it is plausible.<br>
<br>
Moreover, OverloadedStrings doesn't disallow using string literals as<br>
string literals, whereas LaxCommas and TupleSections are mutually<br>
exclusive.<br>
<br>
--<br>
с уважениeм / respectfully,<br>
Косырев Сергей<br>
_______________________________________________<br>
Haskell-prime mailing list<br>
<a>Haskell-prime@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime</a><br>
</blockquote></div></blockquote><div><br></div><div><br></div><div><br></div><div>My bad for forgetting to reply below rather than above :)</div><div><br></div><div>Tla+ does have leading AND style syntax in the style of the  what is being discussed here, but that was done from the outset.  </div><div><br></div><div>Either way, experiments in syntax and semantics are best grounded in ... Running experiments using them!  Certainly some parts of what we hope to achieve need to be grounded thusly, even if it's not changing the type system or the syntax of the core substrate.  Let's do some experimental research and see what happens in the wild, in codes natural habitats! 🕵🎉<span></span></div><div><br></div><div><br></div><div> </div>