Re: A value for "nothing"

[Mark H Weaver]

<address@hidden> writes:

> On Sun, Aug 26, 2018 at 04:07:13PM -0400, Mark H Weaver wrote:
>
>> I would also avoid Guile's #nil.  That is a very special value, for one
>> purpose relating to Elisp compatibility, and ideally it should not be
>> used for anything else.
>
> I must admit that I'm... pretty confused about this very prescriptive
> tone.

You're right, I should have explained.  I'm overburdened at the moment.

For one thing, HiPhish has already indicated that his library will
support both Guile and Racket, so I conclude that he's at least somewhat
interested in portability to other Scheme implementations.

If he would like people to be able to write code that uses his library
and works on multiple Scheme implementations, then it will certainly be
an impediment to use a Racket-specific value for Nil on Racket, and a
Guile-specific value for Nil on Guile.  It would be much better to use a
portable Scheme data structure uniformly.

More generally, even for people only interested in supporting Guile, if
they would like their libraries to be usable from Elisp code on Guile,
which may become important some day if Guile-Emacs matures, then it's
problematic to use #nil for anything that needs to be distinguished from
'() or #f.

Alternatively, if Guile-Emacs dies and people give up on that project,
which is entirely possible, then we should probably deprecate #nil at
some point and eventually remove it.  Supporting #nil has costs, both in
performance and in the size of generated native code, when checking
whether an object is true (in every 'if' or 'cond') and when checking
for '().  That performance cost is insignificant in an interpreter or VM
implementation, but as we move to native code generation it may become
significant, as both of the aforementioned operations are quite
ubiquitous.

       Mark