[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Definition time macros
- To: Fahlman@C.CS.CMU.EDU
- Subject: Re: Definition time macros
- From: Alan Snyder <snyder%hplsny@hplabs.HP.COM>
- Date: Tue, 15 Jul 86 16:47:49 PDT
- Cc: common-lisp@su-ai.ARPA
- In-reply-to: Your message of 15-Jul-86 18:18:00
No doubt about it, one can develop a cleaner semantics for a language
without an interpreter. Cleaner still is to require all of the code to
be presented at one time so that it can be compiled into a block and so
that everything can be checked statically -- none of this incremental
stuff. There are already lots of languages like that, and I'd hate to
see Common Lisp become one of them.
OK, this exaggerates your position, but I think that expanding macros
just once, at "enclose time" is a step in that direction.
The package system is another step in that same direction (I can't write a
call to a function in another package unless the package has already been
defined); is it too late to take back the package system? Common Lisp
straddles the fence regarding easy incremental change versus static checking
and efficiency; the result is that interpreter/compiler consistency is still a
I think the idea of definition-time macro expansion should be explored; the
result might be worthwhile. Two problems have been mentioned: propagating the
effects of redefining a macro, and source-code debugging. I believe (without
proof) that these problems can be effectively solved in a development
environment (a delivery vehicle might choose not to solve these problems).
Dependency chains can be used to propagate changes. The expanded code can be
annotated to indicate its relationship with the source code.