<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-text-plain" wrap="true" graphical-quote="true"
style="font-family: -moz-fixed; font-size: 12px;" lang="x-unicode">
<pre wrap="">On 2016-04-05 22:12, Doug McIlroy wrote:
<blockquote type="cite" style="color: #993300;">
The extensions section of the GHC User Guide gives no formal syntax,
often teaches semantics only by example, and is replete with sales
pitches, partial analogies, inconsistent terminology, and (helpful)
appeals to outside sources. Definitely not a bible.
I understand that many GHC extensions are probationary. Nevertheless,
in the interest of facilitating their full and correct use, I would
plead that a report-grade description accompany each language feature
incorporated in official releases.
<pre wrap="">I don't think the GHC User Guide is the best place to put this
information. One reason is that GHC might be the most popular compiler
by far, maybe even a "reference compiler" but it was never intended to
be the only one. Thus language and compiler should be documented
separately, if there is a nice way to do so.
But maybe we get somewhere if we look at different challenges as well.
For example: if you develop code for a project like Pandoc, you will
most likely be developing on one version of GHC, but the final code will
be checked against several other versions as well. How do you find out
which extensions you can use in this subset of compilers? Do you develop
on the oldest version of GHC that will be checked, keeping several
versions on your machine? Or the oldest and the newest versions? All of
them? Do you look up all the extensions of all the versions in the docs
beforehand? Do you use whatever you want and then pull out extensions
that didn't work?
This latter challenge sparked a short-lived facebook discussion in a
Haskell group some time ago. The result was mainly that there are easy
ways to get a database of (Version,LanguageExtension) tuples (scraping
the docs or asking nix-pkg, if nothing else). The next step might be to
but this database on the web. It could work almost like caniuse.com
works for browser compatibility, but for Haskell extensions. Starting
from there, adding documentation to each extension and adding
information about differences in implementation between versions should
be as easy a editing a wiki.
By the way: last time I checked "caniextend.com" did not seem to be
registered. I honestly expected there to be a
Of course someone would have to build and maintain this thing. I don't
expect there to be huge commercial value in it though, so motivations
might not be high. That being said, I'm currently experimenting with
Yesod in several projects. Once I get the hang of it and finished the
most important ones I might attack this one just for kicks - if it's not
already taken by then and if it doesn't turn out to be stupid.
No promises though, which is why I didn't register the aforementioned
URL. Feel free to take it if you have a student that keeps nagging you
about giving him a project. <span class="moz-smiley-s3" title=";)"></span>