[bug#53878] [PATCH 04/11] gnu: chez-and-racket-bootstrap: Add utilities for Chez machine types.

[Liliana Marie Prikler]

Hi,

Am Sonntag, dem 13.02.2022 um 16:51 -0500 schrieb Philip McGrath:
> [...]
> +(define (chez-machine->upstream-restriction mach)
> +  "Given a string MACH naming a Chez Scheme machine type, returns a
> symbol
> +naming a restriction on the upstream Chez Scheme implementation
> compared to
> +the Racket variant, or @code{#f} if no such restriction exists.  The
> +restriction is reported for the architecture--OS pair, regardless of
> whether
> +MACH specifies a threaded or an unthreaded variant.
> +
> +Possible restrictions currently include:
> +@itemize @bullet
> +@item
> +@code{'no-threads}: Support for native threads is not available
> upstream.
> +@item
> +@code{'no-support}: The upstream release doesn't claim to support
> this
> +architecture--OS combination at all.
> +@end itemize
> +
> +See @code{chez-machine->nix-system} for more details about
> acceptable values
> +for MACH."
> +  (let ((mach (chez-machine->unthreaded mach)))
> +    (cond
> +     ((string-prefix? "arm64" mach)
> +      'no-support)
> +     ((string-prefix? "arm32" mach)
> +      (if (string-suffix? "le" mach)
> +          'no-threads
> +          'no-support))
> +     ((string-prefix? "ppc32" mach)
> +      (if (string-suffix? "le" mach)
> +          #f
> +          'no-support))
> +     (else
> +      #f))))
-> is a conversion operator, not an "accessor".
"upstream-restriction" sounds rather negative, I'd rather have (chez-
machine-features), which yields #f if the machine is unsupported and a
(possibly empty) list of features otherwise, such as '(threads).

I'm also not quite sure what the point is behind using chez machines
here.  Why not simply test the systems with the predicates we already
have, i.e. target-arm64?, target-arm32?, target-linux?, target-ppc32?,
...

And as a minor pet peeve, you ought to spell out machine.


> +(define* (nix-system->chez-machine #:optional (system (%current-
> system))
> +                                   #:key (threads? 'always))
> +  "Return the Chez Scheme machine type corresponding to the Nix
> system
> +identifier SYSTEM, or @code{#f} if the translation of SYSTEM to a
> Chez Scheme
> +machine type is undefined.
> +
> +When THREADS? is @code{'always} (the default), the threaded variant
> of the
> +machine type will be returned: note that the package returned by
> +@code{chez-scheme-for-system} will always support native threads. 
> When
> +THREADS? is @code{#f}, the unthreaded machine type will be
> returned.  If
> +THREADS? is @code{'upstream} (the default), the threaded variant of
> the
> +machine type will be returned if and only if it is supported by
> upstream Chez
> +Scheme (see @code{chez-machine->upstream-restriction}).  If THREADS?
> is any
> +other value, an exception is raised."
What's the point in having THREADS? 'always?  In any case, assuming
chez-machine-features is to be exported, this can easily be checked --
even if not, we can add the check internally by writing 
  #:key (threads? (chez-supports-threads? system))

> +  (let* ((hyphen (string-index system #\-))
> +         (nix-arch (substring system 0 hyphen))
> +         (nix-os (substring system (+ 1 hyphen)))
> +         (chez-arch (assoc-ref %nix-arch-to-chez-alist nix-arch))
> +         (chez-os (assoc-ref %nix-os-to-chez-alist nix-os))
> +         (mach (and chez-arch chez-os (string-append chez-arch chez-
> os))))
This series of let-bindings should probably be done in a separate
function called nix-system->chez-machine.

Cheers