bug#21915: write inconsistent about #nil

bug#21915: write inconsistent about #nil

[Zefram]

The write function is inconsistent about whether it distinguishes between
#nil and ():

scheme@(guile-user)> '(#nil . a)
$1 = (#nil . a)
scheme@(guile-user)> '(a . #nil)
$2 = (a)

Thee latter behaviour, emitting #nil as if it were (), breaks the usual
write/read round-tripping, and the traditional correspondence between
equal? and matching of written representation.  Admittedly those standards
are not absolute, nor is the extent to which they're expected to hold
documented, but #nil is clearly sufficiently atomic to be the kind of
value to which one would expect them to apply.  For these reasons,
if a consistent behaviour is to be chosen, I think it should be to
consistently distinguish the values.

I think the behaviour should be consistent.  The values should be
distinguished or not without regard to the context in which they arise
within an s-expression.

Whatever is done, even if it's to endorse the inconsistency, the behaviour
should be documented, with rationale.

-zefram

bug#21915: write inconsistent about #nil

[Taylan Kammer]

Hi Zefram,

this is an interesting issue.  Here's a related one:

  https://bugs.gnu.org/48318

I think first of all #nil and '() should actually be equal?
to each other.  After all, both represent the empty list,
and checking structural equality between lists is one of the
common uses of equal?.

It might also be good, in addition, to make the Scheme writer
write (foo . #nil) as (foo . #nil).  The positive is that it
would make bugs in Elisp compatibility easier to see by not
masking the fact that one has #nil instead of () at the end
of a list.  The only negative I can think of is that it would
be mildly annoying to see (foo bar . #nil) where you expected
to see (foo bar), but I don't think that's ever really harmful.

Thoughts?


- Taylan

bug#21915: write inconsistent about #nil

[Taylan Kammer]

[-- Attachment #1: Type: text/plain, Size: 556 bytes --]

On 14.05.2021 15:34, Taylan Kammer wrote:
> 
> It might also be good, in addition, to make the Scheme writer
> write (foo . #nil) as (foo . #nil).  The positive is that it
> would make bugs in Elisp compatibility easier to see by not
> masking the fact that one has #nil instead of () at the end
> of a list.  The only negative I can think of is that it would
> be mildly annoying to see (foo bar . #nil) where you expected
> to see (foo bar), but I don't think that's ever really harmful.
> 

FWIW here's a tiny patch that realizes this change.

- Taylan

[-- Attachment #2: 0001-Don-t-write-foo-.-nil-as-foo.patch --]
[-- Type: text/plain, Size: 1046 bytes --]

From 264b0f3eaead2e6460d32c6cd7f00868656ad891 Mon Sep 17 00:00:00 2001
From: Taylan Kammer <taylan.kammer@gmail.com>
Date: Fri, 14 May 2021 23:26:16 +0200
Subject: [PATCH] Don't write (foo . #nil) as (foo).

Elisp needs its own writer that produced output that will be understood
by Elisp's read.  Scheme's write shouldn't hide away a #nil terminating
a list, as this might make some bugs harder to find.

* libguile/print.c (scm_iprlist): Use scm_is_null_and_not_nil in place
of SCM_NULL_OR_NIL_P.
---
 libguile/print.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libguile/print.c b/libguile/print.c
index b10f0f8a8..2bdf1760b 100644
--- a/libguile/print.c
+++ b/libguile/print.c
@@ -1018,7 +1018,7 @@ scm_iprlist (char *hdr, SCM exp, int tlr, SCM port, scm_print_state *pstate)
       /* CHECK_INTS; */
       scm_iprin1 (SCM_CAR (exp), port, pstate);
     }
-  if (!SCM_NULL_OR_NIL_P (exp))
+  if (!scm_is_null_and_not_nil (exp))
     {
       scm_puts (" . ", port);
       scm_iprin1 (exp, port, pstate);
-- 
2.30.2