[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Elisp development news
From: |
Neil Jerram |
Subject: |
Re: Elisp development news |
Date: |
04 Jan 2002 14:51:11 +0000 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 |
>>>>> "Marius" == Marius Vollmer <address@hidden> writes:
Marius> It will affect performance, but I expect it to yield only
Marius> a small performance hit. I expect that, at worst, a test
Marius> for falseness will turn from a comparison with a constant
Marius> to two comparisons with one constant and one global
Marius> variable.
I guess so. I was confused by Jim's suggestion for redefining EQ(x,y)
in the Emacs code, and thinking that this meant changing SCM_EQ_P
similarly in Guile. But in fact we don't need to change SCM_EQ_P at
all, just tests against SCM_BOOL_F and SCM_EOL. And, even then, we
don't need to change ALL tests against SCM_BOOL_F or SCM_EOL, only
those involved in the processing of `if', `cond', `or', `and', `list?'
and so on. So the performance impact should indeed be much less than
I was imagining.
>> The question is whether the Elisp nil value should be distinct from
>> the `nil' symbol. I presume yes (from your argument below) but just
>> wanted to check. If yes, I further presume that the nil value should
>> be a new SCM_MAKIFLAG value; is that right?
Marius> Yes, that what I thought so far. However, it might be better to
make
Marius> nil a real symbol (i.e., satisfying our current SCM_SYMBOLP) and
Marius> somehow play tricks with the heap segments to still get a constant
Marius> value for the nil value (but I wouldn't know off-hand how to do this
Marius> portably).
I don't see why it's useful for the Elisp nil value to satisfy
Scheme's `symbol?'. (Obviously it must satisfy Elisp's `symbolp', but
that's a different matter.) So I think the SCM_MAKIFLAG is the way to
go, and faster because it is a constant.
Neil