Checker Framework VS cakeml

It is interesting! I experimented with creating a bad borrow checker for Java using annotations from

https://checkerframework.org/

It supports some level of substructural types using must-call annotations,

https://checkerframework.org/manual/#resource-leak-checker

Lombok is not a compiler extension. Compiler extensions, aka annotation processors, are offered only specific capabilities that ensure that they preserve the Java language specification. Particularly, code that compiles successfully with an extension also compiles without it (perhaps requiring other classes to be available) and it compiles down to the same bytecode. Annotation processors are used to implement pluggable type systems (e.g. https://checkerframework.org) or to generate other classes (e.g. https://immutables.github.io/).

Unlike compiler extensions, Lombok compiles source files that do not conform to the Java language specification. Lombok is an alternative Java Platform language, like Clojure or Kotlin or Scala, except that it's a superset of the Java language. However, rather than forking `javac` source code and modifying it to compile Lombok source files, the Lombok compiler modifies `javac`'s operation by hacking into its internals and modifying them as it runs to compile Lombok sources rather than Java sources.

Having alternative Java Platform languages is perfectly fine. The problem with Lombok is that it doesn't present itself as such but as a library or a compiler extension even though it violates the Java language specification in ways that compiler extensions are forbidden from doing.

And then I found (thanks Oracle), https://checkerframework.org/ zomg, this thing is awesome. Pluggable Type Systems!

Java should adopt something like the Checker Framework Nullness Checker in its first-party tooling.

https://github.com/typetools/checker-framework

And modern (real, non-android) Java via project amber and so on has gone more and more quasi functional with its immutability and sealed and record types for effective sum types, as well as its pretty cool type-use annotation extensible static type checks.

Checkerframework - a really academic take, and as one might expect from such a thing, backed by tons of papers and analysed to perfection. Specifically, this is the only framework I'm aware of that realizes nullity is a little more complicated than just a boolean yes-or-no; just like generics actually have 4 flavours for any given type: List, List, List, and List are all 4 important and unique, and nullity is no different. Specifically, it can occur that you want to write a method that ought to accept both lists of nullable strings as well as list of nonnull strings, and needs to 'convey' this nullity again on its output. You can either attempt to lift along the existing generics system in java which I think is your intent, but it's not actually all that easy to do this. After all, T extends @Nullable Number super @NonNull Number, or whatnot, isn't legal java. So you.. really just can't do that. Checker Framework solves this problem by introducing the @PolyNull annotation, which still isn't perfect but covers almost all real world use cases you can think of. I'm missing any acknowledgement in your documentation. An oversight, or, something you hadn't thought of yet? You're in good company: Both eclipse and intellij's engineers, when I asked them about it, just hadn't realized it was a thing. Point is: If you think the primary problem with e.g. eclipse's and intellij's take is that they lack academic rigour - checkerframework has you beat.

NullAway or the Checker Framework should greatly help eliminate the issue. Also, when Java gets value types you should be able to define your own non nullable value types and use them safely.

There are a lot of existing libraries for type checking modules. For example the Checker Framework created by University of Washington. This framework includes a NonNull module, as well as regular expression module and a mutex lock module. See this for more information.

If I understand what you are asking about correctly, then I do think you are mistaken.

As a sibling comment observed, you would be proving something about a program, but proving things about programs is both possible and done.

This ranges from things like CakeML (https://cakeml.org/) and CompCert (compilers with verified correctness proofs of their optimizations) to something simple like absence of runtime type errors in statically strongly soundly-typed languages.

Of note is that you are proving properties of your program, not proving them perfect in every way. The properties of your program that you prove can vary wildly in both difficulty and usefulness. A sufficiently advanced formally verified compiler like CakeML can transfer a high-level proof about your source code to a corresponding proof about the behavior of the generated machine-executable code.

> A single IR with multiple passes is a good way to build a compiler

https://mlir.llvm.org/, which is using, is largely claiming the opposite. Most passes more naturally are not "a -> a", but "a -> b". data structures and data structures work hand in hand, it is very nice to produce "evidence" for what is done in the output data structure.

This is why https://cakeml.org/, which "can't cheat" with partial functions, has so many IRs!

Using just a single IR was historically done for cost-control, the idea being that having many IRs was a disaster in repetitive boilerplate. MLIR seeks to solve that exact problem!

You may want to look at [CakeML](https://cakeml.org) done in HOL4, there is also a nice proof pearl about a more .. minimalistic verified bootstrapped compiler also in HOL4.

CakeML

There is also Cake ML which is a formally verified functional programming language compiler and runtime.

There is also a CakeML -> Standard ML compiler though it seems to have been built to translate benchmarks and sort of old so I'm not sure how comprehensive it is: https://github.com/CakeML/cakeml/tree/master/unverified/front-end

> One guess is that lisps cope with being minimal through use of macros and metaprogramming, it's difficult for a typed language to support that level of metaprogramming while maintaining the various guarantees that one wants from such a system.

Difficult, but certainly not impossible [0].

[0] https://cakeml.org/

If this interests you, I'd highly recommend checking out CompCert (docs here) and CakeML.