guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: truth of %nil


From: Neil Jerram
Subject: Re: truth of %nil
Date: Tue, 01 Sep 2009 23:00:51 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)

Mark H Weaver <address@hidden> 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 via email to

[Prev in Thread] Current Thread [Next in Thread]