[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
macros
Date: Fri, 10 Apr 87 10:26:31 cdt
From: David Bartley <bartley%home%ti-csl.csnet at RELAY.CS.NET>
-- One or two namespaces or a hybrid?
I think this could coherently go either way. T switched from one
namespace to two after a year or so in order to be compatible with MIT
Scheme. I'll flame about this later if need be.
How do we deal with the fact that both macro/syntax keywords and
variables are drawn from the same set of identifiers? I think
lambda-bound names should take precedence over keywords, but should
LET-SYNTAX-bound keywords take precedence over lambda-bound names of
an outer level?
For symmetry, the answer must be yes.
What about top-level DEFINE? Does (DEFINE X ...), like (LAMBDA (X) ...),
take precedence over keywords?
A harder question. The definition could be an error if X has a keyword
binding in that lexical contour.
What do we do with keywords that appear in places where a keyword is not
expected, like (+ IF AND), and thus appear to be variable references?
Error.
Should we embed syntax tables in the lexical environment or keep them
separate?
This is practically the same as the one versus two namespace question.
I don't know what distinction you're trying to make here.
For those who might prefer a single namespace: should INLINE and other
optimizations be encompassed? How about named constants like PI and
EOF-OBJECT?
No. No.
-- Mutable or immutable syntax tables?
Immutable. Otherwise you get all sorts of obscure bugs and disgusting
semantic questions. The semantic questions remain if an STF (i.e.
expander) can detect or produce side-effects, but every little bit of
sanity helps.
It seems excessively cumbersome to wrap a LET-SYNTAX around a file or
collection of files.
Immutable does not imply LET-SYNTAX. A DEFINE-MACRO-esque for could
work just as well. Simply make DEFINE-MACRO part of the syntax of a
<program> (or perhaps even a <body>. The scope of the macro then starts
at the point the DEFINE-MACRO occurs, and ends at the end of the file,
<program>, or <body>.
Why should extending the syntax differ from the style of incrementally
adding definitions with DEFINE?
Maybe it shouldn't. The main difference is that DEFINE's can be
mutually recursive, whereas you run into all sorts of nasty problems if
you try to make the scope a macro definition include any text that
precedes it. (This is because you have to expand macros in order to
determine whether or not a macro definition is present in the first
place.)
Perhaps INCLUDE is a better answer than LOAD.
Perhaps. This seems like an independent question, however, more
properly discussed under the heading of "modules".
-- Solution of capture problems
Eugene and others have addressed this.
What is the computational complexity of the hygienic expansion
algorithm, by the way?
-- Must a macro expand into an expression--i.e. not a keyword?
Yes.
-- Which syntax table is used by various REPLs, LOAD, COMPILE-FILE, etc.?
The report doesn't talk about REPL's. The syntax table for files should
be the standard one (i.e. the one with only the official bindings in it,
no user bindings). If the file wants to use nonstandard syntax it must
explicitly request them using a DEFINE-MACRO or USE-SYNTAX-TABLE form
which is effective only for that file.
For controlling the REPL's syntax table, you could have something like
(set-current-syntax-table ...). This should have no effect on which
macros are seen by LOAD, however.
-- What about macros that expand into multiple definitions?
No problem: the expansion can be (begin (define ...) (define ...)).
BEGIN behaves like Maclisp's (PROGN 'COMPILE ...).
-- Should a macro writer have the ability to make absolute (that is,
"qualified") references?
I don't see what the alternative is. Otherwise there's no way to write
things like QUASIQUOTE.
-- Should COMPILE-FILE execute any of the forms it compiles?
Yes, the right-hand side of a DEFINE-MACRO or USE-SYNTAX-TABLE, and the
body of an (AT-PREPROCESS-TIME ...).
-- Can we avoid EVAL-WHEN ?
Yes, but we might need something like (AT-PREPROCESS-TIME ...) in order
to make definitions available to expansion procedures.
* * *
How much agreement must we reach to be useful?
-- basic principles?
Deciding how identifiers in programs are resolved as references is a
good start.
The R^3 report hedges this question, and we may be able to persist in
this.
-- a syntax for >using< macros?
Necessary. There's not much point in defining a macro if you can't use
it.
We're probably wedded to the current syntax that can only distinguish
macros from applications by recognizing keywords.
This is not a problem.
-- a syntax for >defining< macros?
A portable way for defining "global" macros would satisfy many users
and may be easier to reach agreement on than dealing more deeply with
scoping issues. On the other hand, many of us will probably proceed
to implement lexically scoped syntax definitions.
I think scoped macros are absolutely essential. Otherwise there's
absolutely no hope of writing portable code, as Jim Miller has reminded
us.
-- user-friendly syntax for defining macros
Since user-friendly macro definition capabilities tend to have
restricted capabilities, this will probably always be an extension
beyond more primitive capabilities. Perhaps this is a candidate for
the "yellow pages."
Please define user-friendly. I certainly would hope that something that
complicated could be defined as a yellow-pages layer. Obviously no one
would would want to actually write macros using only the low-level
primitives in my proposal. I have implemented something a bit higher
level which, like EXTEND-SYNTAX, uses an input pattern, but unlike
EXTEND-SYNTAX doesn't use an output pattern. But it's not obvious that
everyone will like either my pattern language or Gene's, so I advocate
making the lower-level hooks available as well.
Next time try to come up with some challenging questions.... 8*&
Jonathan