guile-devel
[Top][All Lists]
Advanced

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

Re: upcoming patches


From: Mark H Weaver
Subject: Re: upcoming patches
Date: Tue, 20 Oct 2009 12:47:27 -0400

Andy wrote:
>   2) Make sure Mark's patch is in

Neil wrote:
> Have I missed this?  I _think_ I'm still waiting for Mark's updated
> patch...

Sorry for being so slow on this.  I had a lot of free time with I
first submitted the patch, but have been busier since then.  If
someone wants to make a new patch from my "cube of lisp booleans"
post, that would be fine with me.

The biggest block is that I'm intimidated by the prospect of looking
at every use of scm_is_{false,true,null} in the tree and deciding
which of the new predicates should be used.  I expect that the vast
majority could be left alone without introducing new bugs, but I can't
be sure without checking each one.

Also, since writing the first patch, I've had some second thoughts
about whether this approach to #nil is the correct one.  I'm primarily
concerned with the problem of equality predicates, which from the lisp
point of view should treat #nil as equal to both '() and #f.  How will
this interact with collections (e.g. hash tables and alists, or even
simple lists used as sets) which use lists as keys?  If lisp adds an
element to such a collection, scheme won't be able to find it, and
vice versa.  I see the potential for many subtle bugs to go unnoticed.

I think a case can be made that we need three new equality predicates
which treat #nil, '(), and #f as the same value, three new types of
hash tables, three new sets of association list functions, etc.

Although I'm sure the Emacs community would never agree, I'm tempted
to suggest that the best solution is for Emacs to meet us half way, by
making end-of-list and boolean false distinct values, although '()
would still be considered false by conditionals from within lisp.
Having different notions of "falseness" in the two languages does not
pose a serious problem, but I do not see a robust way of dealing with
lisp's failure to distinguish end-of-list and boolean false.

Apologies if these thoughts are half-baked.  Part of the problem is
that I've not had enough time to fully evaluate these issues, and I
feel paralyzed since I don't like any of the available options.

Thoughts?

     Mark




reply via email to

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