From: Mark H Weaver <mhw@netris.org>
To: Andy Wingo <wingo@pobox.com>
Cc: guile-devel <guile-devel@gnu.org>, Neil Jerram <neil@ossau.uklinux.net>
Subject: Re: truth of %nil
Date: Tue, 7 Jul 2009 07:14:09 -0400 [thread overview]
Message-ID: <20090707111406.GA1388@fibril.netris.org> (raw)
In-Reply-To: <m3iqi7ebc1.fsf@pobox.com>
Having thought more about optimizing %nil handling, it occurs to me
that we will also want boolean tests from within lisp to be optimized.
From lisp, three values are considered to be false: #f, '(), and %nil.
We can use the same bit-masking trick to do these tests quickly if we
make sure that these three values differ in only two bit positions.
Therefore, I suggest that the first four SCM_MAKIFLAG values should be
#f, %nil, '(), and another never-to-be-used value which would also be
considered false by lisp code as a side effect of the masking trick.
In my previous proposal, I made sure to keep SCM_BOOL_F and SCM_BOOL_T
in IFLAG numbers 0 and 1. If this is important, it could still be
arranged by making the aforementioned two bit positions something
other than the lowest two bits of the IFLAG number, but that would
mean our three lisp-false values would be spread out (e.g. 0/2/4/6).
Therefore, unless someone tells me otherwise, I'm going to assume it's
okay to put SCM_BOOL_F and SCM_BOOL_T in IFLAG numbers 0 and 4. These
still have the property that SCM_BOOL_F and SCM_BOOL_T differ by only
one bit, and that SCM_BOOL_F is IFLAG number 0, both of which seem
potentially useful.
So, in my new proposal, the first five IFLAGS are as follows:
#define SCM_BOOL_F SCM_MAKIFLAG (0)
#define SCM_ELISP_NIL SCM_MAKIFLAG (1)
/* SCM_MAKIFLAG (2) would also be considered "false" by lisp code
* and therefore should remain unassigned */
#define SCM_EOL SCM_MAKIFLAG (3)
#define SCM_BOOL_T SCM_MAKIFLAG (4)
This numbering has the nice properties that 0 is #f, the first two are
considered false by scheme, and the first four are considered false by
lisp.
[An alternative numbering for which the following macros would also
work is: ((#f 0) (#t 1) (%nil 2) (unused 4) (() 6)), if it's important
to keep #f and #t together]
The testing macros would be as follows (these can of course be renamed
if my other pending proposal is rejected):
#define scm_is_false(x) \
(((x) & ~(SCM_ELISP_NIL ^ SCM_BOOL_F)) == (SCM_ELISP_NIL & SCM_BOOL_F))
#define scm_is_true(x) \
(((x) & ~(SCM_ELISP_NIL ^ SCM_BOOL_F)) != (SCM_ELISP_NIL & SCM_BOOL_F))
#define scm_is_null(x) \
(((x) & ~(SCM_ELISP_NIL ^ SCM_EOL)) == (SCM_ELISP_NIL & SCM_EOL))
#define scm_is_false_xxx_assume_not_lisp_nil(x) ((x) == SCM_BOOL_F)
#define scm_is_true_xxx_assume_not_lisp_nil(x) ((x) != SCM_BOOL_F)
#define scm_is_null_xxx_assume_not_lisp_nil(x) ((x) == SCM_EOL)
And the lisp boolean tests would be something like this:
/*
* Since we know SCM_ELISP_NIL and SCM_BOOL_F differ by exactly one
* bit, and that SCM_ELISP_NIL and SCM_EOL differ by exactly one bit,
* and that they of course can't be the same bit (or else SCM_BOOL_F
* and SCM_EOL be would equal), it follows that SCM_BOOL_F and SCM_EOL
* differ by exactly two bits, and those are the ones we need to
* mask out to collapse all three values together.
*/
#define scm_is_lisp_false(x) \
(((x) & ~(SCM_BOOL_F ^ SCM_EOL)) == (SCM_BOOL_F & SCM_EOL))
#define scm_is_lisp_true(x) \
(((x) & ~(SCM_BOOL_F ^ SCM_EOL)) != (SCM_BOOL_F & SCM_EOL))
What do you think?
Also, you may have noticed that I've been using the term "lisp"
instead of "elisp". This is because guile may support other lisps in
the future, and they will also need the same %nil handling. (For that
matter, we could even use %nil to implement an "old scheme" language
which treats '() as false.) With this in mind, should SCM_ELISP_NIL
be renamed to SCM_LISP_NIL?
Andy: thanks for the warm reception, and I'll answer your questions in
a later email.
Best regards,
Mark
next prev parent reply other threads:[~2009-07-07 11:14 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-29 21:12 truth of %nil Andy Wingo
2009-06-29 21:44 ` Neil Jerram
2009-06-29 22:11 ` Andy Wingo
2009-06-30 22:22 ` Neil Jerram
2009-07-01 6:45 ` Daniel Kraft
2009-07-01 21:54 ` Neil Jerram
2009-07-05 13:07 ` Mark H Weaver
2009-08-30 11:07 ` Neil Jerram
2009-08-30 14:11 ` Mark H Weaver
2009-09-01 22:00 ` Neil Jerram
2009-09-02 15:57 ` Mark H Weaver
2009-09-17 21:21 ` Neil Jerram
2009-07-02 14:28 ` Mark H Weaver
2009-07-02 14:50 ` Ludovic Courtès
2009-07-02 22:50 ` Neil Jerram
2009-07-03 15:32 ` Mark H Weaver
2009-07-05 2:41 ` Mark H Weaver
2009-07-05 9:19 ` Andy Wingo
2009-07-07 11:14 ` Mark H Weaver [this message]
2009-07-08 13:17 ` Mark H. Weaver
2009-08-30 11:20 ` Neil Jerram
2009-08-30 11:13 ` Neil Jerram
2009-08-30 14:15 ` Mark H Weaver
2009-09-01 21:50 ` Neil Jerram
2009-08-30 22:01 ` Ken Raeburn
2009-08-31 21:59 ` Ludovic Courtès
2009-08-31 23:39 ` Ken Raeburn
2009-08-31 21:55 ` SCM_BOOL_F == 0 and BDW-GC Ludovic Courtès
2009-09-17 22:00 ` Neil Jerram
2009-09-17 22:28 ` Ludovic Courtès
2009-09-18 20:51 ` Neil Jerram
2009-09-20 17:21 ` Ludovic Courtès
2009-09-20 21:03 ` Neil Jerram
2009-09-20 21:36 ` Ludovic Courtès
2009-07-06 21:46 ` truth of %nil Neil Jerram
2009-07-06 23:54 ` Mark H Weaver
2009-07-08 8:08 ` Ludovic Courtès
2009-07-23 21:12 ` Andy Wingo
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=20090707111406.GA1388@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).