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

Hi,

On 2/20/22 13:13, Liliana Marie Prikler wrote:
>> Given Ludo’'s explanation, I think the difference (or at least an
>> important difference) is that those functions are defined in `(guix
>> ...)` modules, as  opposed to `(gnu packages ...)` modules.
>>
>> But I wish I knew with any degree of certainty *why* this would be
>> true, if indeed it is.
>>
>> Maybe Maxime knows?
> Both Ludo and Maxime already explained this, but to be extra clear,
> it's the thunking.
> 
> (define foo <something-in-bar.scm>)
> (define bar <something-in-foo.scm>) <- problem
> 
> (define (foo) <something-in-bar.scm>)
> (define bar <something-in-foo.scm>) <- no problem.
> 
> Since inputs are thunked, you can define chez in chez.scm and racket in
> racket.scm and use them as input to each other without breaking the
> compiler (you will break the package builder though).  If you want
> something more meaningful, you can define racket-minimal in racket.scm
> and use it in chez.scm as input to a package, then use that package as
> input to racket.  This does not work for (source ) and (inherit )
> however, because those forms are not thunked.  You would have to thunk
> them until you reach a save haven (like a package's inputs), where you
> can call the thunk to produce a value.

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:

--8<---------------cut here---------------start------------->8---
 From 982fe7cfb4d33103ee611acc310e3225ccf35852 Mon Sep 17 00:00:00 2001
From: Philip McGrath <philip@philipmcgrath.com>
Date: Wed, 23 Feb 2022 11:13:43 -0500
Subject: [PATCH] example of import problems

---
  gnu/packages/chez-and-racket-bootstrap.scm | 4 ++++
  gnu/packages/racket.scm                    | 3 +++
  2 files changed, 7 insertions(+)

ORIGIN into
  a new file-like object.  In the resulting file-like object, the 
package source
  

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
  

Hi Liliana,

Thanks Philip for these large series.

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

Sorry, I am running out of time and the series is quite large; the
changes are not really atomic. ;-)


On Wed, 23 Feb 2022 at 21:31, Liliana Marie Prikler
<liliana.prikler@gmail.com> wrote:

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

I understand both sentiments.  I also have some difficulties for
auditing the series.  Well, it needs some time to sit down, fill the
coffee pot and careful review. :-)

I cannot promise but I will try to give a look next week; for what my
reviewing eyes are worth.

Cheers,
simon