[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: How did you handle making a GNU/Linux distribution?
From: |
zimoun |
Subject: |
Re: How did you handle making a GNU/Linux distribution? |
Date: |
Tue, 24 Aug 2021 12:24:43 +0200 |
Hi Philip,
On Mon, 23 Aug 2021 at 13:30, Philip McGrath <philip@philipmcgrath.com> wrote:
> On 8/23/21 11:38 AM, zimoun wrote:
>> The bootstrap path of Racket in Guix is not clear to me. I miss if a
>> Racket interpreter or compiler in its binary format is used (as
>> Haskell for instance) or if all is compiled from source using tools
>> already bootstrapped. Anyway, I miss what you would like bootstrap?
>> If you mean a trusted seed in order to start a package collection, you
>> could use the current Guix binaires---as a starting point.
>
> I wrote a long comment at the top of gnu/packages/racket.scm that
> explains the current state of affairs. (For anyone unfamiliar with the
> Guix source tree:
> <https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/racket.scm>)
Oh sorry! I did incorrectly my homework… although I remember the
discussion with Ludo when you submitted the patch set. :-)
> In brief, Racket is bootstrapped from source using only a C
> compiler---including bootstrapping Racket's fork of Chez Scheme without
> an existing Chez Scheme compiler---with one exception: the "expander"
> subsystem (which implements the reader, module system, and macro
> expander) is implemented in Racket, and the older C implementation was
> completely replaced as of Racket 7.0. (One of the motivations was to fix
> many problems with the old implementation.) For bootstrapping, an
> intermediate representation as a "schemified" linklet is checked into
> the Racket source repository.
Thanks for explaining. All is clear.
> This impact is mitigated because, by design, the intermediate
> representation is "human-readable and -editable Scheme code".
> Anecdotally, when I read diffs of changes to the Racket repository, I
> sometimes read tens of lines of code before I realize that I'm looking
> at the generated version of the file, not the source. So the expander is
> not bootstrappable in the most rigorous sense, but it is readily auditable.
>
> If someone wanted to tie the knot, the task would be to use an existing
> bootstappable language to write a minimal expander that can expand the
> canonical Racket implementation: if your output is identical to the
> checked-in generated files, you've succeeded. (Using Guile could avoid
> the heavy maintenance burden of the old C expander implementation, and
> indeed you could write just enough of an adapter to load the Racket
> source files into Guile, which is the technique Racket uses to bootstrap
> the Chez Scheme compiler.) I expect Racket would welcome a contribution
> along those lines; it just hasn't been a priority for anyone yet.
Guile everywhere! ;-)
Thanks again the details.
Cheers,
simon