7 ms·

I don't understand why, in this situation, just make it a compiler option? What are the downsides to options like this? Confusion among Rust users when perusing

by lytedev 10y ago

I don't understand why, in this situation, just make it a compiler option? What are the downsides to options like this? Confusion among Rust users when perusing another code base?

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 ago
      A 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 ago
  If 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 ago
  Note 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 ago
  Haskell LANGUAGE pragmas are like "from __future__" in Python and various other equivalents in many languages.
iopq 10y ago
There's probably less opportunity to make an error when most things are immutable by default. I'm not sure if that's the case or not.
caconym_ 10y ago
Obviously it fragments the language in a way that's harmful for human readers as well as software like compilers, editors/IDE plugins, and so on. How to know which variant of Rust you're reading? As you add more options that change the syntax and semantics of the core language, these difficulties will be compounded. Maybe a bit of fragmentation isn't the end of the world, but I think you'd need a really good argument in its favor and in this case frankly I don't see one. Additive extensions/features (like GADTs in Haskell) are an easier sell for me because a) they actually add something useful and b) they generally don't change the core language, but rather sit on top of it.

by lytedev 10y ago

I don't understand why, in this situation, just make it a compiler option? What are the downsides to options like this? Confusion among Rust users when perusing another code base?

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 ago
    A 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 ago
If 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 ago
Note 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 ago
Haskell LANGUAGE pragmas are like "from __future__" in Python and various other equivalents in many languages.

iopq 10y ago

There's probably less opportunity to make an error when most things are immutable by default. I'm not sure if that's the case or not.

caconym_ 10y ago

Obviously it fragments the language in a way that's harmful for human readers as well as software like compilers, editors/IDE plugins, and so on. How to know which variant of Rust you're reading? As you add more options that change the syntax and semantics of the core language, these difficulties will be compounded. Maybe a bit of fragmentation isn't the end of the world, but I think you'd need a really good argument in its favor and in this case frankly I don't see one. Additive extensions/features (like GADTs in Haskell) are an easier sell for me because a) they actually add something useful and b) they generally don't change the core language, but rather sit on top of it.