unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Neil Jerram <neil@ossau.uklinux.net>
To: Mark H Weaver <mhw@netris.org>
Cc: Andy Wingo <wingo@pobox.com>, Daniel Kraft <d@domob.eu>,
	guile-devel <guile-devel@gnu.org>
Subject: Re: truth of %nil
Date: Tue, 01 Sep 2009 23:00:51 +0100	[thread overview]
Message-ID: <87r5uqnx4c.fsf@arudy.ossau.uklinux.net> (raw)
In-Reply-To: <20090830141100.GA2255@fibril.netris.org> (Mark H. Weaver's message of "Sun\, 30 Aug 2009 10\:11\:00 -0400")

Mark H Weaver <mhw@netris.org> writes:

> What about scm_is_bool?  I'm tempted to suggest that it should work
> the same way as "boolean?" within scheme, whatever that may be.  I
> tend to think they ought to treat %nil as boolean, though I'm less
> sure of this than about scm_is_true/false/null.  It's the right thing
> for type-checking an argument that is expected to be boolean, which
> seems to be fairly common in guile.  More complex code that is
> dispatching on type (such as the aforementioned GOOPS code) will in
> general have to be fixed to take into account that %nil is both a
> boolean and a list.

I agree (i.e. I think scm_is_bool (SCM_LISP_NIL) should be 1).

> One more thing: scheme code can reasonably expect to "write" a list of
> simple values and then "read" it back in.  But now, lists might be
> terminated by %nil instead of '().  Therefore, I think "read" needs to
> be able to read SCM_LISP_NIL in whatever form we "write" it in.  I'll
> let someone more knowledgable about guile reader issues decide what
> that form should be.  Currently we write it as "#nil".

Interesting point, but seems like one that could be left until it
crops up for real somewhere.

I assume the mainline case of writing a proper list will be fine,
because a list like (a b c . #nil) will be written out as "(a b c)" -
right?  Then, when read in again, it would become (a b c . ()) - I
think we may have to wait for real cases to know if that's actually a
problem at all.

> Yes, I've also given this some thought.  If we were using C++ (I'm
> very glad we're not, btw!) then I'm pretty sure we could use the type
> system to mark certain functions as never returning %nil, and then
> arrange to optimize away the %nil checks in those cases, but I can't
> think of a way to do it with C, even with GCC's extensions.  Maybe, if
> we can develop a reasonable proposal, we can get sufficient
> functionality added to GCC.

I was actually meaning the VM compiler...  but yes, maybe there are
also C things we could do.

>> So, if you would be happy to do so, can I suggest that you rework your
>> patches so that they also make (and then assume, obviously) the
>> scm_is_false/true/bool/null change, and incorporate my other comments?
>
> I will gladly do so.

Fantastic, thanks (and also for your 'Yes's to the other add-on
pieces)!

> Also, I signed my copyright assignment papers a while ago, and the
> relevant file on fencepost has been updated accordingly.

Yes, indeed; we (maintainers) got notified about that at the time;
apologies for not closing the loop with you then.

Regards,
        Neil




  reply	other threads:[~2009-09-01 22:00 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-29 21:12 truth of %nil Andy Wingo
2009-06-29 21:44 ` Neil Jerram
2009-06-29 22:11   ` Andy Wingo
2009-06-30 22:22     ` Neil Jerram
2009-07-01  6:45       ` Daniel Kraft
2009-07-01 21:54         ` Neil Jerram
2009-07-05 13:07           ` Mark H Weaver
2009-08-30 11:07             ` Neil Jerram
2009-08-30 14:11               ` Mark H Weaver
2009-09-01 22:00                 ` Neil Jerram [this message]
2009-09-02 15:57                   ` Mark H Weaver
2009-09-17 21:21                     ` Neil Jerram
2009-07-02 14:28   ` Mark H Weaver
2009-07-02 14:50     ` Ludovic Courtès
2009-07-02 22:50     ` Neil Jerram
2009-07-03 15:32       ` Mark H Weaver
2009-07-05  2:41         ` Mark H Weaver
2009-07-05  9:19           ` Andy Wingo
2009-07-07 11:14             ` Mark H Weaver
2009-07-08 13:17               ` Mark H. Weaver
2009-08-30 11:20                 ` Neil Jerram
2009-08-30 11:13               ` Neil Jerram
2009-08-30 14:15                 ` Mark H Weaver
2009-09-01 21:50                   ` Neil Jerram
2009-08-30 22:01                 ` Ken Raeburn
2009-08-31 21:59                   ` Ludovic Courtès
2009-08-31 23:39                     ` Ken Raeburn
2009-08-31 21:55                 ` SCM_BOOL_F == 0 and BDW-GC Ludovic Courtès
2009-09-17 22:00                   ` Neil Jerram
2009-09-17 22:28                     ` Ludovic Courtès
2009-09-18 20:51                       ` Neil Jerram
2009-09-20 17:21                         ` Ludovic Courtès
2009-09-20 21:03                           ` Neil Jerram
2009-09-20 21:36                             ` Ludovic Courtès
2009-07-06 21:46           ` truth of %nil Neil Jerram
2009-07-06 23:54             ` Mark H Weaver
2009-07-08  8:08             ` Ludovic Courtès
2009-07-23 21:12         ` Andy Wingo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r5uqnx4c.fsf@arudy.ossau.uklinux.net \
    --to=neil@ossau.uklinux.net \
    --cc=d@domob.eu \
    --cc=guile-devel@gnu.org \
    --cc=mhw@netris.org \
    --cc=wingo@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).