Re: Elisp development news

[Neil Jerram]

Thanks for your detailed response.

You've now persuaded me that Jim's approach is functionally preferably
to mine.

On the main issue, which I described as the conflict between "value
preservation" and Elisp's false and empty list values working natively
in Scheme...

- 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
_implementation_.

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.

        Neil

>>>>> "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.
Absolutely.

    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.
Right.

    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.
Right.

    >> [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
lists.

    >> 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
to Jim's.

    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).