[racket] Again on bindings visibility in eval

It may very well be that I don't understand your point (it's late at my
place and I already had a couple of wiskeys) but can't you introduce the
variables x and y hygienically. If you have (let ((x ...) (y ...) ...) code)
as part of the expansion of a macro, then the code hygienically catches the
bindings. You may also find that in a template 'z, where z is a pattern
variable, does indeed expand to (quote
whatever-was-specified-for-z-in-the-macro-call) So may be you can do without
eval and quasiquote after all.
Jos

  _____  

From: users-bounces at racket-lang.org [mailto:users-bounces at racket-lang.org]
On Behalf Of Maurizio Giordano
Sent: miércoles, 13 de julio de 2011 23:31
To: Matthias Felleisen
Cc: users
Subject: Re: [racket] Again on bindings visibility in eval


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.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20110714/1dad62ca/attachment.html>