unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Mark H Weaver <mhw@netris.org>
To: Neil Jerram <neil@ossau.uklinux.net>
Cc: Andy Wingo <wingo@pobox.com>, guile-devel <guile-devel@gnu.org>
Subject: Re: upcoming patches
Date: Tue, 20 Oct 2009 12:47:27 -0400	[thread overview]
Message-ID: <20091020164727.GC3779@fibril.netris.org> (raw)
In-Reply-To: <87aazo74zd.fsf@ossau.uklinux.net>

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




  parent reply	other threads:[~2009-10-20 16:47 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-18 10:38 upcoming patches Andy Wingo
2009-10-18 21:43 ` Neil Jerram
2009-10-19 18:24   ` Andy Wingo
2009-10-19 21:08     ` Neil Jerram
2009-10-19 21:17       ` Andy Wingo
2009-10-20 16:47   ` Mark H Weaver [this message]
2009-10-20 19:19     ` Andy Wingo
2009-10-19 12:34 ` Daniel Kraft
2009-10-19 18:26   ` Andy Wingo
2009-10-27 20:15 ` Andy Wingo
2009-10-27 21:17   ` Neil Jerram

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091020164727.GC3779@fibril.netris.org \
    --to=mhw@netris.org \
    --cc=guile-devel@gnu.org \
    --cc=neil@ossau.uklinux.net \
    --cc=wingo@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).