[bug#49280] [PATCH v2 0/3] gnu: racket: Update to 8.2. Bootstrap from C.

[Ludovic Courtès]

Hi Philip,

Sorry for the delay and thanks for the explanations!  Comments/answers
follow.

Philip McGrath <philip@philipmcgrath.com> skribis:

> On 7/8/21 5:25 PM, Ludovic Courtès wrote:
>> Philip McGrath <philip@philipmcgrath.com> skribis:
>> 
>>> * gnu/packages/racket.scm (racket-next-minimal,racket-next): New variables.

[...]

>> For this there’s already a documented convention (info "(guix)
>> Package
>> Naming"), although part of it is undocumented.  The prefix would rather
>> be “racket-” to match what we do with other packages–“ghc-”, “ocaml-”,
>> “guile-”, and so forth.
>
> I wrote these as statements in the hope of eliciting any disagreement :)
>
> The problem I see with using just “racket-” as the prefix is the
> potential for collisions, especially because Racket uses a lot of the 
> namespace: for example, "_" is a useful example package for testing
> package issues, and I maintain the "_-exp" package. There don't seem
> to be Racket packages named "minimal" or "next" right now, but they
> seem reasonably likely to be used in the future, and Guix likewise may
> want to add packages that don't correspond directly to a single
> Racket-level package. (In fact, I think this may be necessary to build
> Racket packages with mutually recursive dependencies.) Other Racket
> package names that I think might be less confusing if prefixed with 
> “racket-pkg-” include "base", "racket-lib", "unstable", "profile",
> "make", "data", "images", "compiler", "compatibility", "pkg-build",
> and "main-distribution".

I would not worry too much about name collisions.  After all, we have
18K packages and a great potential for collisions already.  :-)
We can deal with a hypothetical “next” Racket package when it comes into
existence.

> But we don't need to resolve this now, and maybe actually implementing
> that support will clarify what issues really do or don't exist. I will 
> just remove this whole comment for now, since I don't need to make a
> choice between "racket-next-minimal" and "racket-minimal-next".

Either way is fine with me.  :-)

> In addition to bootstrapping, there are three reasons I know of to
> want Racket BC:
>
>  1. The BC and CS implementations have different C APIs, so some
>     low-level code may support BC but not CS. But this isn't usually a
>     good reason. Racket packages should support both implementations.
>     Embedding applications ideally would also be portable: if it's
>     only feasible to support one implementation, it should be CS.
>
>  2. Comparing the BC and CS implementations can be useful for testing
>     and debugging, both for packages that use the FFI and when hacking
>     on the Racket runtime system itself.
>
>  3. Most importantly, BC supports some architectures that CS does not.
>
> In particular, Racket CS does not (yet) support ppc64le, which Racket
> BC does support. The recommendation to packagers, and what Debian
> does, is
> to explicitly use BC on platforms without CS support:
> https://github.com/racket/racket/issues/3773#issuecomment-832935403
>
> I'm not sure what the most idiomatic way to do this is in Guix.

Once we have a ‘racket-build-system’, it could pick the right Racket as
a function of the target system.

Otherwise we could do a trick of the sort we have for ‘pkg-config’, but
I’d rather avoid that.

Thanks,
Ludo’.