4 ms·

I don't exactly understand why Haste was made into a separate dialect when it "just" has a different stdlib? > with a different set of standard libraries Is t

I don't exactly understand why Haste was made into a separate dialect when it "just" has a different stdlib? > with a different set of standard libraries Is there a technical reason why it would be ill advised to just make Haste itself into a separate library that can be included into the regular Haskell ecosystem? Doesn't this type of fragmentation cause huge delays in the progress of a language, ultimately? Hopefully it's obvious that I'm entirely not knowledgeable about these things and that I'd love for someone to explain this to me.

azernik 13y ago
This is a definitional issue more than a technical one - if you follow the link to the Haskell package documentation [1], the project actually consists of aforementioned standard library, plus a Haskell-to-JS compiler. This is a "dialect" of Haskell in the same way that we can speak of the GCC and Intel dialects of C and C++ - both compilers support the same standard, but each supports a different set of non-standard extensions. In this case, the Haste front page notes that it supports most, but not all, GHC extensions to the Haskell standard. [1] http://hackage.haskell.org/package/haste-compiler http://hackage.haskell.org/package/haste-compiler