[racket-dev] Experiments with closure conversion

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 <ianj at 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" <mflatt at cs.utah.edu>
> To: "J. Ian Johnson" <ianj at ccs.neu.edu>
> Cc: "dev" <dev at racket-lang.org>, "J. Ian Johnson" <ianj at 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" <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
> _________________________
>   Racket Developers list:
>   http://lists.racket-lang.org/dev