Re:Ohm – A library and language for building parsers, interp...
by chrisseaton on Saturday March 27, 2021 @06:17PM
(#26606115)
My experience doing both in practice is that the type system helps you with things that aren't really a problem anyway (a compiler doesn't really have complex data structures and you don't often get these basic things wrong) and all but the most sophisticated type systems don't even begin to help you with things you really need help with - maintaining invariants.
[ Parent
| on HN ]
Re:Ohm – A library and language for building parsers, interp...
by kazinator on Monday March 29, 2021 @01:13PM
(#26625033)
Exactly. E.g. remove this line, and incorrect optimizations ensure, so the compiler fails halfway through recompiling itself:
http://www.kylheku.com/cgit/txr/tree/share/txr/stdlib/optimi...
The type is fine whether or not the line is present. It's all about that invariant.
None of the hair pulling I've experienced in compiler debugging had anything even remotely to do with type, which is something flushed out by testing.
Whenever doing anything, like an optimization test case, I put in print statements during development to see that it's being called, and what it's doing. You'd never add a new case into a compiler that you never tested. Just from the sheer psychology of it: too much work goes into it to then not bother running it. Plus the curiosity of seeing how often the case happens over a corpus of code.