"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
> Hrvoje> Multiple extension languages sounds like big
> Hrvoje> trouble.
>
> What do you think "elisp:foo-n", n goes from 1 to 1000, is, if all the
> foo-n are defined in base Common Lisp too, but differently?
I believe multiple extension languages are a wholly different kind of
trouble. One I am too scared to even contemplate! *shiver*
> Obviously, I think that that is the same problem as multiple
> extension languages, of perhaps somewhat lesser degree. I take it
> you think it is not a problem (most likely because you believe n is
> small)?
I'd call n "reasonably small," if Erik's packages scheme can be made
to work. I am not yet 100% convinced that it can work flawlessly, but
we'll see. Common Lisp reader is very flexible.
> If we make "old ELisp" available as an option, who's going to police
> the contributors who continue to use it?
The whole point is for the contributors to be able to keep using it --
for compatibility, if nothing else.
> And there are some people who find the prospect exciting.
Undoubtedly. There are people who find the prospect of Perl-in-Emacs
exciting.
> Bruno does not seem to be an expert on XEmacs internals. And he has
> committed to extensions needed by XEmacs, not to implementation
> changes needed by XEmacs. Can you assert that there are none of the
> latter? Will Bruno go so far as to change internals of CLisp to fit
> XEmacs needs?
I don't know. Hopefully, he will. You would have to ask Bruno this
question.
> Hrvoje> If enough work is done on ensuring it is, I don't see why
> Hrvoje> [CLisp] wouldn't be a good choice [as a substrate for
> Hrvoje> XEmacs].
>
> "Enough work" can be one hell of a lot of work.
Yup.
> Hrvoje> Define "confidence."
>
> The _definition_ of confidence is a written proposal with a schedule
> (cf. Fred Brooks, Ed Yourdon, Watts Humphrey, ad nauseum).
Wow. Then I'm surely not confident. :-)
That's not how Webster defines the word, but hey -- not that I will
argue English semantics with a native speaker!
> I have no thought of _asking_ anyone for that. But one of the
> attractions of Scheme for me is that Michael is already moving in
> the direction of a written proposal,
Yeah, I notice that. More to the point, Michael gets more credit
because he is prepared to do the actual work, rather than only argue
about it. That's a great point pro Michael, but means nothing in
terms of general CL-vs.-Scheme arguments.
> That gives me some confidence that a Scheme implementation will
> happen, with few defects, in a timely fashion, with its necessary
> documentation, if it gets a green light.
Yes, but I fear that the implementation will be buggy, that the elisp
emulation will be inadequate, and that we'll wind up with n00 users,
the rest of the folks happily using XEmacs 21.x.
But I fear the same in a CL-based XEmacs 2x, so the above was a
digression.
> Hrvoje> Because otherwise the whole thing would make no sense.
> Hrvoje> If this goal cannot be met with clisp, then clisp is not
> Hrvoje> the right choice.
>
> So tell us how we're going to meet the goal. I don't doubt your
> desire or willingness to work and to help coordinate with the CLisp
> project.
You'd better doubt my willingness to do that! I don't have a
sufficient amount of time to devote to that, nor do I have the
necessary knowledge; I thought I have made this clear. My past
contributions to XEmacs were more or less elaborate hacks and, when
I'm in a good mood, bugfixes. Porting XEmacs to clisp is clearly
outside my scope.
I argue for clisp and against Scheme 48 because I feel I would prefer
using (in the sense of "enhancing") the finished product.
> You're the obvious candidate that participants in this discussion
> will look to for managing the clean up if anything does go wrong
> with a CL engine, don't you think?
I don't think that at all. Noone has expressed their wishes to do a
substantial amount of work on this, except for Michael. Following
your line of thought, we are more or less stuck with his choice of
extension/implementation language because he will do the work.
> rm -rf xemacs-22; cvs co -rr21_release xemacs
>
> Sure, this is pessimistic. But such disasters happen, and we need
> to be prepared for the possibility, and to have a plan to avoid it.
Yup. But unlike you, I consider it just as likely with Scheme as with
Common Lisp.
> Hrvoje> There is no way I can compete with Michael.
>
> You don't have to.
Oh yes I do! See above.
> Not even to get me to agree that CL is the way to go. But Michael's
> expertise _is_ an advantage for Scheme. It would be nice if you
> could find someone to play the same role for CL.
I cannot. I am certainly not the person you want me to find. Thanks,
but no, thanks.
--
Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Do not meddle in the affairs of troff, for it is subtle and quick
to anger.
