4 ms·

> Rust is not ready to be specified as is required for ISO and similar standards. A few large chunks of its functionality currently don’t have any good definiti

by rualca 6y ago

> Rust is not ready to be specified as is required for ISO and similar standards. A few large chunks of its functionality currently don’t have any good definition written down, but instead are defined by the rustc implementation: most significantly, the ownership and borrow checking system. That assertion makes no sense at all. If an implementation exists and is already used in production then it's behavior is already relied upon and thus it can already be described. Just write down how it behaves and specify how it is expected to behave. That's it. That's how the whole software world has been for almost half a century. And no, it makes no difference if a reference implementation decides to implement something that breaks that behavior. That just means it doesn't comply with the standard. That's it. Why have these basic lessons been forgotten?

hobofan 6y ago
> Just write down how it behaves and specify how it is expected to behave. I don't know how to describe it differently as GP, but I'll give it a try. Until a formalised model is built, there is no way to describe it's behaviour that wouldn't come down to writing down the implementation that's currently in the compiler (apart from specifying it by example, which would be even more expansive). It _might_ (don't quote me on this) be possible to more easily formalize and standardize borrow checking if you leave out non-lexical lifetimes (which were added rather recently), but that's a bad idea because you would lose a lot of functionality, and an alternative compiler with an incompatible implementation of NLLs could split the ecosystem, which obviously nobody wants.
- rualca 6y ago
  > I don't know how to describe it differently as GP, but I'll give it a try. Until a formalised model is built, there is no way to describe it's behaviour that wouldn't come down to writing down the implementation that's currently in the compiler (apart from specifying it by example, which would be even more expansive). That is the point some seem to fail to understand: said model is absolutely irrelevant if we already have production releases of an implementation of Rust. A standard is not supposed to be academically rigorous. A standard is a specification of the current behavior so that multiple implementations can meet the current requirements, and thus ensure interoperability and compatibility. It makes absolutely no sense to talk about "a formalized model" because rust is already used in production without said formalized model. The absence of said formalization is irrelevant. The only thing that matters is that the current behavior is specified and set in stone so that it serves as a target set in stone that anyone in the world can target and expect to interoperate. It's terribly simple: if a rust v1.25 exists then it's behavior and interfaces can be described. Obviously. That description is what a standard is: an implementation target set in stone that others can use as a reference.
  - steveklabnik 6y ago
    While I disagree with the general sentiment of “rust needs a standard to be successful generally,” you are absolutely right in this comment. There’s a number of things at play here, but there are folks trying to do exactly this. We’ll get there, in time.
  - hobofan 6y ago
    If you want to exhaustively describe the behavior of e.g. Rust 1.25.0, without a formalized model, then the only way to do so it to run it for all kinds of possible (edge-)cases you encounter and document the output. If all you have as a reference is a bunch of test cases without any underlying reasoning as to why input A leads to output B, then that's not really a useful target to implement against. At that point you can just go the direct route, not bother with any standard and just implement directly against the Rust compiler.
chrismorgan 6y ago
The problem is that we don’t have a sound, correct model. What we have is a compiler that seems pretty decent, but rejects some things that shouldn’t really be rejected, and accepts a few things that are iffy and potentially unsound. It’s a whole lot of code crafted in a comparatively ad hoc manner, whereas a true, correct model is likely to be simpler and more beautiful. Any specification would therefore be specifying the wrong thing, essentially a form of overfitting. Suppose you’re a cave man and you’re just figuring out how to double numbers. So far, you’ve figured out how to double each number from 0 to 100. Someone asks you to write down your fancy rule so they can do something with it. Do you really want to be teaching everyone that the way to double a number is: “if the number is zero, the answer is zero; if one, then two, 2 ⇒ 4, 3 ⇒ 6, 4 ⇒ 8, &c. ad tedium”? Even if it covers all the required cases without error, it’s a mess. It’ll do for the moment for your own personal use, but you don’t want to be teaching it to other people until you figure out that you can say “to double a number, add the number to itself”. Until we have a sound model, any attempt at specifying Rust would, for these key areas, be simply importing the current implementation of the compiler. That’s not a good sort of a specification.

by rualca 6y ago

hobofan 6y ago

> Just write down how it behaves and specify how it is expected to behave. I don't know how to describe it differently as GP, but I'll give it a try. Until a formalised model is built, there is no way to describe it's behaviour that wouldn't come down to writing down the implementation that's currently in the compiler (apart from specifying it by example, which would be even more expansive). It _might_ (don't quote me on this) be possible to more easily formalize and standardize borrow checking if you leave out non-lexical lifetimes (which were added rather recently), but that's a bad idea because you would lose a lot of functionality, and an alternative compiler with an incompatible implementation of NLLs could split the ecosystem, which obviously nobody wants.

rualca 6y ago
> I don't know how to describe it differently as GP, but I'll give it a try. Until a formalised model is built, there is no way to describe it's behaviour that wouldn't come down to writing down the implementation that's currently in the compiler (apart from specifying it by example, which would be even more expansive). That is the point some seem to fail to understand: said model is absolutely irrelevant if we already have production releases of an implementation of Rust. A standard is not supposed to be academically rigorous. A standard is a specification of the current behavior so that multiple implementations can meet the current requirements, and thus ensure interoperability and compatibility. It makes absolutely no sense to talk about "a formalized model" because rust is already used in production without said formalized model. The absence of said formalization is irrelevant. The only thing that matters is that the current behavior is specified and set in stone so that it serves as a target set in stone that anyone in the world can target and expect to interoperate. It's terribly simple: if a rust v1.25 exists then it's behavior and interfaces can be described. Obviously. That description is what a standard is: an implementation target set in stone that others can use as a reference.
- steveklabnik 6y ago
  While I disagree with the general sentiment of “rust needs a standard to be successful generally,” you are absolutely right in this comment. There’s a number of things at play here, but there are folks trying to do exactly this. We’ll get there, in time.
- hobofan 6y ago
  If you want to exhaustively describe the behavior of e.g. Rust 1.25.0, without a formalized model, then the only way to do so it to run it for all kinds of possible (edge-)cases you encounter and document the output. If all you have as a reference is a bunch of test cases without any underlying reasoning as to why input A leads to output B, then that's not really a useful target to implement against. At that point you can just go the direct route, not bother with any standard and just implement directly against the Rust compiler.

chrismorgan 6y ago

The problem is that we don’t have a sound, correct model. What we have is a compiler that seems pretty decent, but rejects some things that shouldn’t really be rejected, and accepts a few things that are iffy and potentially unsound. It’s a whole lot of code crafted in a comparatively ad hoc manner, whereas a true, correct model is likely to be simpler and more beautiful. Any specification would therefore be specifying the wrong thing, essentially a form of overfitting. Suppose you’re a cave man and you’re just figuring out how to double numbers. So far, you’ve figured out how to double each number from 0 to 100. Someone asks you to write down your fancy rule so they can do something with it. Do you really want to be teaching everyone that the way to double a number is: “if the number is zero, the answer is zero; if one, then two, 2 ⇒ 4, 3 ⇒ 6, 4 ⇒ 8, &c. ad tedium”? Even if it covers all the required cases without error, it’s a mess. It’ll do for the moment for your own personal use, but you don’t want to be teaching it to other people until you figure out that you can say “to double a number, add the number to itself”. Until we have a sound model, any attempt at specifying Rust would, for these key areas, be simply importing the current implementation of the compiler. That’s not a good sort of a specification.