3 ms·
Yep agree. Keeping track of what all the language extensions do is not worth the effort compared with more leading edge languages like Agda and Idris.
by mbrodersen 4y ago
Yep agree. Keeping track of what all the language extensions do is not worth the effort compared with more leading edge languages like Agda and Idris.
- ParetoOptimal 4y agoAs of GHC 9.0.2 the GHC2021 language pragma is available and it consists of the most popular language extensions. https://downloads.haskell.org/~ghc/9.2.1/docs/html/users_guide/exts/control.html#extension-GHC2021 https://downloads.haskell.org/~ghc/9.2.1/docs/html/users_gui... Also typically language extensions are pretty simple, single purpose, and well documented.
- klysm 4y agoIs this structured like rust editions? If so I think that could be very useful for the ecosystem.
- quadrifoliate 4y ago> Also typically language extensions are pretty simple, single purpose, and well documented. I will try again to explain with an example how these extensions are borderline user-hostile. One of those extensions in your article linked above is apparently something called `DoAndIfThenElse` which enables if..then..else syntax with if and then on the same line, so far as I can tell [1]. When building programs that assume this extension without declaring that pragma, you get helpful error messages like "Unexpected semi-colons in conditional" [2]. Dealing with oddities like this seems to be routine any time I work on a Haskell project that's not a tutorial, and the constant need to go hunting for these error messages and add random pragma headers saps energy and is discouraging. There also seems to be an open issue about the extension being undocumented [3], which would seem to contradict your "well documented" claim. Given such significant problems in a relatively simple extension, I cannot even imagine how bad things are in more complex cases. I think whoever is steering the ship in Haskell/GHC land should really focus on ways to freeze new language extensions, and make the current ones well-documented in addition to providing options like the one you linked. Newer languages have environments that are much friendlier towards newcomers in terms of both documentation and (for lack of a better word) runnability of real-world code. ---------------------------------------- [1] I would really like to know why this is considered a popular language extension, and/or why it was needed, but let's skip over that for the moment. [2] https://kseo.github.io/posts/2014-01-13-DoAndIfThenElse-language-extension.html https://kseo.github.io/posts/2014-01-13-DoAndIfThenElse-lang... [3] https://gitlab.haskell.org/ghc/ghc/-/issues/18631 https://gitlab.haskell.org/ghc/ghc/-/issues/18631
- ParetoOptimal 4y ago> When building programs that assume this extension without declaring that pragma, you get helpful error messages like "Unexpected semi-colons in conditional" [2]. Dealing with oddities like this seems to be routine any time I work on a Haskell project that's not a tutorial, and the constant need to go hunting for these error messages and add random pragma headers saps energy and is discouraging. Well thats kind of the point of the GHC2021 extension. It will be a standard so that new programmers that format if else statements as they would in other languages don't get a weird error that very much does SAP their energy. > There also seems to be an open issue about the extension being undocumented [3], which would seem to contradict your "well documented" claim. It certainly calls it into question, though I did say typically. I'm open to weakening to "many times" if there are more than a few other examples. > Given such significant problems in a relatively simple extension, I cannot even imagine how bad things are in more complex cases. The problems described occur as a result of the extension not being turned on, so I find the logic doesn't work here.