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

[Liliana Marie Prikler <liliana.prikler@ist.tugraz.at>]

Hi,

Am Donnerstag, dem 12.05.2022 um 01:26 -0400 schrieb Philip McGrath:
> > 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. 
Your 6/9 patch imho erases a use that wouldn't have been wrong. 
Certainly not if we add extra features to it or use inference at build
time.

For instance
(let* ((base-system #$(nix-system->chez-machine 
                       (or (%current-target-system) 
                           (%current-system))))
       (threaded? (member "--threads" configure-flags))
       (portable-bytecode? [however you would determine that])
       (actual-machine (string-append ...)))
  [code that uses actual-machine])
would be an alternative if you want actual-machine inferred by compile
options rather than earlier on.

> 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).
From my POV it is already enough if we can do the basic translation
with nix-system->chez-machine.  Additional features like threads or
portable bytecode would be nice to have, but if you feel that it'd be
"subtly wrong" to add them (or not to add them), you can feel free to
add or omit them as you like.

> > 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. 
For one, that procedure would be free to filter features as it needs so
that it doesn't return racket-specific symbols, but more importantly if
you do feel that using this table to report racket support explicitly
is abuse, how is it not abuse if you report it implicitly?

> 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.
If I read this table correctly, there is no entry, that does not have
either 'threads or 'bootstrap-bootfiles.  So null? after filtering
racket features would work.  If this is ever violated, e.g. we find an
arch that has neither bootstrap nor threads, but is still supported by
upstream, we could add an explicit 'basic-upstream-support feature to
the table.

> > 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. 
Let's just assume that to be true.  Even if so, why is "supported by
racket" the condition for which we check rather than "not supported by
upstream"?  Seems kinda counterintuitive if racket supposedly supports
all arches while chez itself does not.

> 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).
You might want to rephrase that sentence.  I have no idea what you're
trying to get across here.


Cheers