[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Date: Fri, 3 Jun 88 11:19:31 MST
From: "Mike Coffin" <firstname.lastname@example.org>
I've got extend-syntax working in T. Now I'm wondering how it ought
to be packaged. Should there be extend-syntax and
extend-local-syntax, in analogy to define-syntax and
You can avoid the question entirely defining a form that evaluates to a
syntax descriptor, similar to T's MACRO-EXPANDER macro (at least I think
that's what it's called), and not defining any defining forms at all.
Suppose you call it EXTENDED-SYNTAX: then you would do
(extended-syntax pat1 pat2 ...))
(extended-syntax pat1 pat2 ...)).
This would be much more orthogonal than having two (or more) defining
By the way, for all you fans of T's macro system, I think that the
DEFINE-SYNTAX form was a mistake. If there is to be any explicit
support for definition of macros as a side-effect of loading a file,
there ought to be a special form (TARGET-SYNTAX-TABLE) that returns the
syntax table into which DEFINE-SYNTAX would store the expander; then one
(set (syntax-table-entry (target-syntax-table) 'foo)
(macro-expander (foo x y) ...)).
Better would be to use an ordinary variable instead of
(target-syntax-table), but that would have the problem of how the name
for that variable is chosen (by the HERALD form perhaps?) and how it
becomes bound (by LOAD?). Best would probably be to force the programmer
to decide for himself into what syntax table the macro should go.
Any of these would drive home the point that many people (especially
MacFranzCommon hackers) find confusing, that DEFINE-SYNTAX is a load
time phenomenon. Coupled with a fix to the file loader whereby the
entire file is macroexpanded before any of it is executed, I think the
danger of compiled/interpreted code incompatibility would be greatly
Flushing DEFINE-SYNTAX would also have the benefit of freeing up the name
for some better purpose, e.g. that now served by DEFINE-LOCAL-SYNTAX.