macros

[David Bartley <bartley%home%ti-csl.csnet@RELAY.CS.NET>]

I confess that I find the macro problem to be one of the hairiest yet
one of the most important ones we face.  I'm not yet ready to comment
on Jonathan's proposal because it differs so much from my current
approach that I need to re-examine my assumptions and biases.

Before debating the specific merits of any particular proposal,
perhaps we should discuss some basic issues first and work our way up
from there.  I'd also like to get a feel for what kind of an
agreement, and how much of one, we should be working towards.

My list of basic issues regarding macros includes...

  -- One or two namespaces or a hybrid?

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?

What about top-level DEFINE?  Does (DEFINE X ...), like (LAMBDA (X) ...),
take precedence over keywords?

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?

Should we embed syntax tables in the lexical environment or keep them
separate?

For those who might prefer a single namespace: should INLINE and other
optimizations be encompassed?  How about named constants like PI and
EOF-OBJECT?

  -- Mutable or immutable syntax tables?

It seems excessively cumbersome to wrap a LET-SYNTAX around a file or
collection of files.

Why should extending the syntax differ from the style of incrementally
adding definitions with DEFINE?

Perhaps INCLUDE is a better answer than LOAD.

  -- Solution of capture problems

Eugene and others have addressed this.

  -- Must a macro expand into an expression--i.e. not a keyword?

Suppose an (*IF*) macro expands into the identifier IF.  Then how does
one interpret the result of the expansion ((*if*) a b c) ==> (if a b c)?

  -- Which syntax table is used by various REPLs, LOAD, COMPILE-FILE, etc.?

  -- What about macros that expand into multiple definitions?

  -- Should a macro writer have the ability to make absolute (that is,
     "qualified") references?

  -- Should COMPILE-FILE execute any of the forms it compiles?

  -- Can we avoid EVAL-WHEN ?

				* * *

How much agreement must we reach to be useful?

  -- basic principles?

Deciding how identifiers in programs are resolved as references is a
good start.

  -- a syntax for >using< macros?

We're probably wedded to the current syntax that can only distinguish
macros from applications by recognizing keywords.

  -- 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.

  -- 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."

What is a reasonable goal for us to work towards?

--db--