From: Jack Hill <jackhill@jackhill.us>
To: Brett Gilio <brettg@posteo.net>
Cc: guix-devel@gnu.org, leo.prikler@student.tugraz.at, bandali@gnu.org
Subject: Re: [Proposal] The Formal Methods in GNU Guix Working Group
Date: Mon, 16 Dec 2019 18:04:40 -0500 (EST) [thread overview]
Message-ID: <alpine.DEB.2.20.1912161745450.11560@marsh.hcoop.net> (raw)
In-Reply-To: <87tv616q5s.fsf@posteo.net>
[-- Attachment #1: Type: text/plain, Size: 4604 bytes --]
Greetings,
On Sun, 15 Dec 2019, Brett Gilio wrote:
> Hello Guix!
>
> This is going to be a rather lengthy email proposing a new working group
> (if that is indeed the proper name for this) in the GNU Guix
> project. Just as there are other "working groups" for GNOME packages,
> bootstrapping Rust & JVM, and bootstrapping the entirely of the GNU
> Corelibs (GNU Mes) in Guix, I am proposing a new working group based on
> the synthesis of two fundamentally and mutually agreeable concepts.
>
> This is a continuation of the discussion proposed by Amin Bandali, Leo
> Prikler, and I from the #guix Freenode IRC. All three of us are either
> students of formal methods in mathematics and computer science, users of
> proof assistants, or interested in category theory and type theory. As
> such as noticed and wondered what kind of community there is for formal
> methods in GNU Guix, and by extension what kind of benefits GNU Guix has
> to offer the formal methods community which is providing some of the
> most rigorous research in computing methods to date.
[…]
> Having Guix and the Formal Methods community aligned would mean a great
> deal of power for both camps! Just as we see with the Software Heritage
> project and Guix, for providing historical and state-consistent
> reproducible environments for software testing we and correspond to
> formal methods much of the same guarantees of deterministic
> computational states, modeling, and reasoning in software correctness.
I'm not a formal methods researcher, but merely a hobbyist who is
interested in programming languages and type system. That said, I find
this proposal intriguing, and would like to follow along, and perhaps
help as I am able. At the very least, I hope to learn some new things.
One of the things that attracted me to Guix is the ability to represent
the pieces as objects in a programming language as opposed the the big
mass of state that is a traditional system. I agree this property of Guix
harmonizes with formal analysis.
[…]
> What follows is proposals for some of the work to be done by this
> working group:
>
> -- A lot of proof assistants are based on dialects of ML. Most of these
> use SMLnj or MLton for their work. To date there is an issue of
> source-based bootstrapping of _all_ of the major ML compilers. We do
> have PolyML in our repositories, but even this uses space-inefficient
> text file blobs for compiling and is not a fully C-based source
> bootstrap. Basically, all of the ML compilers rely on some distinct
> pre-compiled something-or-other to get to their pristine state. I
> have explored the idea, along with Leo and Amin, about following in
> the tradition of MES (and mrustc) and starting an analogous GNU project for
> writing a reduced-size specification ML bootstrapping compiler. That
> way we can end the loop of a source-based build of ML97 compilers
> being basically impossible.
> [See issues #38605 & #38606 on DEBBUGS. Also, see
> https://github.com/MLton/mlton/issues/350.]
This is the sub-area I'm most interested in. In addition to ML, I'd also
like to be able to bootstrap GHC. I know that Ricardo has done some work
in that area [0].
[0] https://elephly.net/posts/2017-01-09-bootstrapping-haskell-part-1.html
> -- Begin adding more projects that are important works in the formal
> methods community. We have Coq, Idris, and Agda, but there is a lot of work
> to be done on keeping these projects not only up-to-date but also
> adding subprojects that use these toolchains. For example: C Minor,
> Metamath, Ynot, Formally verified Featherweight Scala, RustBelt,
> RedPRL, NuPRL, JonPRL, HOL/Isabelle, F*, kreMLin, CakeML, tons of
> various type checkers based on OCaml, Alloy, Frama-C, TLA+, Liquid
> Haskell, extensions to Z3, and tons more!
I would love to have more tools like these in Guix, so that we can use
Guix's repoducibility guarantees to have them as part of the historical
record.
> All of this seems really nice and impressive, but what is it without
> getting some feedback from the community? I'd _really_ love to hear your
> thoughts, experiences, and more on this working group idea and other
> working groups to avoid pitfalls. Maybe we should have a secondary
> #guix-fm channel on IRC? There is definitely a lot of work to be done
> here, and we will need some form of organizational structure to keep the
> work consistent and neatly integrated with the goals and purposes of GNU
> Guix.
>
> I hope to hear from the community.
Thanks for proposing the idea!
All the best,
Jack
next prev parent reply other threads:[~2019-12-16 23:04 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-16 0:59 [Proposal] The Formal Methods in GNU Guix Working Group Brett Gilio
2019-12-16 8:47 ` Julien Lepiller
2019-12-16 9:22 ` Julien Lepiller
2019-12-17 3:29 ` Brett Gilio
2019-12-27 18:56 ` Ludovic Courtès
2019-12-27 22:33 ` Brett Gilio
2019-12-27 23:37 ` Ludovic Courtès
2019-12-28 2:59 ` Brett Gilio
2019-12-30 21:34 ` Ludovic Courtès
2019-12-31 10:17 ` Brett Gilio
2020-01-02 22:11 ` Ludovic Courtès
2020-01-03 23:49 ` Amin Bandali
2020-01-15 21:59 ` Ludovic Courtès
2020-01-13 19:27 ` Maxim Cournoyer
2019-12-28 7:20 ` Amin Bandali
2019-12-28 11:28 ` Vicente Eduardo
2019-12-29 8:09 ` Jan Nieuwenhuizen
2019-12-17 3:27 ` Brett Gilio
2019-12-16 19:46 ` zimoun
2019-12-16 20:10 ` Julien Lepiller
2019-12-17 3:40 ` Brett Gilio
2019-12-27 23:56 ` Ludovic Courtès
2019-12-28 2:55 ` Brett Gilio
2019-12-17 3:38 ` Brett Gilio
2019-12-16 23:04 ` Jack Hill [this message]
2019-12-17 1:33 ` John Soo
2019-12-17 3:49 ` Brett Gilio
2019-12-17 3:48 ` Brett Gilio
2019-12-21 6:48 ` Amin Bandali
2019-12-21 23:59 ` Brett Gilio
2019-12-28 0:02 ` Ludovic Courtès
2019-12-27 23:54 ` Ludovic Courtès
2019-12-28 3:06 ` Brett Gilio
-- strict thread matches above, loose matches on Subject: below --
2020-01-23 19:17 Alexandru-Sergiu Marton
2020-02-12 12:02 Orians, Jeremiah (DTMB)
2020-02-12 14:16 ` zimoun
2020-02-12 14:38 ` Svante Signell
2020-02-12 14:48 ` Jan Nieuwenhuizen
2020-02-12 20:59 ` Bengt Richter
2020-02-13 12:13 ` Orians, Jeremiah (DTMB)
2020-02-13 12:07 ` Orians, Jeremiah (DTMB)
2020-02-15 16:10 ` zimoun
2020-02-18 11:17 ` Orians, Jeremiah (DTMB)
2020-02-21 14:47 ` zimoun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.20.1912161745450.11560@marsh.hcoop.net \
--to=jackhill@jackhill.us \
--cc=bandali@gnu.org \
--cc=brettg@posteo.net \
--cc=guix-devel@gnu.org \
--cc=leo.prikler@student.tugraz.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.