[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Scheme-reports] Procedural equivalence: the last debate



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 <51AE7631.4050903@x" target="_blank">51AE7631.4050903@x>, 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 <alexshinn@x> wrote:
On Wed, Jun 5, 2013 at 9:00 AM, John Cowan <cowan@x> 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
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports


_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports