Re: [Haskell-cafe] Documenting extensions

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