Oops, I'm probably lost... Does the current discussion suggests that fresh location tag must be allocated for every time lambda expression is evaluated, even the lambda expression doesn't close any mutable state?
As Per Bothner posted in <[email protected]>, lifting constant lambdas to upper level is the important optimization and I heavily rely on it. (What I see from Will's suggestion isn't that extreme; the compiler can "mark" the procedure in some way so that even the optimizer duplicates lambda exprs (hence can't retain eq?-ness) it can still eqv? to each other.) On Tue, Jun 4, 2013 at 2:41 PM, Alex Shinn <[email protected]> wrote: > On Wed, Jun 5, 2013 at 9:00 AM, John Cowan <[email protected]> wrote: > >> Alex Shinn scripsit: >> >> > As I see it, once a procedure escapes, the existence of any semantics >> > in the language which can discriminate the procedure location requires >> > it to be boxed. This is true whether the discriminator is eq? or eqv?. >> >> Well, it depends what you mean by "boxed". >> >> It means that the location tag no longer has to be identified with the >> unique address of the procedure. The procedure can be copied any number >> of times (each of which is distinguishable by `eq?`), but the location >> tag (which is what `eqv?` looks at) has to be copied with it; it can be >> any arbitrary value at least as wide as an address. >> > > Sorry, I think I finally see what is being suggested. > > Is the idea basically to transform: > > (let ((f (lambda ...))) > (... f ...) > ... > (... f ...)) > > into: > > (let ((f (lambda ...)) > (location (generate-unique-value))) > (... (box f location) ...) > ... > (... (box f location) ...)) > > ? > > Thus the escaped f's would not be eq? but could the > location tag could be compared by eqv?. > > Using addresses wouldn't work, generate-unique-value > would have to increment a global counter (which need > not be unique to this location). Though if the counter > ever overflows into a bignum all optimization is lost. > > -- > Alex > > > > _______________________________________________ > Scheme-reports mailing list > [email protected] > http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports > >
_______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
