[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Hvatum@MIT-MULTICS.ARPA, Rob MacLachlan <RAM@c.cs.cmu.edu>, masinter.PA@xerox.com, Jim Kempf <email@example.com>, Jon L White <firstname.lastname@example.org>, Mike Hewett <HEWETT@sumex-aim.stanford.edu>, email@example.com, navajo!Common-Lispfirstname.lastname@example.org
- Subject: Compiling CASE
- From: David C. Plummer <DCP@quabbin.scrc.symbolics.com>
- Date: Mon, 13 Apr 87 09:57 EDT
- In-reply-to: <870411100755.599053@MIT-MULTICS.ARPA>, <RAM.12293665189.BABYL@C.CS.CMU.EDU>, <RAM.12293670645.BABYL@C.CS.CMU.EDU>, <870411-154536-1554@Xerox>, <8704120544.AA05619@hplabsc>, <8704130006.AA04788@bhopal.edsel.com>, <12294088425.12.HEWETT@SUMEX-AIM.STANFORD.EDU>
Date: Sun, 12 Apr 87 22:24:43 PDT
From: Mike Hewett <HEWETT@SUMEX-AIM.STANFORD.EDU>
As someone more concerned with using Common LISP and in
the portability of it, I can't believe any responsible
software engineer would even think of redefining a
CL-defined function, macro, or special form.
I agree, and the implication (or my inference) is that there are
irresponsible engineers, or even the responsible ones make mistakes.
Therefore, the question of allowing redefinition is purely
a CL environment implementation question, and I would think
that it should be perfectly legal to protect the user from
himself and not allow redefinition.
I agree here too. Various implementations do protect the user. The
Symbolics implementation does this by remembering the source file of the
original definition, and if the new source file doesn't match it
queries. This applies to all functions, not just the core language.
Date: Sat, 11 Apr 1987 11:09 EDT
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
The significance of code walkers has also been exaggerated. For one
thing, modern Lisp compilers tend not to use source code as the
internal representation, and their operation cannot really be modeled
as a source code walk. Given a sufficiently rich representation, many
things can be determined without actually grovelling the code.
Of course internal compiler representations are highly implementation
dependent, but this isn't necessarily a problem. One of the main
things that source code walkers have been used for is writing
"optimizing macros" for non-optimizing compilers. As long as the
compiler adequately optimizes the code, macros can expand in a
simple-minded way without understanding their arguments.
Speak for yourself. They are also used to write embedded languages or
to make semantic extensions to existing languages that require
source-to-source translation to convert the embedded syntax to CLtL.
This is precisely my main use of code walkers. Consider a simple object
oriented system where slots are referenced with AREF. I could (1) go in
and change the compiler, (2) try to use the compiler's internal
representation, or (3) code walk looking for slot names and replace them
with the appropriate AREF forms. (3) is the only method that has any
hope of portability, and the funarg to the code walker is 9 lines of