I don't think there is a source-level representation that has those operations explicit in Racket. If you need to change the way closures are represented to do your experiments, you will probably have to work at a very low-level.
I think it would help you to look at Casey's model of the Racket machine. It will help you understand what the low-level representations actually are, which will probably help you undertand what would be easy to change and what isn't (there is "closure-ref" for example). http://plt.eecs.northwestern.edu/racket-machine/ The short version: if you can stick with using lambda and variables as the output of your transformations, you'll be much happier than if you cannot. Robby On Fri, Nov 23, 2012 at 9:09 AM, J. Ian Johnson <i...@ccs.neu.edu> wrote: > I mean the difference between a constant closure that takes an extra vector > argument for the environment and a Racket closure that has its own > environment representation. > Lightweight closure conversion and super-beta inlining both need a way to > access surrounding environments for the shared bindings, so it would be nice > to just use Racket's own closure-ref (or whathaveyou) to do that rather than > change all affected functions to use a different calling convention with > vectors. > -Ian > ----- Original Message ----- > From: "Matthew Flatt" <mfl...@cs.utah.edu> > To: "J. Ian Johnson" <i...@ccs.neu.edu> > Cc: "dev" <dev@racket-lang.org>, "J. Ian Johnson" <i...@ccs.neu.edu> > Sent: Friday, November 23, 2012 8:54:58 AM GMT -05:00 US/Canada Eastern > Subject: Re: [racket-dev] Experiments with closure conversion > > Sorry --- I don't understand what you mean by "lightweight closures use > the same representation". > > If you convert a `lambda' so that it doesn't capture any variables --- > perhaps because you moved formerly captured variables to a vector > argument --- then the compiler will compile it as a constant closure > (or a module-level closure if it captures only module-level bindings). > > The compiler will not detect that a particular argument of a function > is always a vector, that the vector is always size N, that the vector > always contains the values of N variables, and therefore that the > vector argument can be replaced by N arguments to avoid constructing > the vector. > > At Wed, 21 Nov 2012 13:03:06 -0500 (EST), "J. Ian Johnson" wrote: >> 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" <mfl...@cs.utah.edu> >> To: "J. Ian Johnson" <i...@ccs.neu.edu> >> Cc: "dev" <dev@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 > _________________________ > Racket Developers list: > http://lists.racket-lang.org/dev _________________________ Racket Developers list: http://lists.racket-lang.org/dev