[Haskell-cafe] Documenting extensions

[Alexander Altman]

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 <monkleyon at googlemail.com> 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160422/7a99b797/attachment.html>