Re: truth of %nil

[Neil Jerram]

Hi Mark!

Mark H Weaver <address@hidden> writes:

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

> Do a grep-find in the tree for uses of these macros.  I think you'll
> find that the majority of places where they are used should also be
> checking for %nil, but they are not.

I started doing this.  Actually some of the first ones are in
backtrace.c (testing for the file and line source properties), and I
think those may be counter-examples...  but I agree that there are
many many cases that should be allowing for %nil.

But then I thought that this argument isn't really about the numbers.
It's that we have effectively taken a decision to treat Elisp as a
special case, among the set of languages that Guile may eventually
support - a fact which I now realize more clearly thanks to your and
others' querying of the treatment of nil, and thanks to the developing
language support - specifically in the sense of being able to pass
data between Scheme and Elisp without requiring any translation.  And
therefore it makes sense that libguile's most immediately available
APIs - i.e. scm_is_false/true/bool/null - should allow for their args
coming from either Scheme or Elisp.

So, thanks for persisting with the argument.

> 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.  But someone will have to think about
> each of these cases individually anyway, so it makes sense that these
> faster tests should be named something different than the old names,

This is of course something that you've included in your patch, and
I'm happy with that.

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

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?

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?  Alternatively, if you have your own Git repository,
we could pull from that.

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?

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

Many thanks!

     Neil