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
> sbl...@adelphi.edu
> 


_________________________________________________
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/users

Reply via email to