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

[Philip McGrath <philip@philipmcgrath.com>]

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