<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Sep 8, 2015 at 10:10 AM, Michal Antkiewicz <span dir="ltr"><<a href="mailto:mantkiew@gsd.uwaterloo.ca" target="_blank">mantkiew@gsd.uwaterloo.ca</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">+1 for the change but not for an extension. Here's why<div><br></div><div>5. The only reason to guard changes behind LANGUAGE pragmas should be when they are causing problems with other extensions.</div></div></blockquote><div> </div><div>There is a massive downside to this view. It only permits monotonic progress in one direction. If we later learn about a better thing we could have done, you can never really retract it.</div><div><br></div><div>There are a lot of historically proposed extensions that 'don't break anything' that you've never heard of that subtly conflict with other extensions that 'don't break anything'.</div><div><br></div><div>Trex-records, half a dozen layout rule variants, I don't know how to resolve both naked existential types in UHC and type families in GHC...</div><div><br></div><div>Each of these chip away at some innocuous corner of our syntax or semantics, but in aggregate they'd leave us no room to grow, and no ability to know if we'd written portable, standards compliant, code.</div><div><br></div><div>The LANGUAGE pragma is an annoying tax, but I think the long term benefits in terms of readability of new extensions makes it worth it. Look at languages like C++ and what horrible things they have to call everything to avoid conflicting with every random historical idea baked into the standard. Let's not go down that road. </div><div><br></div><div>You can always amortize the cost of those LANGUAGE pragmas by embedding them in the extensions field of your cabal file if you feel they must be on at all times in the code you write -- and since the ones you are interested in are 'just extensions that don't break anything' this causes you no pain when reading other people's code as they just don't use your favorite extension.</div><div><br></div><div>-Edward</div><div><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 class="gmail_extra">Best,<br clear="all"><div><div><div dir="ltr"><div>Michał </div></div></div></div>
<br><div class="gmail_quote"><span class="">On Tue, Sep 8, 2015 at 12:56 AM, Andrew Gibiansky <span dir="ltr"><<a href="mailto:andrew.gibiansky@gmail.com" target="_blank">andrew.gibiansky@gmail.com</a>></span> wrote:<br></span><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">In order to get a feel for  using this extension in real-world Haskell, take a look at the new ghc-reskin package:<div><br></div><div><a href="https://github.com/gibiansky/ghc-reskin" target="_blank">https://github.com/gibiansky/ghc-reskin</a><br></div><div><br></div><div>This allows you to use ArgumentBlock *today* by passing GHC a few parameters to tell it to use ghc-reskin as a preprocessor. Take a look at the README for a full example.</div><div><br></div><div>-- Andrew</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 7, 2015 at 9:02 PM, Bardur Arantsson <span dir="ltr"><<a href="mailto:spam@scientician.net" target="_blank">spam@scientician.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><span>On 09/08/2015 03:08 AM, Dan Burton wrote:<br>
> +1 people who like it can use it and people who don't like it don't have to<br></span>
> use it. Personally I wish it were the default because the superfluous $<br>
> confuses a lot of people coming from other languages like Ruby.<br>
><br>
<br>
</span>Whether it's "superfluous" depends entirely on one's PoV.<br>
<span><br>
> You can even write in the old style if you have the extension turned on. It<br>
> doesn't disable the old way of doing things. It just allows a new way. It's<br>
> entirely backwards compatible with working code when turned on, is it not?<br>
><br>
<br>
</span>Except now there are two "dialects" everybody has to read/understand.<br>
That's not progress IMO. (Considering that it's so little gain. I really<br>
don't understand the hatred of $ that some people seem to have.)<br>
<br>
Regards,<span><br>
<div><div><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>
</div></div></span></blockquote></div><br></div>
<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></div></div><br></div></div>
<br>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">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></div>