[racket-dev] Experiments with closure conversion
Your answer sounds like we're on the same page, so I'll follow up. Is there any way to communicate with Racket's closure conversion so that lightweight closures use the same representation? I would have to ensure that lightweight closures never flow to functions that I myself don't have the ability to transform to use the right calling convention.
Sharing is a separate optimization I am considering (Shao & Appel 2000)
Thanks,
-Ian
----- Original Message -----
From: "Matthew Flatt" <mflatt at cs.utah.edu>
To: "J. Ian Johnson" <ianj at ccs.neu.edu>
Cc: "dev" <dev at racket-lang.org>
Sent: Wednesday, November 21, 2012 12:56:09 PM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] Experiments with closure conversion
I think I don't yet understand the question.
Are you wondering about what happens to performance of a Racket program
when you convert the program's source before giving it to Racket? And
you wonder specifically about performing lightweight closure conversion
and how Racket will treat the converted program?
If so, since Racket has its own closure conversion, my guess is that
manually managing your own conversions will perform less well. It seems
possible, though, that you can convert a program so that it performs
better by using vectors that effectively allow sharing among closures.
At Wed, 21 Nov 2012 11:56:11 -0500 (EST), "J. Ian Johnson" wrote:
> I have a control-flow analysis of a subset of Racket that is similar to R4RS
> Scheme (only with immutability in the right places). In fact, I have many - in
> order to compare different analyses' effectiveness and precision, I have a
> series of post-hoc analyses and program transformations I want to do.
>
> One is lightweight closure conversion (Wand & Steckler 1996)
>
> Is a source->source transform that uses immutable vectors for passed
> environments and unsafe references for variable lookups enough to get the
> Racket compiler to pick up on what I'm doing?
> I'm really not quite sure which question to ask, since I haven't made my own
> higher-order language compiler top to bottom before, and don't know if there
> might be internal represenations that I'd need to use rather than user-level
> representations.
>
> Thanks,
> -Ian
> _________________________
> Racket Developers list:
> http://lists.racket-lang.org/dev