GNU bug report logs - #55248
[PATCH 0/7] gnu: Update Racket to 8.5 and Chez Scheme to 9.5.8.

Previous Next

Full log

Message #158 received at 55248 <at> debbugs.gnu.org (full text, mbox):

From: Liliana Marie Prikler <liliana.prikler <at> ist.tugraz.at>
To: Philip McGrath <philip <at> philipmcgrath.com>, 55248 <at> debbugs.gnu.org
Cc: Maxime Devos <maximedevos <at> telenet.be>,
 Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Subject: Re: [PATCH v3 8/9] gnu: chez-scheme-for-racket: Fix supported systems.
Date: Mon, 09 May 2022 11:36:23 +0200

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.

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

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

> 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.  Note
that none of the racket-vm packages appear to currently carry
supported-systems, which seems dubious.

> These conditions are documented in the comments on '%chez-features-
> table'. 
See above.


Cheers

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.