
I'd like to believe the Haskell report is a bible. I learned H98 using the Prelude as a source of examples and Hugs as a testbed. That was a comfortable and rewarding combination. Later I discovered that by default GHC rejected almost all my report-conforming (H98 and H2010) code. Ironically, its website at the time asserted, "Haskell is a standard language." In fact, far from reflecting biblical authority, the de facto Haskell discussed in this cafe comes in some 2^99 flavors -- enough to use a different language for every run of the compiler for the life of the universe. Witness: ghc --supported-languages | grep -v '^No[A-Z]' | wc -l (99 is the answer for GHC 7.8.4. In fact not all combinations of -X options are legal, but you get the point.) Unfortunately there is no coherent discussion of all those Haskells. 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. This seems like a small amount of effort beyond the hard work of conception and implementation. Are there cogent reasons for doing otherwise? Doug

On Apr 5, 2016, at 10:12 PM, Doug McIlroy
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. This seems like a small amount of effort beyond the hard work of conception and implementation. Are there cogent reasons for doing otherwise?
Yes: we're imperfect humans with limited time. This, of course, cannot be a reason not to strive for this ideal. I would like to suggest a slight softening of this proposal: that every extension included in a release be given either a label as probationary (with a mention of its first release) or such a specification. Some extensions end up in released versions of GHC before they are fully settled, as the process of wide release gives feedback to the extension author and allows for improvement in future releases. PolyKinds/DataKinds/ConstraintKinds fit into this category in 7.4, and TypeApplications and TypeInType fit into this category for 8.0. PatternSynonyms has also undergone a bit of churn. However, older extension do deserve this level of documentation. Care to post a feature request? Richard

On 21 April 2016 at 12:19, Giacomo Tesio
2016-04-05 22:12 GMT+02:00 Doug McIlroy
: Later I discovered that by default GHC rejected almost all my report-conforming (H98 and H2010) code.
Do you mean that GHC can't compile Haskell2010 conformant code? Can you please post (or point to) some examples?
This page [1] lists the ways in which GHC diverges from the standard. Erik [1] https://downloads.haskell.org/~ghc/master/users-guide/bugs.html

On 2016-04-05 22:12, Doug McIlroy wrote:
<snip>
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.
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 male-body-part-enlargement-website. 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. Cheers, Martin

This has already been done, although I'm sure it needs some work still: https://damianfral.github.io/ghcaniuse/ (Not my project, by the way.)
On Apr 22, 2016, at 12:28 PM, martin
wrote: On 2016-04-05 22:12, Doug McIlroy wrote: <snip>
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. 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 male-body-part-enlargement-website.
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.
Cheers, Martin _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
participants (6)
-
Alexander Altman
-
Doug McIlroy
-
Erik Hesselink
-
Giacomo Tesio
-
martin
-
Richard Eisenberg