GNU bug report logs - #53878
[PATCH 00/11] Update Racket to 8.4. Adjust Chez Scheme

Previous Next

Full log

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

From: Philip McGrath <philip <at> philipmcgrath.com>
To: Liliana Marie Prikler <liliana.prikler <at> ist.tugraz.at>,
 53878 <at> debbugs.gnu.org
Subject: Re: [PATCH 07/11] gnu: chez-scheme: Explicitly package bootstrap
 bootfiles.
Date: Thu, 17 Feb 2022 03:06:28 -0500

Hi,

On 2/17/22 02:10, Liliana Marie Prikler wrote:
> Hi,
> 
> Am Mittwoch, dem 16.02.2022 um 16:13 -0500 schrieb Philip McGrath:
>> Hi,
>>
>> On 2/14/22 09:54, Liliana Marie Prikler wrote:
>>> Am Sonntag, dem 13.02.2022 um 16:51 -0500 schrieb Philip McGrath:
>>>> This might seem a bit silly in isolation, but it makes the
>>>> structure of the upstream Chez Scheme package the same as for the
>>>> Racket variant, it sets things up for (one day, hopefully)
>>>> actually being able to bootstrap the upstream Chez Scheme
>>>> bootfiles, and it may be useful for cross-compilation and adding
>>>> support for architectures without pre-built bootfiles from
>>>> upstream.
>>>>
>>>> * gnu/packages/chez-and-racket-bootstrap.scm
>>>> (chez-scheme-bootstrap-bootfiles): New variable.
>>>> (chez-scheme)[native-inputs]: Add it.
>>>> [arguments]: Add new phase 'unpack-bootfiles'.
>>>> [version, source, home-page]: Derive from 'chez-scheme-bootstrap-
>>>> bootfiles'.
>>>> ---
>>> While having chez-scheme-bootstrap-bootfiles (silly name) does make
>>> some kind of sense, making chez-scheme inherit from it does not.
>>> Given that we don't have a chez-scheme bootstrap tower at hand, you
>>> should probably make (chez-scheme-bootstrap) a procedure which
>>> takes chez-scheme's origin as argument and returns the full
>>> package.
>>>
>> Making a function is an interesting idea, but I'm not sure I'm quite
>> picturing what you have in mind. I will see if I can figure out
>> something that seems reasonable as I revise this series, if I don't
>> hear from you before then.
> I was picturing something like
> 
> (define chez-bootfiles (chez ...)
>    (package/inherit chez
>      (inputs ...)
>      (native-inputs ...)
>      (build-system ...)
>      (arguments ...)))
> 

Sorry, I still don't think I'm following. Would this rely on the 
`mative-inputs` being thunked to let the result of this function be an 
input to `chez-scheme`? What commonality is the function abstracting 
over, compared to having 'chez-scheme-for-racket-bootstrap-bootfiles' 
inherit from 'chez-scheme-bootstrap-bootfiles'?

(I'm using "-bootstrap-bootfiles" because there are also other kinds of 
bootfiles: applications can create their own bootfiles, e.g. 
"racket.boot", and using Chez as a cross-compiler also involves more 
bootfiles.)

>> Is there a technical reason to prefer either repeating the home page,
>> license, etc. or writing e.g. `(package-license
>> chez-scheme-bootstrap-bootfiles)` rather than using inheritance?
> You should not write (package-license chez-scheme-bootstrap-files),
> that's the point!  For one, that's exactly what inheritance would do
> unless you specify the field (technical reason), but more importantly,
> as a reader, using (package-license this-other-chez-thing) sends me on
> a journey to track down this-other-chez-thing while determining the
> license of chez!  That's just silly (social reason).

That makes some sense with respect to the license and home page, but 
what about 'package-source' and 'package-version'?

-Philip

Previous Next

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