unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
* bug#21915: write inconsistent about #nil
@ 2015-11-14  1:46 Zefram
  2021-05-14 13:34 ` Taylan Kammer
  0 siblings, 1 reply; 3+ messages in thread
From: Zefram @ 2015-11-14  1:46 UTC (permalink / raw)
  To: 21915

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





^ permalink raw reply	[flat|nested] 3+ messages in thread

* bug#21915: write inconsistent about #nil
  2015-11-14  1:46 bug#21915: write inconsistent about #nil Zefram
@ 2021-05-14 13:34 ` Taylan Kammer
  2021-05-14 21:31   ` Taylan Kammer
  0 siblings, 1 reply; 3+ messages in thread
From: Taylan Kammer @ 2021-05-14 13:34 UTC (permalink / raw)
  To: 21915, Zefram

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





^ permalink raw reply	[flat|nested] 3+ messages in thread

* bug#21915: write inconsistent about #nil
  2021-05-14 13:34 ` Taylan Kammer
@ 2021-05-14 21:31   ` Taylan Kammer
  0 siblings, 0 replies; 3+ messages in thread
From: Taylan Kammer @ 2021-05-14 21:31 UTC (permalink / raw)
  To: 21915

[-- 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


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2021-05-14 21:31 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-11-14  1:46 bug#21915: write inconsistent about #nil Zefram
2021-05-14 13:34 ` Taylan Kammer
2021-05-14 21:31   ` Taylan Kammer

unofficial mirror of bug-guile@gnu.org 

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://yhetil.org/guile-bugs/0 guile-bugs/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 guile-bugs guile-bugs/ https://yhetil.org/guile-bugs \
		bug-guile@gnu.org
	public-inbox-index guile-bugs

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.lisp.guile.bugs
	nntp://news.gmane.io/gmane.lisp.guile.bugs


AGPL code for this site: git clone http://ou63pmih66umazou.onion/public-inbox.git