<story><title>An alternative front end for Haskell?</title><url>https://gilmi.me/blog/post/2023/10/05/haskell-alternative-frontend</url></story><parent_chain><item><author>stepchowfun</author><text>Most of the comments so far are negative, so I&amp;#x27;ll add something positive. One thing I love about the Haskell community is how they are always questioning their assumptions and genuinely seeking the best way to do things (often drawing upon or contributing to computer science research). The core concepts behind Haskell are clean and simple (essentially something between System F and System Fω), but there&amp;#x27;s a lot of baggage on the surface that obscures that underlying elegance. We should encourage people taking an introspective look into their tools and asking how they can be better, even if certain proposals are unrealistic or controversial.&lt;p&gt;I think the author is just writing down their opinions (which are worth discussing!) and not seriously trying to start a new GHC frontend. Personally, I think Haskell is approximately stuck in a local maximum, which can only be escaped by embracing dependent types (which are actually simpler than where Haskell has been heading) rather than building increasingly complex approximations of them. Once you try a dependently typed language like Agda, Lean, Coq, or Idris, it&amp;#x27;s hard to go back to the complexity of having two (or more!) separate languages for types and programs.&lt;p&gt;Regarding the proposals in the article, the most interesting to me is (2), although I&amp;#x27;m not sure about some of the specifics. In general, I think Haskell needs a way to graduate (or retire) language extensions, rather than having them accumulate unboundedly. It&amp;#x27;s harder to talk about Haskell when everyone is using a different flavor of it.</text></item></parent_chain><comment><author>codeflo</author><text>&amp;gt; Personally, I think Haskell is approximately stuck in a local maximum, which can only be escaped by embracing dependent types&lt;p&gt;To give a counter point, there seem to be lots of small wins that aren&amp;#x27;t taken, possibly in part &lt;i&gt;because&lt;/i&gt; people seem to wait for the big ideas.&lt;p&gt;Take partial functions like head: You can do what Haskell and Java do and throw an exception. Or you can have dependent types and statically prevent the function from being applied to an empty list. But the obvious and easy solution in the current language would be to return Maybe, which isn&amp;#x27;t done because there&amp;#x27;s a feeling that it&amp;#x27;s not a big enough step to be worth the effort, and dependent types will eventually solve this anyway.</text></comment>
<story><title>An alternative front end for Haskell?</title><url>https://gilmi.me/blog/post/2023/10/05/haskell-alternative-frontend</url></story><parent_chain><item><author>stepchowfun</author><text>Most of the comments so far are negative, so I&amp;#x27;ll add something positive. One thing I love about the Haskell community is how they are always questioning their assumptions and genuinely seeking the best way to do things (often drawing upon or contributing to computer science research). The core concepts behind Haskell are clean and simple (essentially something between System F and System Fω), but there&amp;#x27;s a lot of baggage on the surface that obscures that underlying elegance. We should encourage people taking an introspective look into their tools and asking how they can be better, even if certain proposals are unrealistic or controversial.&lt;p&gt;I think the author is just writing down their opinions (which are worth discussing!) and not seriously trying to start a new GHC frontend. Personally, I think Haskell is approximately stuck in a local maximum, which can only be escaped by embracing dependent types (which are actually simpler than where Haskell has been heading) rather than building increasingly complex approximations of them. Once you try a dependently typed language like Agda, Lean, Coq, or Idris, it&amp;#x27;s hard to go back to the complexity of having two (or more!) separate languages for types and programs.&lt;p&gt;Regarding the proposals in the article, the most interesting to me is (2), although I&amp;#x27;m not sure about some of the specifics. In general, I think Haskell needs a way to graduate (or retire) language extensions, rather than having them accumulate unboundedly. It&amp;#x27;s harder to talk about Haskell when everyone is using a different flavor of it.</text></item></parent_chain><comment><author>mhitza</author><text>&amp;gt; I think Haskell needs a way to graduate (or retire) language extensions, rather than having them accumulate unboundedly. It&amp;#x27;s harder to talk about Haskell when everyone is using a different flavor of it.&lt;p&gt;That is what the standardization process is for. I don&amp;#x27;t think that the parties that could write a new Haskell standard have the time, resources, or bandwidth to work on one. That&amp;#x27;s why for now we&amp;#x27;re stuck with 98, 2010 and a bunch of extensions.</text></comment>