[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
object lisp -> clos
- To: email@example.com
- Subject: object lisp -> clos
- From: Henry Lieberman <firstname.lastname@example.org>
- Date: Sat, 19 Jan 91 13:36:11 EST
- Cc: email@example.com, firstname.lastname@example.org
- In-reply-to: Gary Byers's message of Fri, 18 Jan 91 21:09:03 -0500 <9101190209.AA22376@cambridge.apple.com>
My experiences in converting Object Lisp to CLOS in MACL were not so bad.
Certainly less trouble than other conversions I have had
to do, e.g. Rel 6 to Rel 7 Symbolics, Flavors to Object Lisp,
Flavors to Clos, Symbolics to Lucid, etc. etc.
In my experience, the effort of converting between dialects A and B of
roughly equivalent power is roughly constant regardless of A and B
because the bulk of the work is (1) ferreting out ALL the
differences between dialects A and B (2) Debugging the target
implementation all over again to verify that everything works.
Coral's CLOS implementation in 2.0 is quite well done, much
better than PCL. The only major area for improvement I see is
more debugging support for CLOS programs.
A big area of conversion problems that might not be evident at
first for the OL->CLOS conversion has to do with naming. Both Object Lisp
and CLOS have, to my view, serious but different naming problems.
These come up in unexpected clash of identifiers during conversion.
Object Lisp has the infamous problem of clash between local variables and
In other object-oriented dialects, [Smalltalk, old flavors]
"message names" are considered to be a convention between sender and
receiver, so there is no conflict with the same message name being
used by different sender and receiver pairs. In CLOS, "message names"
are function symbols, and the lambda-list congruence constraint often
prevents incompatible multiple uses of the same function name. The only way
to separate names is by packages, but packages do not work well for this
purpose, and it is not feasible to create a new package every time this