Re: How did you handle making a GNU/Linux distribution?

[zimoun <zimon.toutoune@gmail.com>]

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