[bug#53878] [PATCH v5 00/22] Update Racket to 8.4. Adjust Chez Scheme packages.

[Liliana Marie Prikler]

Hi,

Am Samstag, dem 26.02.2022 um 08:02 -0500 schrieb Philip McGrath:
> Hi,
> 
> I've been ruminating for a while on Liliana's comment
> from <https://issues.guix.gnu.org/53878#118>:
> 
> On Wednesday, February 23, 2022 3:31:34 PM EST Liliana Marie Prikler
> wrote:
> > [...] 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.
> > 
> 
> It struck me that the core of the dependency cycle (at least, from
> one perspective) is that 'chez-scheme-for-racket' wants to 'inherit'
> from 'chez-scheme' but use '%racket-origin' for its 'source', and
> neither of those are thunked fields.
I did realize that too, but perhaps I failed to mention that or didn't
get the point across before this, so pardon me for the extra work you
had to put in that I could have helped avoid.

> I realized that, if we just pass the origin some other way than as
> the 'source' field, we can avoid adding the
> "chez-and-racket-bootstrap.scm" file
> altogether: patch v5 10/22 does the core of that.
I did miss that nugget when I skimmed it first; is there a reason to
prefer overloading unpack and redirecting it to (package-source racket-
vm-bc) over doing the same, but using simply #$%racket-origin?

> I also managed to split up the update to Racket 8.4 (patch v4 15/15)
> into a number of smaller steps (or, more precisely, rewrite it now
> that I knew what the end result would be). I now have the 'racket-
> minimal*' packages gradually evolve into the corresponding 'racket-
> vm-*' packages (rather than adding the 'racket-vm-*' stack in
> parallel), then split the new 'racket-minimal' package
> out of 'racket'. Hopefully this might be somewhat easier to review.
> The downside is there are now 22 patches, rather than 15.
In general, smaller patches = more better.  I really like this series
so far, there's only some cosmetic nitpicks, although for the record I
do have to say that I skipped over many things that felt familiar from
earlier series.

BTW for the record, if you're dropping one of my mails from the CCs,
please make sure to include the gmail account rather than my institute
mail.  This one is technically supposed to be for work and I'm using a
rather loose interpretation of "ensuring that software is up-to-date"
as part of my work when I do comment on Guix issues from it.

I'll now attempt to build racket with this patch and hopefully
encounter no error as I do.

Cheers