5 ms·
What’s the advantage of a formal standard when the language itself and the tools are all open source? All I can see a formal standard adding to the picture is a
by cageface 6y ago
What’s the advantage of a formal standard when the language itself and the tools are all open source? All I can see a formal standard adding to the picture is a lot of bureaucracy and friction and the headache of subtly incompatible implementations.
- higerordermap 6y agoHaving a spec is enough IMO. Go has one. That enables alternative implementations. There are enough reasons to not want an implementation monoculture.
- cageface 6y agoWhat are the reasons? I see a lot of benefits of an open source monoculture, especially if corporate backing is uncertain.
- higerordermap 6y agoCompetition is great. If there is no competition, implementation quality stagnates. It happened with GCC, for example.
- cageface 6y agoI doesn't seem like a comparable situation. There were already multiple competing C & C++ compilers including several commercial options. I don't think complacency is holding Rust back.
- nullifidian 6y agoI would be nice to have a document we can rely on and refer to, in case of subtle breakages and bugs. Alternative implementations could also be a possibility down the line. Having a formal spec would also help with code verification, i.e. you basically can't do it unless the language is specified.
- jabl 6y agoIndeed. It was a very much different situation for, say, C or C++. Back then it was multiple proprietary implementations, and customers (if not vendors) had an interest in a specification. For Rust, so far there is one (main) implementation, which is open source. Very different scenario.
- tzs 6y ago> What’s the advantage of a formal standard when the language itself and the tools are all open source? Let a, b, c be integers. Consider this statement in a language: a = b % c If b < 0, c > 0, is a <= 0 or is a >= 0? How about if b > 0, c < 0? How about if b < 0, c < 0? There are three ways I might go about determining that. 1. I could write some test cases and run them. That will tell me what the deal is for that particular compiler on the particular OS and architecture I am compiling on/for. It doesn't tell me if I can count on that anywhere else. It could be that the compiler doesn't care, and I'm simply seeing the way the underlying machine division or mod instruction works on my particular CPU. If I care, then, I have to specifically write code myself to make it work the way I want, or make sure to only run my code on CPUs that work the way I want. 2. I could look at the source for the compiler. Suppose I see in there that it compiles it so that it will be consistent regardless of how the underlying CPU works, and it is even doing it the way I want. Great, now I don't need to write extra code. I can just use "a = b % c" and be done with it, right. Nope. Maybe in the next release of the compiler they change this to just do whatever the underlying CPU does because that enables some optimization that they could not make when they forced one particular option for this. Then my code breaks. 3. I can read the language specification and see what it says about signs and modulus. If it says it will always work one specific way, I can code to that and be done with it. Without a specification for language X, you cannot really write X code. You can just write code for the incompletely documented X-like language implemented by specific releases of specific X-like langauge compilers, possibly also limited to specific CPUs.
- the_why_of_y 6y agoTrue, but (as you say) this merely requires a specification, not a (ISO or other) standard like the GP asked about. In other words, it's sufficient if the semantics are publicly documented with adequate precision, and the developers of the reference implementation consider any deviation from this specification a bug.