define-syntax

["Ji-Yong D. Chung" <virtualcyber@erols.com>]

    Hi,

(1)    By the way -- my apologies for sending multiple emails 
earlier.  As I already explained to Shriram, as a newbie here,
I was not certain if anyone was getting these messages.

(2) I noticed that you have not quite finished with define-syntax.
I suppose you will implement this soon enough.

    This is rather a general question regarding it and macros -- I was
wondering if you came across literature or anything that tries
to use macro to optimize code before "compilation" (prior
to evaluation).

    I would be grateful for any enlightenment (if you 
are familiar with it) on the topic.

For instance if you have 

    (let ((x #f)) x),

    this might expand to 

    ((lambda (x) x) #f)  

    which is inefficient.

    I was wondering of if you came across any system
that attempts to rewrite expressions as the one above,
using macros, to make it more efficient.

    For example, say you have define-syntax, as 
follows (assuming that lambda is not a special keyword)

    (define-syntax lambda
       (syntax-rules ()
          ((lambda (x ...) 
            b1 ...) 
           a1 ...)

           (begin 
             (define x a1) 
            ...
              b1 ...)))))

    The macro will rewrite the lambda expression
above (the inefficient one) as:

    (begin (define x #f) x)  

     If a non-optimizing compilation were done on
the preceding lambda expression and the "begin"
expression above, the begin expression would
result in faster code -- it eliminates stack frame
allocation.

.
(3)    I looked at your code for eval, and before eval is invoked,
it is pruning redundant code during "compile" stage.  
I also noticed that certain functions are inlined.  

    It is terriffic stuff.

----- Original Message ----- 
From: Matthew Flatt <mflatt@cs.utah.edu>
To: Ji-Yong D. Chung <virtualcyber@erols.com>
Cc: <plt-scheme@fast.cs.utah.edu>
Sent: Tuesday, December 19, 2000 10:48 AM
Subject: Re: efficiency


> Quoting "Ji-Yong D. Chung":
> >     Does anyone have good understanding of its
> > architecture and why MzScheme seems to be
> > so much faster than MITScheme?
> 
> As Shriram says, the interpreter is probably fast just because we've
> put most of our effort there.
> 
> More technically, the reason might have to do with the way function
> application special-cases argument expressions that are constants,
> lexical variables, and global variables. The eval-apply loop has also
> been carefully optimized by hand. And most primitives are implemented
> directly in C, so a program that spends a lot of time in "large"
> primitives like `memq' and `list-ref' gets the equivalent of compiled,
> optimized code.
> 
> But all of these architectural choices play against each other in a way
> that makes it difficult to compare alternaitves. We've simply spent
> time over the years working towards a local maximum for one particular
> set of choices.
> 
> Matthew
>