4:58 p.m.
"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.
Neither CL nor Scheme contain descriptions of "text objects", I think.
2. What constructs in one dialect would be difficult or impossible
to
implement efficiently in the other?
Why is this an issue? I don't *want* to implement Scheme in CL, nor
do I want to implement CL in Scheme.
3. Where will it be hard to emulate current elisp efficiently?
It is my hope that it will be possible to evaluate Emacs Lisp from
Common Lisp "directly", within a specific package, without the need
for a translator. I have not delved into this further, but Erik
Naggum proposed some interesting ideas in his articles.
An example of Erik's idea is to use the CL package system for our
advantage. For example, in `.el' files, `elisp' would be the current
package, and elisp::mapcar would grok strings and vectors. Also,
within these files, the reader would grok [] as vector syntax. Etc.
4. Where the semantics of common constructs differ among elisp,
Common Lisp, and Scheme, how hard is it going to be for casual elisp
programmers to make the switchover?
Lars expanded on this nicely. It is much easier for elisp programmers
to switch to CL than to Scheme.
5. Do we or CLisp or any of the suggested Scheme variants have an
API
that will allow us to separate the Lisp engine proper from extensions,
like the C-level support for fontification?
I'm not sure about clisp. Michael claims that there are Scheme
variants with excellent FFI's, and I believe him.
This is especially important if we hope to offload Lisp engine
maintenance, as Bruno has offered to do for CLisp.
Bruno already maintains clisp, no matter what we do. What he offered
to do is help us implement the additional Emacs-specific stuff within
clisp, such as `DEFINE_LRECORD_IMPLEMENTATION' lookalikes.
mb> Scheme has been designed for programming language
research,
mb> rather than practical use. It has such a history of
mb> minimalism that all scheme implementations had to provide
mb> extensions to be useful.
Hmm. Sounds like Common Lisp is going to require lots of extensions
to be useful to us, to me. CLtL1, at least, makes no reference to
editing buffers or multilingual text processing, frames or extents.
True, but the same goes for Scheme. What Martin really meant was more
clearly explained in Lars' messages.
Minimal is good, if we want to support different extension
languages.
I don't think we want to do that, with the single exception of Emacs
Lisp. At least I would argue against that.
Minimal is good, if we are going to end up having to maintain the
Lisp
engine ourselves. Yes, Bruno says that he will help maintain a Common
Lisp engine specific to XEmacs. Does he understand that that will
possibly include things like C-level support for fontification?
C-level support for fontification has nothing to do with the Lisp
engine, and will surely not be maintained by Bruno.
mb> It still is missing many things. For example, my beloved
mb> (when ...) is missing (from the standard). Hashtables are
mb> missing.
(when ...) is a trivial macro, isn't it? ("Very useful" and now
"beloved"! What loyalty a trivial extension can engender!)
Hashtables, we can do.
Why would having these (and many similar items, I'm sure) _in the
standard_ be useful to us?
Because then you don't have to rely on incompatible extensions.
Again, see Lars' DELETE-IF example.
mb> (call-with-current-continuation) is a very interesting
mb> function, but one cannot expect ordinary humans to understand
mb> it. It is only a tool for system implementors.
XEmacs is a system, is it not? _We_ are system implementors. (Sorry
for the implicit self-aggrandizement.) However, I will leave call/cc's
serious usage to Michael and the Mark II version of Karl Hegbloom ;-)
I imagine most package writers and so on will do so, too.
If we can get coroutines and threads as cheaply as Michael suggests,
that is a _big_ deal.
I'm afraid we can't.
--
Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
4. Thou shalt not warlorde a sig if it bee the sig of Kibo, nor if
it bee the sig of the Inner Circle.
6:01 a.m.
New subject: scheme - my opinion
>>>> "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. CLtL1 apparently _did_ contain a standard for
bucky-bits in characters, but CLtL2 retracted it (thank you, Jerry
James).
That would have been a real irony.
> 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.
Hrvoje> An example of Erik's idea is to use the CL package system
Hrvoje> for our advantage. For example, in `.el' files, `elisp'
Hrvoje> would be the current package, and elisp::mapcar would grok
Hrvoje> strings and vectors. Also, within these files, the reader
Hrvoje> would grok [] as vector syntax. Etc.
Thank you, that is very useful to know.
> 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?
> Minimal is good, if we are going to end up having to maintain
> the Lisp engine ourselves. Yes, Bruno says that he will help
> maintain a Common Lisp engine specific to XEmacs. Does he
> understand that that will possibly include things like C-level
> support for fontification?
Hrvoje> C-level support for fontification has nothing to do with
Hrvoje> the Lisp engine, and will surely not be maintained by
Hrvoje> Bruno.
I'm ignorant of most of XEmacs's internals. I picked an example for
which the answer is "no problem". That's why I used the word
"possibly".
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.
Can we assert with some confidence that we will be able to depend on a
separately-maintained Common Lisp engine, presumably CLisp, or not?
We _know_ we're going to have to extend and maintain a Scheme engine,
for all the reasons the CL camp has given. Scheme being inherently
small, we can pick and choose the features we wish to support. If
XECL diverges from its parent, we will be committed to maintaining the
":not-when-otherwise-not" keyword, now that Lars has revealed its
existence in the standard.
Hrvoje> Because then you don't have to rely on incompatible
Hrvoje> extensions. Again, see Lars' DELETE-IF example.
So, _just like Common Lisp itself_ (with respect to MacLisp, ZetaLisp,
InterLisp) we declare that extensions will be compatible with CL.
> 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.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +1 (298) 53-5091
9630
days inactive
9631
days old
1 comments
2 participants
participants (2)
-
Hrvoje Niksic -
Stephen J. Turnbull