Re: Elisp development news

[Neil Jerram]

>>>>> "Neil" == Neil Jerram <address@hidden> writes:
>>>>> "Ken" == Ken Raeburn <address@hidden> writes:

    Neil> I'd like to merge this work back into the main development
    Neil> branch, both to encourage further use and development, and
    Neil> to avoid bitrot, but there are some (possibly controversial)
    Neil> changes to the libguile C code that I'd like to discuss and
    Neil> agree or rework first.  Those changes are ...

    Ken> Removing a bunch of the elisp-oriented support looks like a
    Ken> good thing to me.  The less that needs to be written in C
    Ken> (not counting Scheme mechanically translated to C for
    Ken> performance), the better the argument for Scheme and Guile
    Ken> specifically as an extension language that can easily subsume
    Ken> the roles of other extension languages.  Maybe I'm just being
    Ken> silly, but my thinking is along the lines of, "If Scheme is
    Ken> so great, why do you have to write all this C code?"
    Ken> (Probably followed up by, "Okay, so if performance is so
    Ken> important, why don't you have a better compiler?")

    Neil> I completely agree.  From a slightly more pragmatic point of
    Neil> view, we might find for performance reasons (and for lack of
    Neil> a compiler!) that we need to move something into C in the
    Neil> future.  But the stuff that exists right now is
    Neil> over-engineering IMO.

So, would anyone else object to me

- deprecating the unnecessary C Elisp support in the stable branch

- removing the same stuff in the CVS head?

Just to be clear, what I'm talking about is 0-ify, 1-ify, nil-ify,
t-ify, nil-cons, nil-car, nil-cdr, SCM_EOL2NIL, SCM_NILNULLP, nil, t
etc.  Basically everything in lang.[ch] and corresponding branches in
the evaluator.  The only things that survive are nil-cond, @fop and
@bind.

        Neil

PS. Remember - it'll always be there in CVS if this turns out to be a
mistake!