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

[Shiro Kawai <shiro.kawai@x>]

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