
CakeML: A verified implementation of ML - poppingtonic
https://github.com/CakeML/cakeml
======
nickpsecurity
The best thing since FLINT. My scheme here was to piggy back on it by
implementing fast, compatible DSL of CakeML in Racket or something. Do
prototyping and testing with fast one. Once ready, compile functions with
verified one. Works best for tools that will still have acceptable performance
or run in batches overnight. Implement it on Verisoft stack if still available
for down to CPU correctness.

Also, some recent threads are on trustworthy compilers with verified vs
reproducible builds. The ML languages have made robust compilers much easier
to write. One can use this one for that to further reduce TCB and make
compiler still easier to write vs C or whatever.

~~~
e12e
> The best thing since FLINT.

I assume you mean something related to?:

[http://flint.cs.yale.edu/flint/software.html](http://flint.cs.yale.edu/flint/software.html)

I can't seem to find anything directly related to the software part - is
SML/NJ a verified implementation of ML'97?

I was exposed to a bit of Standard ML in university, and it always felt
"nicer" than OCaml - but also less practical for actually getting anything
done (probably because more people actually write real software in OCaml than
in SML?).

As for Racket and SML, I came across the following existing projects:

"This is the Standard ML language embeded in PLT Scheme.":
[http://planet.racket-
lang.org/display.ss?package=sml.plt&own...](http://planet.racket-
lang.org/display.ss?package=sml.plt&owner=chongkai)

"A Standard ML to Racket Translator without type inferencing and checking":
[https://github.com/stslxg/sml-racket](https://github.com/stslxg/sml-racket)

And while I like the concept of Racket (I've yet to play with it as much as I
think it deserves), why not simply use SML/NJ or MLTON if CakeML is a subset
of SML? Or possibly implement a non-verfied implementation either on top of
MLTON/SML/NJ, or _in_ ML? Curious about your line of thinking there.

~~~
nickpsecurity
"I can't seem to find anything directly related to the software part - is
SML/NJ a verified implementation of ML'97?"

The page says it's included in SML/NJ distribution. Probably one of the
tarballs. SML/NJ is just an old compiler for SML 1997. FLINT is techniques and
code needed to certify compilation. They're different things but apparently
bundled.

"probably because more people actually write real software in OCaml than in
SML?)"

That's what I've gathered. The SML people have strong academic focus with
Ocaml people having more practical focus. A big community built up around it.

"As for Racket and SML, I came across"

That's neat but they both have no type checking. I'll skip to next question as
it's relevant here.

" Curious about your line of thinking there."

LISP is easy to parse, easy to interpret, has robust compilers, supports
incremental compilation of individual functions, modify/debug a running
program, and especially extension with macros. Racket is a batteries-included
LISP with IDE, active community, and strong support for DSL's.

Now, ML's strengths are strong typing, type inference, easily integrated into
formal verification, lots of prior work/tools in that (incl compilers), and
easy to model w/ macros. Embedding ML in a LISP gives me the best of both
worlds. I once did this in a 4GL to have rapid development with extraction to
C/C++ with safety, portability, etc stuff auto-inserted. Easy parsing also
lets you extract to a number of ML's or LISP's to use their tooling to catch
extra errors in yours.

I've only run into two tools outside of Racket doing this sort of thing:

[https://github.com/combinatorylogic/mbase](https://github.com/combinatorylogic/mbase)

[http://julialang.org/](http://julialang.org/)

Mbase is used in commercial tools for static analysis, etc. It's a LISP and
toolset custom designed for easily making things like compilers that comes
with many DSL's for specific tasks, including ML. Julia raises the bar for 3GL
language experience via a compiler written in LISP (femtolisp) that
immediately translates the AST's into LISP expressions and works from there.
It's more advanced than, but similar advantages to, the 4GL I wrote as it
combines best properties of static typing, dynamic productivity, macros, and C
support. Underlying LISP that enables that is only about 1,000loc to implement
IIRC.

So, that's my thinking. I also thought of implementing the tool in MLton, too,
but such things are even easier when your tooling and language makes
extractions trivial. ;)

------
vosper
> A long-term goal is to make proof assistants into trustworthy and practical
> program development and implementation platforms. The CakeML compiler
> verification is an example of proof-assistant-based development;
> specifically, of proven-correct synthesis of machine code from higher-order
> logic specifications.

Is CakeML intended to be used to make things, or is it more of a proof of
concept?

~~~
gillygize
"practical program development" implies that it is intended to make things and
is not just proof of concept, no?

~~~
vosper
I read it as they're talking about making proof assistants practical one day,
and CakeML is a step on the road to that goal. If they then move onto the next
step, where does that leave CakeML?

------
Ericson2314
I'm sorry, but why do people still use HOL? It seems so much more annoying
than type-theoretic approaches (Coq/Agda/Idris/Lean). [Cool work judging from
the title nevertheless.]

~~~
mafribe
HOL is a classical rather than constructive logic.

Moreover, there is less concern about soundness of the logic.

~~~
dtornabene
Could you post some links on the soundness comment? I share a fellow siblings
comment of a little skepticism? But I'm neither a professionally nor scholarly
logician, though I've read and owned (a couple of times) Van Heijenoorts From
Frege to Godel, so feel free to throw some meat my way if you follow up with
this comment.

~~~
mafribe
Well-developed proof assistants like Coq and Isabelle/HOL are the current
pinnacle in scientific rigour. But soundness of a foundational system is
always a worry and will always remain so. By Goedel's 2nd incompleteness
theorem, you cannot verify absolute soundness.

This is true for HOL just as for CoC/MLTT.

However, Coq, Agda etc have a much more expressive logic, which is less well
understood, and I think a couple of genuine logical breakdowns have been found
over the years in Coq and Agda, see e.g. [1, 2, 3], but they could all be
fixed. (I'm not following the development closely, but I think the Coq/HoTT
implementation even seems to require patching Coq to disable critical checks.)
I don't think that the HOL tradition has had to revise logical foundations.

[1] [https://sympa.inria.fr/sympa/arc/coq-
club/2013-12/msg00119.h...](https://sympa.inria.fr/sympa/arc/coq-
club/2013-12/msg00119.html)

[2] [https://sympa.inria.fr/sympa/arc/coq-
club/2014-01/msg00036.h...](https://sympa.inria.fr/sympa/arc/coq-
club/2014-01/msg00036.html)

[3]
[https://coq.inria.fr/cocorico/CoqTerminationDiscussion](https://coq.inria.fr/cocorico/CoqTerminationDiscussion)

~~~
dtornabene
this is fascinating! Thank you so much! I had no idea that the logic for Coq
was more expressive, I can understand quite clearly how that can lead to
breakdowns. I'm just slowly returning to this stuff through haskell.

Heady stuff, that second mailing list post.

------
julian_1
Awesome. If anyone knows about this project - how easy would would it be to
re-target the backend code generator for something other than x86 or ARM?

~~~
sanxiyn
It's reasonably retargetable. If you look under compiler/targets in the
repository, you will find MIPS and RISC-V backends.

