[bug#55248] [PATCH v3 8/9] gnu: chez-scheme-for-racket: Fix supported systems.

[Philip McGrath]

Hi,

On 5/9/22 05:36, Liliana Marie Prikler wrote:
> Hi,
>
> Am Montag, dem 09.05.2022 um 03:55 -0400 schrieb Philip McGrath:
> > Concretely, there are no other uses in Guix.
> >
> > I do not know a robust, correct way to use
> > 'nix-system->chez-machine'---certainly not without it growing many
> > additional features, like maybe computing endianness for pbarch
> > backends when we are able to build them. For example, if we continued
> > using it as we did in 'stex', you couldn't build a package graph for
> > nonthreaded Chez simply by applying a package transformation to
> > remove '--threads' from its '#:configure-flags', because that would
> > change the machine type without updating the uses of 'nix-system-
> > > chez-machine'.
> True, you would have to change the machine type, but I think I already
> noted that we might want to use this machine type as a distinguishing
> factor in packages built on top of chez (and later chez-build-system
> perhaps).  You could do this the other way round by deriving flags from
> the given machine-type, e.g. stex for threaded chez machine is given --
> threads, otherwise it's not.  Since we have named symbols for these
> features, we could have a "package-with-chez-features" or similar
> transformer.  Being able to specify this machine is a strength, not a
> weakness.

I can imagine something like this might be useful eventually. My problem 
is that, right now, 'nix-system->chez-machine' is an attractive 
nuisance: it sounds useful, but I don't know any way of using it that 
wouldn't be subtly wrong. I don't even feel certain even about what 
cases 'nix-system->chez-machine' would need to cover to be correct and 
useful: a fair amount seems to depend on what turns out to be necessary 
for cross-compilation and the portable bytecode architectures (which I 
hope to work out by July).


> > The idea is that the "portable bytecode" backends should work,
> > including thread support, on any system with a reasonably capable C
> > compiler.
> The idea.  In practice, what racket deems reasonably capable can change
> over time and might result in them dropping some architectures
> currently supported.  What do you do then?

I mean, "over time", at the extreme, anything "might" happen, but I 
don't think that's worth worrying about. Racket has an extremely strong 
commitment to backwards compatibility. To pick one example, support 
libraries for racket/draw and racket/gui are still maintained for 
ppc-macosx, which the vendor hasn't released any software for in a 
decade or more (depending on how you prefer to count). The C code 
deliberately does not require C99 support.

>> The presence of an entry in '%chez-features-table' explicitly means
>> that 'chez-scheme-for-racket' can generate native code.
> That is not explicit at all.  There might be an explicit comment
> stating so somewhere, but in terms of actual code, it's super
> implicit.
>

> > There are no other "features" that vary among systems for
> > 'chez-scheme-for-racket'. It doesn't rely on pre-built bootfiles for
> > bootstrapping.  Since the initial fork at the beginning of 2017, when
> > support for new systems has been added, native threads have been
> > supported immediately. Racket regularly merges all changes from
> > upstream Chez (which has not added any supported systems during that
> > time---not even the systems added already in Racket's variant).
> I'd still make "supported-by-racket" or however else you decide to name
> that feature an explicit part of that table rather than an implicit
> one, or use a separate "table" for platforms supported by racket.

I really don't understand how this would be helpful. I don't think it 
would make sense for a list returned by 
chez-upstream-features-for-system to include a symbol 
supported-by-racket, which has nothing to do with *upstream* features. 
Aside from that, we would be adding this symbol to every single entry in 
%chez-features-table. That would imply turning all of the #f entries 
into (supported-by-racket), and then we would need some other solution 
for identifying platforms with no support upstream.

>  Note
> that none of the racket-vm packages appear to currently carry
> supported-systems, which seems dubious.

The only constraint on the systems supported by 'racket-vm-cs' is from 
'chez-scheme-for-racket'---i.e., the trouble with `configure` for 
systems without a native-code backend, which should be fixed by the next 
release, if not before. I expect the fact that the 
'chez-scheme-for-racket' input is not supported to work as an 
alternative to duplicating the filtering in its supported-systems field 
(which I think would create a cyclic dependency issue).

AFAIK, 'racket-vm-cgc' and 'racket-vm-bc' should work everywhere (though 
possibly without the JIT, futures, and/or places) except that support 
for aarch64-macosx is prohibitively poor (IIUC due to W^X issues), which 
is fairly irrelevant for Guix.

-Philip