[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Elisp development news
Re: Elisp development news
20 Dec 2001 23:19:14 +0000
Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
Thanks for your detailed response.
You've now persuaded me that Jim's approach is functionally preferably
On the main issue, which I described as the conflict between "value
preservation" and Elisp's false and empty list values working natively
- I accept that my examples for this were rather contrived, and
unlikely to occur much (if at all) in real Elisp code. Therefore,
although my argument is theoretically correct, you are right when
you say "But I hope and think that we can get very, very close."
- To allow for the case where someone for some strange reason wants to
write code like (if x 'true x), we could provide an `elispify'
primitive that coerces all Elisp null values to nil; then the coder
can instead write (if x 'true (elispify x)).
That just leaves one concern and one (for now) question about the
The concern is that I'm still worried about the performance impact of
managing multiple false values and multiple end of list values. I
know that Jim suggests a solution in his proposal, but am not
convinced that it will not affect performance. What do you think
about Jim's suggestion here, and do you have any other thoughts on
implementation and performance?
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?
Thanks again. I've inserted a few more minor comments below.
>>>>> "Marius" == Marius Vollmer <address@hidden> writes:
Marius> - Regardless to what conclusion we come here, it will not
Marius> affect how isolated Elisp code runs when being executed by
Marius> Guile. What we are discussing, only affects how Elisp and
Marius> Scheme interact when being used side-by-side.
Marius> - Neither Neil's proposal nor Jim's are perfect. For
Marius> both, there is probably code out there that will break.
Marius> However, with Neil's proposal we don't need to change the
Marius> core of Guile, while with Jim's we would need to add a
Marius> special value and make sure that all low-level code
Marius> respects it.
Marius> - There are no drawbacks in Jim's proposal as compared to
Marius> Neil's. Jim's stuff will give us no more problems than
Marius> Neil's, but probably less.
I do now agree with you; but structurally this statement is only
defensible on the assumption that people agree with your detailed
arguments that follow.
Marius> - So the question is, what is the cost of implementing and
Marius> maintaining the core changes for Jim's proposal; and what
Marius> do we gain compared to Neil's proposal.
>> [All we need to achieve this is to handle #f when passed as the
>> CDR parameter to cons and setcdr.
Marius> Hmm, sure? It wouldn't work for the empty list, and cons
Marius> is not only used to construct lists. What about a tree
Marius> with boolean values at the leaves? It seems wrong to
Marius> treat the cdr different from the car.
Yes, that seemed wrong to me too, but I thought perhaps that it was a
fundamental asymmetry introduced by Lisp/Scheme's pervasive use of
>> The other way round is an issue that we'll get to in a moment.
Marius> I meant the other way around, like (pick-mappings
Marius> elisp-predicate ...).
(pick-mappings elisp-predicate ...) is a very persuasive example of
the benefits of trying to get native operation right in most cases.
Marius> We should analyze the existing Elisp code to see how often
Marius> the pattern (if x ... x) appears.
Well we can if someone would like to do that. I'm already convinced
that it will turn out to be pretty rare.
Marius> However, since adopting your proposal means doing nothing,
Marius> we have in effect adopted it already until it is clear
Marius> that it falls short of our goals (if at all).
I don't understand what you mean here. The current CVS head has
Mikael's prototype in it (although not uniformly used), which is
different again from both Jim's and mine, but more similar if anything
Marius> Please try to make sure that the Elisp translator can be
Marius> switched between both proposals. I think this will not be
Marius> too difficult.
I agree that it would not be difficult, but personally I'm now
convinced to go with Jim's approach. My only remaining worries are
performance and implementation details (as stated above).