Re: 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