[racket] Again on bindings visibility in eval

On Thu, 2011-07-14 at 08:53 -0400, Stephen Bloch wrote:
> On Jul 14, 2011, at 7:56 AM, Maurizio Giordano wrote:
> 
> > About optimization... in my case the main optimization is:
> > 1) My macro has to generate a function which has to perform some
> > recursive tasks 
> > (for example, it has to do a recursive pattern matching on a set of
> > elements)
> > 2) Instead of generating a recursive function, I generate one very long
> > piece of code that expand (I say "inline") all the (potential) recursion
> > point.
> 
> And how is that an optimization?  What are you gaining by making the code much longer?  If your function was "tail-recursive" (i.e. the result of the recursive call is returned as the result of the calling function, without any further processing), Scheme will already optimize it to take constant stack space (effectively replacing the recursive call, at the machine level, with some assignments and a "goto").  If it wasn't, it's very difficult to see how to inline it -- as I presume you've already discovered.
> 
> 
It is not tail recursive... as I reported in a past email, my macro
looks like this:

(define-syntax-rule replace
    ...
    (eval `(lambda (x) 
                  ... static part ...
                  ,(expander ...)   ; this inject a part of the lambda
code   
                  ...static part ...)))
 
(define (expander ...)
   `(let ((...))
        ... static part ...
        (for (...)
          ...
          ,(expander ...)             ; injection once again   
          ... static part ...)
        ... static part ...))

I am wondering if it can be easily transformed in tail-recursive ...
maybe!
You may tell me this is not appropriate to the scheme programming
syle... you are right. I choose this way since my objective is to
write a sort of macroexpander (a cross-compiler) from my source language
(gamma-calculus) to scheme.
At this cross-compiler development stage, by producing all the code in
one-shoot, for me it is easier to analyze it and find out several
(other) optimizations.

Maybe you do not agree...
Cheers,
Maurizio.    
 
> Stephen Bloch
> sbloch at adelphi.edu
>