all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Brett Gilio <brettg@posteo.net>
To: Jack Hill <jackhill@jackhill.us>
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 21:48:54 -0600	[thread overview]
Message-ID: <87mubry5ll.fsf@posteo.net> (raw)
In-Reply-To: <alpine.DEB.2.20.1912161745450.11560@marsh.hcoop.net> (Jack Hill's message of "Mon, 16 Dec 2019 18:04:40 -0500 (EST)")

Jack Hill <jackhill@jackhill.us> writes:

> 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.

I am glad you say this. We all have a lot to learn from each other here.

> 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.

Absolutely! This is the kind of thesis I was proposing, and something
that I wonder what Julien will think of as far as benefits particular
and specific to the formal methods community.

>> 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

So far this idea has garnered the most attention. Amin Bandali and I are
both wanting to see this be taken to the next level, with maybe the
support of Janneke and other people working with minimal compilers /
formal methods in their day-to-day work. See some of my previous emails
to others about why I think this is important work. Basically, as I
mentioned to Ludo' the situation of bootstrapping ML from source is
occluded after 1993. We should reasonably be able to remedy this in
order to facilitate ML-based proof assistant development and use on
Guix. Especially things like the PRLs (NuPRL, RedPRL, JonPRL) which
offer nice dependent type systems. But first the compiler tower needs to
be there."

Maybe we could borrow some inspiration from miniML (mentioned by
Julien), CakeML (mentioned by Simon), or C Minor? I don't know. But I
think this is an important task.

> Thanks for proposing the idea!
>
> All the best,
> Jack

Thank you for voicing your support Jack! :)

-- 
Brett M. Gilio <brettg@posteo.net>
GNU Guix, Contributor <https://guix.gnu.org/>

  parent reply	other threads:[~2019-12-17  3:49 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
2019-12-17  1:33   ` John Soo
2019-12-17  3:49     ` Brett Gilio
2019-12-17  3:48   ` Brett Gilio [this message]
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=87mubry5ll.fsf@posteo.net \
    --to=brettg@posteo.net \
    --cc=bandali@gnu.org \
    --cc=guix-devel@gnu.org \
    --cc=jackhill@jackhill.us \
    --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.