Re: TC problem

[Jonathan Rees <Rees@YALE.ARPA>]

    Date:    Thu, 8 Mar 84 19:19:40 EST
    From:    Jim Meehan <Meehan>
    To:      T-Bugs
    
    Suppose you run TC and load the following definition:
    
      (define-syntax (abc x) `(foo ,x nil))
    
    and then you try to compile the following file:
    
       (herald file)
       (define-syntax (abc x) `(foo x))
       (define (foo x) x)
       (define (baz) (abc 2))
    
    When compiling baz, it complains that you've called foo with 2
    arguments instead of 1, leading one to believe that it has used
    the *SCRATCH-ENV* definition of abc, not the one in the file.
    Shouldn't the file take precedence?

Check your T manual, 4th edition, page 79.  It says that DEFINE-SYNTAX
forms have no effect at compile time.  If you want a syntactic extension
to be available at compile time you must use DEFINE-LOCAL-SYNTAX.

I know that this is awkward.  In fact, DEFINE-MACRO is being retained
for this very reason: it combines DEFINE-SYNTAX and DEFINE-LOCAL-SYNTAX.

    (DEFINE-MACRO pattern . body)
    
is equivalent to

    (BLOCK (DEFINE-LOCAL-SYNTAX pattern . body)
           (DEFINE-SYNTAX       pattern . body))

except that it generates fewer warning messages... in other words,
it has effects at both compile time and run time.  Perhaps if I had
a name for DEFINE-MACRO which was consistent with DEFINE-...-SYNTAX,
it would be re-released.

I know that the situation with macros is not as smooth as it should
be.  As a matter of style, I would suggest that one's macro definitions
be sorted out into a separate file (module) from the files (modules)
which use those macros.  I realize that this is not acceptable to
everyone.  Part of the problem is that there is currently no way to
put two modules in the same file.  Work is in progress.

The DEFINE-SYNTAX/DEFINE-LOCAL-SYNTAX separation was motivated by
the desire to force the interpreted and compiled languages to have
the same semantics, and therefore prevent people from being able to
complain that "my code runs interpreted but not compiled" (and prevent
critics of Lisp from claiming that Lisp has ill-defined semantics).
In order to accomplish this, the interpreted language may have to
become more disciplined or restrained.  Your bug report has to do
not with TC but with the evaluator, because the evaluator doesn't
enforce the restriction stated in the manual.  The compatibility goal
has not been achieved, but we're getting closer to it.