5 ms·
The downsides of compiler options that modify the language is that code can no longer be understood on its own. Most languages stay away from these for that rea
by hota_mazi 10y ago
The downsides of compiler options that modify the language is that code can no longer be understood on its own. Most languages stay away from these for that reason.
One notable exception is Haskell, which uses pragmas to modify the language. At least these pragmas are part of the source code, but they absolutely need to be included if you want people to understand a snippet of your code. Take a look at Haskell questions on StackOverflow to see what I mean.
It's not something you want to see in an industrial strength language because it basically turns your language in factorial(n) languages, where n is the number of pragmas.
- dualogy 10y ago> It's not something you want to see in an industrial strength language because it basically turns your language in factorial(n) languages, where n is the number of pragmas. I don't see this as an issue because here it's just simply an intrinsical part of the "language". Nobody writes the core language consisting of just some ~6 primitives, everything on top is syntactic sugar and language-extension pragmas are just the same principle for the more obscure/experimental (but in no way unstable/less robust) ones.
- arcbyte 10y ago> Nobody writes the core language consisting of just some ~6 primitives https://en.wikipedia.org/wiki/Lisp_(programming_language) https://en.wikipedia.org/wiki/Lisp_(programming_language)
- kazinator 10y agoA discussion on minimal forms is here: http://www.faqs.org/faqs/lisp-faq/part1/section-6.html http://www.faqs.org/faqs/lisp-faq/part1/section-6.html "Nobody" implements practical Lips with just six special forms. To get a ridiculously low count, you have to leave a lot to uncounted library function. Such as, oh, any numeric support. Programmers want everyday things like (+ 2 3.0) to be implemented as primitives.
- Buttons840 10y agoIf a language will have N number of features I'd rather have some behind pragmas than not. Let's say by some measure GHC Haskell and C++ have the same number of features. C++ will always be N factorial, unless I read the entire source code to see that certain features are not being used. In Haskell I can look at the top line and easily see that many features are not being used. An interesting alternative (one which a C++ compoler could employ) is to allow pragmatic that disable features. E.g. I could quickly see that a C++ file is not using macros. This is the wrong default though. Features should be opt-in rather than opt-out to encourage a minimal use of features.
- harpocrates 10y agoNote that to _use_ an already written Haskell module, I don't need to know what extensions it uses. I don't even need to use the same ones. Haskell's LANGUAGE pragma is analogous to Rust having a bunch of experimental features you can turn on - they extend the language in a particular direction in a natural way.
- Peaker 10y agoHaskell LANGUAGE pragmas are like "from __future__" in Python and various other equivalents in many languages.