Comment by AnimalMuppet

6 hours ago

I haven't played with it at all, but the writeup looks promising. Moving a bunch of things into the type system and out of runtime crashes is one of the ways we make progress.

I think this is wrong. Type systems should be simpler, and you should design it so that your language is easily and correctly statically checked. Not all invariants necessarily have to be verified at the same cadence (compile time)

  • > you should design it so that your language is easily and correctly statically checked.

    You do that by making the type system more sophisticated.

    If you have a really important invariant that you really don't want to be violated due to run-time behavior/input, it's a huge benefit to have a compiler that can statically check that it actually can't be. That's one of the main benefits of having type systems, not just describing the shape of data structures in memory.

    • You can perform static analysis outside of the compiler without putting things in the type system?

      C is a bad language to do this with for various reasons, but as a simple example:

          char* buf = malloc(SIZE);
          free(buf);
          free(buf);
      

      There is absolutely no reason why static analysis should not be able to see what the problem is here.

      3 replies →

  • But what does static analysis work on? The source code. If it's not in the source code, the static analyzer can't check it. So if you want to check something, even with a static analyzer, then you need some way to talk about that thing in the source code, which means it has to be part of the source language.

    Now, sure, you could have some kind of annotations in the comments or something, and a static analyzer that checked those, and you could get that to check pretty much anything that can be checked statically. But at that point, it's not really part of the language, is it?