Codifying language extensions in Report
Carter Schonwald
carter.schonwald at gmail.com
Sat Aug 20 03:33:16 UTC 2016
Or more strongly : language extensions explicitly articulating which fancy
features are enabled in a given module makes code more reason-able!
And has made evolving code styles much easier to learn
I still remember when having a toplevel -fglasgow-extensions was a thing,
and I personally only started to understand various fancy techniques after
the tools / features used In a given module had to be explicitly
enumerated.
Phrased differently: i agree with Richard
-Carter
On Friday, August 19, 2016, Richard Eisenberg <rae at cs.brynmawr.edu> wrote:
> I personally think this should be in scope. And indeed the Haskell 2010
> Report does codify several extensions in Section 12.3.
>
> Richard
>
> > On Aug 19, 2016, at 9:57 PM, M Farkas-Dyck <m.farkasdyck at gmail.com
> <javascript:;>> wrote:
> >
> > Is this in scope? I.e. a conformant Haskell implementation must allow
> > the extension, but using it remains optional.
> > _______________________________________________
> > Haskell-prime mailing list
> > Haskell-prime at haskell.org <javascript:;>
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org <javascript:;>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-prime/attachments/20160819/4f03bc17/attachment.html>
More information about the Haskell-prime
mailing list