Philip McGrath schreef op ma 27-12-2021 om 13:38 [-0500]:
> Hi!
> 
> Just as a general disclaimer, I'm a Racketeer and only incidentally a 
> Schemer, so I'm not very familiar with the universe of Guile libraries.
> 
> On 12/23/21 01:59, Maxime Devos wrote:
>  > Philip McGrath schreef op wo 22-12-2021 om 23:25 [-0500]:
>  >> G-expressions currently do not consistently preserve the distinction
>  >> between #nil and '(), which causes trouble for programs that rely on
>  >> that distinction. In particular, the issue affects programs that use
>  >> (guix build json), because that library uses #nil to represent the JSON
>  >> value `null', whereas it uses '() to represent an empty JSON array.
>  >
>  > The constant #nil is only for elisp compatibility and not something
>  > supposed to be used in Scheme code that isn't for Scheme/elisp
>  > compatibility, so this seems more a bug in (guix build json) to me.
> 
> That was not the impression I had gotten from `info "(guile)Nil"`. For 
> example, I think someone who wanted to finish the implementation 
> described in `info "(guile)ECMAScript"` might want to use #nil for one 
> of the false-y ECMAScript values to take advantages of the documented 
> efficiencies in its bit-level representation. More concretely, 
> guile-json@1 and guile-json@3 use #nil in the same way as (guix build json).

There is

‘Guile has chosen to support ‘nil’ as a separate value, distinct from
‘#f’ and ‘'()’.  This allows existing Scheme and Elisp code to maintain
their current semantics.  ‘nil’, which in Elisp would just be written
and read as ‘nil’, in Scheme has the external representation ‘#nil’.’

and

‘This decision to have ‘nil’ as a low-level distinct value facilitates
interoperability between the two languages.  Guile has chosen to have
Scheme deal with ‘nil’ as follows: [...]’

and this is only documented under ‘Emacs Lisp’, though this doesn't
explicitely say it's not supposed to be used elsewhere.

Also, see e.g.
<https://lists.gnu.org/archive/html/guile-devel/2017-05/msg00017.html>.

Anyway, this doesn't really matter here, because:

> So, I agree that:
> 
> On 12/25/21 06:13, Maxime Devos wrote:
> > That said, it would be less surprising if the #nil/() distinction is
> > preserved by gexp->derivation and friends. This can be done by writing
> > our own 'write' procedure. Downside: it might be less efficient than
> > Guile's write which is implemented in C. Can be resolved by writing our
> > own 'write' procedure in C.
> [...]

I'll try to look into other parts of your response later.

Greetings,
Maxime.