syntax

[Jonathan A Rees <JAR@MC.LCS.MIT.EDU>]

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

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:
    COND 	XCOND
    CASE	XCASE
    SELECT	XSELECT
    OR
    DELAY
    SET
    ITERATE
    DO
    AND

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.

    MACRO-EXPANDER

This is a very peculiar one which I don't understand quite what to do
with.  It's probably completely unnecessary.

    DESTRUCTURE
    DESTRUCTURE*
    BLOCK0
    DECREMENT
    LET*
    INCREMENT                
    BIND*                    
    POP
    PUSH

I rarely use any of the above, and given my druthers would probably
prefer to see them disappear from the manual & implementation.

    WITH-OUTPUT-WIDTH-STREAM
    WITH-INPUT-FROM-STRING
    WITH-OPEN-STREAMS
    WITH-OUTPUT-TO-LIST
    UNWIND-PROTECT
    WITH-OUTPUT-TO-STRING    

These have no right to be macros.  They should be procedures which take
procedure arguments, just as in MIT Scheme.

    MODIFY
    MODIFY-LOCATION
    EXCHANGE                 
    SWAP                     

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:
    OPERATION                         OBJECT 
    LOCATIVE                          LOCALE 
    LET                               LABELS 
    CATCH                             BIND   

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):
    DEFINE-INSTANCE-METHODS           %DEFINE-SYNTAX               
    IGNORE                            DEFINE-MACRO                 
    DECLARE-SETTER                    REFERENCE                    
    ^                                 DEFINE-STRUCTURE-SELECTOR    
    COMMENT                           IGNORABLE                    
    OPERATION-DISPATCH                UNTRACE                      
    **BACKQUOTE-MARKER**              GC-DEFER                     
    HANDLER                           IMPORT                       
    SYNONYM                           IF-INTEGRATED                
    REQUIRE                           HERALD                       
    TRACE                             PP                           

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

Jonathan