[racket] Again on bindings visibility in eval

Well, perhaps eval is the only way to go. There are situations where you need it; otherwise it wouldn't be there - Matthias



On Jul 13, 2011, at 5:30 PM, Maurizio Giordano wrote:

> Hi Matthias, hi all
> 
> 2011/7/13 Matthias Felleisen <matthias at ccs.neu.edu>
> 
> 
> [I hadn't forgotten your messages, it's just that deadlines got in the way.]
> 
> I still don't understand your desire to access the environmental variables specially:
> 
> 1.  if you generate a closure or a struct full of closures in your macro, the expression that you pass in captures the variables in its context:
> 
> > (define-syntax-rule (mystuff y expr) (lambda (x) (displayln `(expr ,y)) (if expr x 0)))
> > [  (let ((t 333)) (mystuff t (> t 444)))   22]
> ((> t 444) 333)
> 0
> 
> See it really does get t's value from the context.
> 
> Yes it does ... I know that if the macro returns the lambda ...
> no problem, unfortunately my macro returns something like:
> (eval `(lambda ...))
> Now the question is: Can I rewrite my macro to generate the same code
> without using the "(eval `(lambda  ...))"?
> I don't know, I feel yes ... but at the moment I don't know how to
> redesign it.
> My lambda code is not a predefined template
> (the quasiquote) with some small parts to be instantiated (with unquoting).
> First, the lambda code is very large,
> Second, it is recursively produced by an expander function (used in the macro).
> When you call the macro, you don't know in advance how many times 
> the expander will call itself. It is something like:
> 
> (define-syntax-rule replace
>    ...
>    (eval `(lambda (x) 
>                  ... static part ...
>                  ,(expander ...)   ; this inject a part of the lambda code   
>                  ...)))
> 
> (define (expander ...)
>   `(let ((...))
>        ... static part ...
>        ,(expander ...)             ; injection once again   
>        ...))
> 
> 2a. do you have reason to access variables other than throwing them into the environment for eval? In that case your problem is solved.
>  
> 2b. if not, what are the reasons to guess at variable names in the context of the macro USE (not definition)?
> 
> I try to answer to both questions:
> 
> My macro is the primitive of a new language:
> 
> < elem1, elem2, ... , (replace x y by (+ x y) if (> x othervar)) >
> 
> the replace macro has the following inputs:
> x, y = free variables to be matched on a set of elements (<...>)
> (+ x y) = a form to be inserted in the set inspite of x and y
> (> x othervar) = a conditional form: here x is matched (bound) locally,
> othervar is  a symbol "outside" the set (that is the scheme top env or
> any other inner env like a let)
> This is why I need that the produced lambda USE outside symbols.
> At the moment, in my implementation, the lambda can use outside
> symbols if they are defined in the top env ... I would like to have it also in
> inner environments. 
>  
>   
> ;; ----------------
> 
> 
> SEPARATE QUESTION: Now you also write that you process the code before you throw it to eval. Is it possible to write functions on syntax that process the code and perform the optimizations that Racket doesn't perform for you?
> 
> That's an interesting question: yes ... I process A LOT the code before
> I throw it to the eval ... as I said you it is like a compiler (... my first research area... many years ago!)
> First: I generate recursively the code with a my expander function (not the one of racket)  
> Second: I (try) to generate an efficient code to simulate the runtime of the language (the chemical language) I have implemented on top of racket.
> If you look at the generated code, you can figure out several optimizations.
> One is "inlining": if I have a lambda (in my case a chemical rule) that will be executed many times (on all possible combinations of elements in a set), 
> and each time the lambda may use recursion, than, from my experience it is
> better to explode recursive calls in recursive inlining of code.
> From your question I understand that you mean "optimizations of racket
> code" that racket does not do.
> 
> Absolutely an interesting discussion... thanks.
> 
> Cheers,
> Maurizio.
>   
> -- Matthias
> 
> 
> 
> 
> 
> 
> On Jul 13, 2011, at 3:54 PM, Maurizio Giordano wrote:
> 
> > Hi all, hi Matthias,
> >
> > I would like to come back to my (still unsolved) problem I
> > proposed some days ago:
> >
> > when using define-syntax in a inner scope of bindings (like let),
> > in this example:
> >
> > (define-syntax mymacro
> >   (syntax-rules ()
> >     [(_ x)
> >       (eval `(lambda (w) (print (quote x)) (if x w #f)))]))
> >
> > (let* ((s 3) (f (mymacro (> s 0)))) (f 5))
> > reference to undefined identifier: s
> >
> > of course if you:
> >
> > (define s 3)
> >
> > in the top environment, the error will not appear.
> > This is even more clear if you expand the macro:
> >
> > (syntax->datum (expand '(mymacro (> s 0))))
> > ... you see that "s" is a %top binding.
> >
> > I know that if I make the macro to return directly the lambda,
> > it works. Nevertheless, in my implementation, I still need to use
> > the "(eval (quasiquote (lambda ...)))".
> > Why? my macro is like a compiler
> > that generates a lambda code very huge: the code  is recursive in some of its part,
> > but, for efficiency reasons, i preferred to inline all recursive calls. So I use a
> > function "expander" that makes recursive inlining (or injecting) of code).
> > It is more or less something like:
> >
> > `(lambda (...) ... static-code...  ,(expander ...) ...)
> >
> > where "expander call itself with different parameters.
> >
> > This is just to know your opinion... if the "(eval (quasiquote (lambda ...)))"
> > cannot see local bindings like in let*, than I have to choice:
> > 1) renounce to the feature.
> > 2) looking for alternative methods to generate my code with recursive inlining
> >
> > Than you,
> > Cheers,
> > Maurizio.
> 
>