[plt-scheme] determine free variables

From: Sam TH (samth at ccs.neu.edu)
Date: Sat Mar 29 13:54:00 EDT 2008

On Sat, Mar 29, 2008 at 1:47 PM, Jay McCarthy <jay.mccarthy at gmail.com> wrote:
> Thanks for the update.
>
>  The following difference remains:
>
>  Your id case is:
>
>  [id
>      (identifier? #'id)
>      (if (eq? 'lexical (identifier-binding #'id))
>          (list #'id)
>          null)]
>
>  While mine is:
>
>  (let ([i-bdg (identifier-binding #'id)])
>           (cond
>             [(eqv? 'lexical i-bdg)
>              (list #'id)]
>             [(not i-bdg)
>              (list #'id)]
>             [else
>              empty]))
>
>  I don't think eq/eqv matters. But when the identifier-binding is #f
>  does. I find many errors in transformed code if these are not
>  considered free. I don't really understand why, but I believe I came
>  to this particular test by looking at what the macro debugger said
>  some obviously free vars identifier-binding was.

It seems that #f should only be returned if the binding refers to a
variable bound at the top-level (the real top-level, no in a module).
Are you trying to handle this case?  That seems more analogous to the
module-bound variable case, which are not included in the results in
either implementation.  Can you describe the code that goes wrong
without that?

>  I presume that your implementation will be much more efficient than
>  mine, btw, given its use of identifier mappings.

All the credit for the implementation goes to Matthew, who originally
wrote it.  I just made it a library.

Thanks,

sam th

>
>  Jay
>
>
>
>  On Sat, Mar 29, 2008 at 10:41 AM, Sam TH <samth at ccs.neu.edu> wrote:
>  > On Mon, Mar 24, 2008 at 9:18 PM, Jay McCarthy <jay.mccarthy at gmail.com> wrote:
>  >  > That's interesting.
>  >  >
>  >  >  A note though: that implementation doesn't handle
>  >  >  letrec-syntaxes+values which isn't in true fully expanded code, but
>  >  >  will show up in the result of local-expand with an empty stop list.
>  >  >  (I've talked to mflatt about this and he said there isn't a way to get
>  >  >  true fully expanded code.)
>  >
>  >  This is now fixed.  If you could take a look at it and see if there's
>  >  anything else that needs to change for you to be able to use it in the
>  >  webserver, that would be great.
>  >
>  >  Thanks,
>  >  --
>  >
>  >
>  > sam th
>  >  samth at ccs.neu.edu
>  >
>
>
>
>  --
>
> Jay McCarthy <jay.mccarthy at gmail.com>
>  http://jay.teammccarthy.org
>



-- 
sam th
samth at ccs.neu.edu


Posted on the users mailing list.