[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
portable code walkers vs. portable code
- To: common-lisp@SU-AI.ARPA
- Subject: portable code walkers vs. portable code
- From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
- Date: Thu 10 Jul 86 16:43:43-MDT
Date: Thu, 10 Jul 86 17:08 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
What's this talk about portable code walkers. You can't write portable
code at all if you use implementation-specific lambda-list keywords, let
alone portable code walkers.
Date: Thu, 10 Jul 1986 17:35 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
The option to include additional lambda-list keywords may or may not be
a good idea, but it certainly is not an issue for someone implementing a
portable code walker. Portable code walkers would only work on portable
code, and that would not contain any such extensions.
I must disagree with this sentiment. Perhaps there is is come confusion
between a ((portable code) walker) and a (portable (code walker)). The
issue is not whether or not my program-analyzing program uses nonportable
lambda-list keywords. It's whether my program-analyzing program has to
be able to recognize these beasties in the code it's analyzing.
My contention is that it should be possible to write a portable program to
"walk" *any* valid Common Lisp program. After all, this was the rationale
for prohibiting implementations from defining their own additional special
forms, right? If you allow implementations to extend the syntax of
lambda lists, you might as well let implementations extend the syntax by
introducing more special forms, and let users define their own special
forms too. And once we do that, we might as well forget about having a
standard Lisp dialect in the first place.
As an example of the kind of code walker I had in mind, consider a simple
cross reference utility, something that traverses a function and keeps
track of what other functions it calls. (Perhaps the purpose of the
utility is to locate references to implementation-specific functions.)
As long as I know exactly where evaluable code can or can't validly appear,
I can certainly write this utility in a portable manner, regardless of
whether the bits of code it analyzes are portable or not. However, if
every implementation is free to extend the syntax of the language however
it wants, it would be impossible to write a portable program that checks
for portable usage!
In short, I think it is certainly valid for implementations to include
implementation-specific functions, variables, and macros, (hopefully not
living in the Lisp package), and still call themselves "Common Lisp".
But an implementation that includes syntactic extensions should not call
itself "Common Lisp".