Re: truth of %nil

[Mark H Weaver <mhw@netris.org>]

Neil wrote:
> > I would like to argue that the definitions of scm_is_false,
> > scm_is_true, and scm_is_null should indeed be changed to test for
> > %nil.
> 
> OK, thanks to your arguments, I now agree with this.

Excellent!

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.

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".

> > If, in a particular use, it
> > can be proved statically that the value was not created by an elisp
> > function (which we can almost never prove), then that is a case where
> > we can use some faster test.  [...]
>
> [...]
> 
> This is also something that could (potentially!) be optimized at
> runtime or by the compiler (reminds me of the class of calls where
> type checking could be eliminated if the compiler can prove that
> objects will always be of the required type).

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.

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

> It would also be more convenient - and better for giving you your
> deserved attribution - if you could submit them as Git patches.  Would
> that be possible?

Will do.

> Also, we will need documentation of the new APIs, and to explain the
> overall concept; and a NEWS entry; and maybe a couple of tests to
> check where data that includes %nil is passed to some of the fixed
> functions.  Would you be willing to prepare all those too?

Yes, certainly.

> > One category of place where these could be used is code dealing with
> > data structures created internally by the evaluator -- though I'm not
> > very familiar with guile's internals, so I don't know how common these
> > data structures are, if indeed they exist at all.
> 
> Yes, indeed.  In the updated patch(es), I suggest that you mark the
> cases that you are not sure about, then I and other developers can
> help work out what kind of check they should be doing.

Indeed, some of the usage cases are difficult for me to evaluate, so
your help will be much appreciated!

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

   Best,
    Mark