3 ms·
> If you add one more extension, you program might suddenly stop to compile. Do you have some real examples of this happening with GHC extensions? I haven't ru
by enigmo 13y ago
> If you add one more extension, you program might suddenly stop to compile.
Do you have some real examples of this happening with GHC extensions? I haven't run across one in the field.
> We need a fixed set of language extensions which are always available.
This sounds very much like a language standard. Haskell isn't much different than other languages here, though the language committee is slow to ratify generally accepted extensions into the standard. GHC at least makes them available to people who want to kick the tires. Then read about closures in Java. Look at C++11 revisions and notice that sometimes meant cutting features, even if they were previously implemented by some compilers (template exports) or prototyped (concepts).
- solomatov 13y ago>Do you have some real examples of this happening with GHC extensions? I haven't run across one in the field. I am not that advanced in how GHC types work. However, I understand, that in any language extensions there are tradeoffs between how expressive a language is and how much type inference we have.
- enigmo 13y agoMany (most?) of GHC's commonly used language extensions enable new functionality or syntax (DataKinds, GADTs, RankNTypes, KindSignatures, TypeFamilies, FunDeps, MPTCs, etc). Enabling such extensions and not using these newly enabled features shouldn't affect type inference.