[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Date: Mon, 23 Dec 85 22:52:38 EST
From: Jim Meehan <csi!meehan%UUCP at YALE.ARPA>
While there's lots of room to argue about whether certain macros (e.g.,
the ones in Categories I and III) could or should be special forms, I
don't know how you can avoid all 32 of the macros in Category II, and
I doubt you'd recommend making them all special forms.
This is a good point; however, there's a very big difference between
language-provided syntactic extensions like AND, OR, and LET, and the
fact that user-supplied macros are desirable. Clearly the language
should have a tiny set of primitive special forms (5 is about the right
number, although I think a T kernel would end up having about 11), and
syntactic sugar should be clearly marked as such in any reasonable
I'll go over your catalog anyhow, to see whether the existence of any of
T's macros would argue for the desirability of user-written macros. I
don't think they do.
II. Macros useful (i.e., reasonably meaningful) anywhere:
I use these, but practically never want to invent new things like them,
so I wouldn't consider it a terrible inconvenience to have the set of
such things (mostly pretty fundamental control constructs) bound at
language design time.
This is a very peculiar one which I don't understand quite what to do
with. It's probably completely unnecessary.
I rarely use any of the above, and given my druthers would probably
prefer to see them disappear from the manual & implementation.
These have no right to be macros. They should be procedures which take
procedure arguments, just as in MIT Scheme.
Locations have second-class status in T, and if things like this are to
exist at all, locations should be made first-class.
III. Macros that might be [reasonably implemented as] special forms,
but are useful anywhere, not just at top level:
I don't quite understand the distinction between II and III, but again I
don't see quite how users would want to extend this set. CATCH and BIND
should be procedurized; OBJECT should be primitive; all the others are
trivial syntactic sugar, but deal with semantically primitive concepts,
not special members of an open-ended class of features.
IV. Other macros (mostly implementation stuff):
Many of these (like IF-INTEGRATED) are disappearing, and exist only due
to design or implementation inadequacies; others are part of the user
interface, not the language (like PP and TRACE), and should not be
implemented by expressions; others are either primitive or trivial.
Again, I don't see how I, or users generally, would want to write macros
similar or analogous to these. If they do it probably implies a gross
deficiency in the language, and has a better solution than the
sledgehammer of a user macro facility.
I'm not saying there shouldn't be a macro facility, or that the language
shouldn't have a limited amount of syntactic sugar, but rather that I
practically never see a legitimate use of a macro by anyone other than a
language designer. It's good to be able to be a language designer, but
it's a subtle and difficult art, and correct, orthogonal implementation
is even harder than correct, orthogonal design.
If people have good counterexamples to this argument, I would like to
- Re: syntax
- From: Andy Freeman <ANDY@SU-SUSHI.ARPA>