[Top][All Lists]
[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