[bug#53878] [PATCH v3 09/15] gnu: Add racket-vm-cgc.

[Liliana Marie Prikler]

Hi,

Am Mittwoch, dem 23.02.2022 um 13:55 -0500 schrieb Philip McGrath:
> To try to be concrete, I made the patch below as a mock-up of part of
> your earlier suggestion (IIUC):
> 
> On 2/20/22 04:03, Liliana Marie Prikler wrote:
>  > Inside chez-and-racket-bootstrap, define (make-<package>)
> functions for
>  > the following:
>  > - chez-bootstrap-bootfiles, chez-for-racket-bootstrap-bootfiles:
>  >    Taking version and origin.
>  > - racket-vm-cgc: Taking version and origin.
>  > - racket-vm-bc: Taking racket-vm-cgc.
>  > - racket-vm-cs: Taking racket-vm-bc.
> 
>  > Inside racket, define %racket-version, %racket-origin, racket-
> minimal
>  > and racket.  It'd also be good if you made local definitions
>  > (define racket-vm-cgc (make-racket-vm-cgc %racket-version %racket-
>  > origin))
>  > (define racket-vm-bc (make-racket-vm-bc racket-vm-cgc))
>  > ...
>  > in this file.
> 
> This applies on top of v4, or I've put it at 
> <
> https://gitlab.com/philip1/guix-patches/-/commit/982fe7cfb4d33103ee611acc310e3225ccf35852
> >
> if that's easier for anyone:
To be fair, the issue here is with my proposal, which doesn't
completely thunk through.  I clarified later on that it would need
another pair of brackets or – if that's easier for you – commented on
the commit you've linked.

> Overall, I certainly agree that duplicating the definition of 
> `%racket-version` is not ideal. I'd be glad for you or anyone to
> improve the situation, and I'll try to get my head around Maxime's
> email about the underlying semantics.
> 
> But I am confident that v4 of this series is at least not broken, if 
> perhaps not maximally beautiful. Especially given that I, for one,
> have tried things that initially seemed correct only to discover
> subtle problems later, I think it would be better for any refinements
> to come in follow-on patches later.
I can understand the sentiment, but there are some things that still
don't feel right for me – for instance the fact, that seemingly
unrelated modules now have to pull in racket bootstrap sounds like a
recipe for trouble.  The final patch in the series also still does too
much for me to wrap my head around, which makes it difficult to audit.

Therefore, one question I have w.r.t. updating Racket is whether we
could theoretically bump the version while keeping the old bootstrap,
and then adjust the bootstrap by adding all the packages you've made. 
It does seem to be an all or nothing deal when doing the bootstrap
first, but that need not necessarily hold for bootstrap second.

Also, accepting for a moment that we might have to move chez-scheme and
other important things into chez-scheme-and-racket-bootstrap (even
though I'm not really content with it), I still wonder if we could
introduce chez-scheme-for-system first (defined as simply chez-scheme
initially) and adjust the callers, then move chez-scheme while keeping
the function in chez.scm and finally do the magic with making it either
chez or racket.

I know I have a tendency towards being overly cautious when it comes to
pushing big changes, so if that's the case I'd be happy if someone else
were to take over.  That said, I do feel somewhat lonely at the moment
despite the many people specifically mentioned in "To:" and "Cc:", so
I'm somewhat content with moving slowly for now.

Cheers