"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
>>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)srce.hr> writes:
Hrvoje> "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
>> 1. Do the respective standards specify things (like behavior
>> of text objects) that we would prefer to specify ourselves?
>> (Neither camp has said anything about this AFAIK.) If so, this
>> is harmful to ease of migration.
Hrvoje> Neither CL nor Scheme contain descriptions of "text
Hrvoje> objects", I think.
By "text objects" I mean characters, strings, buffers, extents, and
other things that I don't know about or possibly don't exist yet that
are used to contain and manipulate text. They surely do define some
of the above.
I think both specify characters as strings, as you surely guessed.
>> 2. What constructs in one dialect would be difficult
or
>> impossible to implement efficiently in the other?
Hrvoje> Why is this an issue? I don't *want* to implement Scheme
Hrvoje> in CL, nor do I want to implement CL in Scheme.
Some people _are_ thinking in those terms. So it's an issue.
Closed, from your standpoint. Still open, from mine.
Can you name some of these people? What exactly do they want to
achieve by implementing CL in Scheme, or vice versa? And what does
that have to do with what we are discussing here (extension language
for XEmacs)?
>> This is especially important if we hope to offload Lisp
engine
>> maintenance, as Bruno has offered to do for CLisp.
Hrvoje> Bruno already maintains clisp, no matter what we do. What
Hrvoje> he offered to do is help us implement the additional
Hrvoje> Emacs-specific stuff within clisp, such as
Hrvoje> `DEFINE_LRECORD_IMPLEMENTATION' lookalikes.
Are you implying that he doesn't plan to help maintain them?
Maintain what? XEmacs? No. Clisp? Yes.
Provide extensions to clisp so that XEmacs is easier to maintain?
Yes, or so he told me.
I'm trying to get an understanding of the advantages and
disadvantages of the dialects. When you take advantage of my
ignorance to be legalistic like that, it doesn't build my confidence
in your position.
I have no idea what you mean here. I haven't "taken advantage" of
you. You noticed that Bruno should maintain font-lock.c, and I said
he shouldn't. I see no reason in this world why clisp maintainer
should maintain XEmacs code.
Can we assert with some confidence that we will be able to depend on
a separately-maintained Common Lisp engine, presumably CLisp, or
not?
That would be the whole point of the move.
We _know_ we're going to have to extend and maintain a Scheme
engine,
Huh? We only have to extend it, not maintain it.
>> If we can get coroutines and threads as cheaply as
Michael
>> suggests, that is a _big_ deal.
Hrvoje> I'm afraid we can't.
And I'm afraid of maintaining the
":not-when-otherwise-not-because-it-just-might-possibly" keyword, and
all its brethren.
Bruno does that already, or whoever maintains the Lisp substrate.
--
Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Personifiers Unite! You have nothing to lose but Mr. Dignity!