4 ms·

I think Steve is reacting more to this not being a compile error.

steveklabnik 8y ago
Yes, the text explained how I should write this, my surprise is that I can get undefined behavior. And that the text says that this may, but is not guaranteed to, warn. On Twitter the other day, someone suggested that this is because, when Ada was first made, this kind of analysis was truly to expensive, and so the guarantee was not made, and they're sticking to backwards compatibility, and modern implementation should basically always warn. That seems reasonable, but I have no idea if it's correct. I assume most real-world Ada scenarios treat warnings as errors.
- sanxiyn 8y ago
  Yes, the analysis is called definite assignment analysis: https://en.wikipedia.org/wiki/Definite_assignment_analysis https://en.wikipedia.org/wiki/Definite_assignment_analysis It was a great victory of Java and C# to require this. Java's analysis is "buggy" and C#'s is complete.
  - twic 8y ago
    To be clear, buggy in that it can sometimes not detect correct assignment, and require you to add some unnecessary assignments to shut it up. Not in that you can ever read an uninitialised variable. That is a bit of a theme in Java. The type inference often has the same problem. (Although the type inference is also actually unsound)
    - kqr 8y ago
      Hub, is that supposed to not be the case with C#? Because I've definitely had that experience at least once, of knowing a variable is initialized and the compiler not "getting" it until I added some semantically redundant formality.
- galangalalgol 8y ago
  It had processing constraints and it probably lacked some too like c interop. But largely it has the same target as rust right? Back when rust first got started was there someone on the team that knew Ada well in order to take lessons learned. It seems kind of crazy if there wasn't. It would be like Tesla not having anyone from a traditional car company involved in initial design.
  - steveklabnik 8y ago
    In general, I have a rule of thumb: if the question is "does Graydon know about $LANGUAGE", the answer is almost always "yes." I haven't specifically spoken to him about it, though.
  - coldtea 8y ago
    >Back when rust first got started was there someone on the team that knew Ada well in order to take lessons learned. It seems kind of crazy if there wasn't. It would be like Tesla not having anyone from a traditional car company involved in initial design. Or like Go only taking into account C, Limbo, and CSP.
- pmderodat 8y ago
  It’s a good opportunity to point that Ada defines “bounded errors” and “erroneous execution” as distinct things. TLDR: reading uninitialized data in Ada is safer than in C. Reading an uninitialized OUT argument is a bounded error, which is much less dramatic than C’s undefined behavior: the semantics is that you’ll read an arbitrary value (which is obviously bad as far an program intent is concerned), but otherwise the language constraints still hold. This is very different from erroneous execution, which is very similar to the famous undefined behaviors in C, in which all bets are off and anything can happen.
  - steveklabnik 8y ago
    Ah thank you! As I dig into the reference material, I’m sure I’ll gain this kind of nuance, but I appreciate you pointing this out! That indeed does also make it less dangerous.

Yes, the text explained how I should write this, my surprise is that I can get undefined behavior. And that the text says that this may, but is not guaranteed to, warn. On Twitter the other day, someone suggested that this is because, when Ada was first made, this kind of analysis was truly to expensive, and so the guarantee was not made, and they're sticking to backwards compatibility, and modern implementation should basically always warn. That seems reasonable, but I have no idea if it's correct. I assume most real-world Ada scenarios treat warnings as errors.

sanxiyn 8y ago
Yes, the analysis is called definite assignment analysis: https://en.wikipedia.org/wiki/Definite_assignment_analysis https://en.wikipedia.org/wiki/Definite_assignment_analysis It was a great victory of Java and C# to require this. Java's analysis is "buggy" and C#'s is complete.
- twic 8y ago
  To be clear, buggy in that it can sometimes not detect correct assignment, and require you to add some unnecessary assignments to shut it up. Not in that you can ever read an uninitialised variable. That is a bit of a theme in Java. The type inference often has the same problem. (Although the type inference is also actually unsound)
  - kqr 8y ago
    Hub, is that supposed to not be the case with C#? Because I've definitely had that experience at least once, of knowing a variable is initialized and the compiler not "getting" it until I added some semantically redundant formality.
galangalalgol 8y ago
It had processing constraints and it probably lacked some too like c interop. But largely it has the same target as rust right? Back when rust first got started was there someone on the team that knew Ada well in order to take lessons learned. It seems kind of crazy if there wasn't. It would be like Tesla not having anyone from a traditional car company involved in initial design.
- steveklabnik 8y ago
  In general, I have a rule of thumb: if the question is "does Graydon know about $LANGUAGE", the answer is almost always "yes." I haven't specifically spoken to him about it, though.
- coldtea 8y ago
  >Back when rust first got started was there someone on the team that knew Ada well in order to take lessons learned. It seems kind of crazy if there wasn't. It would be like Tesla not having anyone from a traditional car company involved in initial design. Or like Go only taking into account C, Limbo, and CSP.
pmderodat 8y ago
It’s a good opportunity to point that Ada defines “bounded errors” and “erroneous execution” as distinct things. TLDR: reading uninitialized data in Ada is safer than in C. Reading an uninitialized OUT argument is a bounded error, which is much less dramatic than C’s undefined behavior: the semantics is that you’ll read an arbitrary value (which is obviously bad as far an program intent is concerned), but otherwise the language constraints still hold. This is very different from erroneous execution, which is very similar to the famous undefined behaviors in C, in which all bets are off and anything can happen.
- steveklabnik 8y ago
  Ah thank you! As I dig into the reference material, I’m sure I’ll gain this kind of nuance, but I appreciate you pointing this out! That indeed does also make it less dangerous.