
Coq-based synthesis of Scala programs which are correct-by-construction [pdf] - pharrington
https://cedric.cnam.fr/fichiers/art_4027.pdf
======
tehmillhouse
If you're interested in this kind of thing, note that Coq can also extract
code in Haskell, Scheme and OCaml.

If Coq's not quite your cup of tea, Isabelle/HOL is another proof assistant
with amazing (dare I say superior?) tooling and automation, and it supports
code extraction in SML, OCaml, Haskell and Scala.

Microsoft Research's Lean theorem prover is also promising in this regard.
Work is almost complete on native code compilation (via C code extraction),
allowing you to compile all the constructions you can formalize in Lean
directly to native code. (see
[https://github.com/leanprover/lean/pull/1241](https://github.com/leanprover/lean/pull/1241)
for progress)

(Note that none of those code extractors are verified to be correct
themselves, lacking a formalization of the target language's semantics. You
don't get a mathematical proof that the code you're running does what you
specified, but you get _pretty damn close_.)

~~~
unboxed_type
>Note that none of those code extractors are verified to be

>correct themselves, lacking a formalization of the target

>language's semantics.

CertiCoq project aims to provide a certified compiler from Coq into CLight
(formalized subset of "Safe C"). In this respect,

it is superior to what you have mentioned, I guess.

Offtopic: Lean's effort seems strange to me. Usage of C++ as its
implementation language gets me really nervous,

I feel doubt in its reliability.

~~~
hardlianotion
What is acceptable to use in your view? In my own, if you don't like C++, you
can't like Scala much and I am a fan of both

~~~
lmm
I don't think they're that similar? I dislike C++ because of its large amount
of unsafe constructs and huge number of special-cased language-level features;
I like Scala because it's the most practical language I've found for writing
safe enough code and because the core language is quite small, with many
features moved out into libraries or patterns of combining simpler features.

~~~
hardlianotion
They are both multi-paradigm languages with plenty of modes of expression.
Both provide sufficient ways to hurt yourself. There are enough Scala
implementation warts to trap the unwary.

edit - in my parent comment I should have restricted scope of the comment to
the use of the language for this purpose.

------
pharrington
The source repo is at
[https://github.com/JBakouny/Scallina](https://github.com/JBakouny/Scallina)

------
amelius
I didn't read the paper, but is this restricted to purely functional programs?

~~~
sn9
It's a quick read. Only 2 pages. Not particularly dense and accessible to most
programmers.

------
unboxed_type
I wonder why they have not used Coq's extraction approach?

~~~
gsps
As far as I understand, their approach is exactly that, i.e., another target
language for extraction. Synthesis is a bit of an overloaded term.

~~~
unboxed_type
"The compiler itself is also written in Scala and its underlying Coq parser is
largely based on the use of parser combinators"

while "true" extractor has to be written in Coq, as I understand :-)

~~~
nickpsecurity
When I read that, I thought "What a huge TCB versus what's typical."
Additionally, there exist verified strategies for parsing that _might_ be
applicable to Scala. Depends on if their formalisms can handle the language's
grammar or whatever. Additionally, if they write untrusted parts in ML, they
can supplant it with stuff like property-based testing or CakeML compiler.

------
mathgenius
It seems like this is the sort of thing that blockchain languages should be
built on top of. Things like Etherium.

~~~
carterschonwald
Working on something like this for work.

