Re: Syntax checks

[Lynn Winebarger]

On Sunday 07 April 2002 05:40, Marius Vollmer wrote:
> Neil Jerram <address@hidden> writes:
> > Also, does this fit into a more general picture of how we should
> > evolve the interactions between transformation, evaluation,
> > compilation etc.?  (I don't claim that such a picture exists, but it
> > would be nicer if it did.)
>     [snip]
>     But having a compiler for Guile is still an important goal, but we
>     should do it Right rather than rush it.  I plan to attack it from
>     above, by first straighten out the module system to be friendly to
>     compiler semantics, redoing our current memoizer to be no longer
>     tangled with the evaluator and then having a way to write memoized
>     code to disk and load it back in.  Down that road are enough
>     design problems that are important for good compiler support, long
>     before we come close to worrying about how to produce native
>     machine code (or even cross compiling).

        Are you actively working on the module system/first class 
environments?  The TODO list currently only lists 1.6 and "Eventually"
as target times.   I am interested in this particular task, but am still poking
around the source.   It's not entirely clear what the exact difference between
environments and modules is (or should be).  Well, there's import/export and
syntax readers.  
     I did go back and read a lot of discussion from late 2000/early 2001,
but I'm not sure how much has sunk in yet.  
     Also, while I'm aware modules should act orthogonally to objects in
terms of introducing namespaces, it seems to me the module system
should allow constructs similar to the imperative object-oriented languages.
Before I go on, though, I'd like to find out if there's any point to doing so.

>  > [interaction of macros and compilation should interact how? ]       
>     Common Lisp will offer good hints, I guess.  This is what I want
>     to iron out when separating the memoizer from the evaluator.  I
>     want to make these questions 'central' to Guile, that is, the
>     basic semantics of Guile are affected by this, not just the
>     odd-ball compiler user.  This will ensure that compilation is
>     consistent with using Guile interactively.
       
         The real question (lingering from at least late 2000) seems to be
whether lambda abstractions should delay expansion as well as evaluation.
My first impulse is to say it shouldn't, that macros are "evaluated" at read 
time.  Among other effects of using lambda to delay expansion, you have
introduced a definite evaluation ordering of applications.  I'm guessing one
of the appeals of this behaviour is that in
(define (foo x) (bar x))
(define (bar x) (+ x 5))
(define-syntax bar (syntax-rules () ((_ x) (+ x 5))))

    the 2 definitions of bar work "the same".  However, IMO, the second
definition should yield an  error in  (foo 4)  because it's evaluation time 
and bar evaluates to a macro, and 5 is not "syntax". 
    Mainly, however, I see this as a kind of lexical scoping - if you 
re-evaluated macros whenever they changed, you have a kind of 
dynamic scope.  I know this was characterized by Marius in the opposite
way in the earlier (late 2000) discussion.  I.e. that because macro expanding
at read time captures whatever value of the syntax binding was lying around
rather than the binding itself (to be used over and over), it is "dynamic".  
Well,
I don't have a great counter to this, it's just my intuition says that expanding
at read time gives you a "what you get is what you write" promise of 
lexicality.  Or actually that the other scheme is even more dynamic than 
expanding at read  time.  Besides which the expansion stage is supposed to 
occur (completely) before either interpretation or compilation, not intertwined
with it.  I guess I sort of see define-syntax as implicitly introducing a new,
inescapable and non-bracketed scope.  
    Probably the most compelling reason to expand at read time, though is that
any sane compilation system would not go re-compiling every bit of code just
because someone redefines lambda or if at the repl.

Lynn