CLtL II schedule

[Dick Gabriel <RPG@SAIL.Stanford.EDU>]

[In reply to message from gls@Think.COM sent Fri, 29 Sep 89 12:44:34 EDT.]


   Except for various incompatibilities of the usual sort, such as name
   conflicts, I see no reason why the presence of CLOS in an implementation
   should prevent existing programs from running.  Were the Japanese really
   talking about existing *programs* continuing to run, or about existing
   *implementations* continuing to be standard-conforming after making all
   non-CLOS changes but without having to implement CLOS?

They want to support existing programs with minimum implementation effort
to conform. They feel that CLOS is not proven (though they expect it will
be) and therefore is not current practice. The implementations of CLOS I
saw in Japan were quite slow, so they do not believe that it is known how
to make it run fast. We distributed to implementors many copies of
Dussud's paper on how to make a fast CLOS. Generally the academic and even
some commercial implementors in Japan are not able to make things run fast
unless it is obvious how to do it. For example, Tohoku University (a big
national school) has no analysis of algorithms courses though they have
a computer science department.

   Is there any possible thing X3J13 could produce that France would vote for?
   (This question is serious, not merely rhetorical.)

Well, there is something, but it would be useless to almost everyone. They
want a common intersection with EuLisp, which is a Lisp1 with a specified
order of evaluation including the functional position. So, we can make a
subset that leaves enough unspecified to allow both Lisp1 and Lisp2
supersets (it is unspecified what happens if a symbol names both a ordinary
binding and a functional binding - you know what I mean.).

Also, they use (dynamic-let ((x <stuff>)) ... (dynamic 'x) ...).
Furthermore (symbol-value <symbol>) is never equivalent to (dynamic <symbol>).

Finally, they use a lexpr-like thing form multiple arguments (as they call it),
and there are special forms for converting a multiple-argument thing into 
a multiple-value thing.

Dussud and I talked to Chailloux about it last spring and we came to the
conclusion the subset would have no dynamic binding, no fancy argument
passing except optionals, no multiple values, only simple vectors,
possibly simple arrays (only), only simple strings, fixnums, 1 floating
point format, and hardly anything else.

I think it is not hopeful, but it is possible.

			-rpg-