CORRECTION: optimizing with === immutable comparitor

2006-07-14 Thread Darren Duncan

At 12:30 AM -0700 7/14/06, Darren Duncan wrote:
If $a === $b means what I think it does, then I believe that a 
not-premature implementation optimization of === would be that it 
always $a := $b if it was returning true, so that any future === of 
$a and $b or aliases thereof could short-circuit with a =:= test 
even if they weren't created as aliases, and Perl would be 
automatically more memory efficient without those extra storage 
copies.


Sorry, I stated some things badly in that previous email, mainly the 
$a := $b part, which is technically incorrect, so I will try and 
clarify what I meant to say.


What I propose concerning non-premature === optimizing is a system 
where, at any time that two appearances of the same immutable value 
are compared with ===, they are immediately consolidated into a 
single appearance.  Or at least $a.value := $b.value occurs 
immediately, and garbage collection of the second and now 
unreferenced copy happens whenever it would happen.


For illustration:

 $a = 'hello'; # one copy of the value 'hello' in memory
 $b = 'hello'; # a second copy of the value 'hello' elsewhere in memory
 $c = 'world'; # one copy of 'world' in memory
 $a === $b; # now only one copy of 'hello' is in memory, $a and $b point to
 $a === $c; # nothing changes, as values are different
 $b = $c; # now only $a points to 'hello', $b and $c point to one 'world'

I of course did not mean for the actual symbol $a := $b to happen, 
only what they point to internally.


Of course, the above example could be constant folded to one copy of 
'hello' at compile time, but my illustration is meant to be for 
situations where $a and $b are declared or set far apart, possibly 
from run-time input values, so the folding happens at run time.


What I meant with the =:= shortcut then, is that $a.value =:= 
$b.value could return true following the above run of $a === $b.


Sorry for any confusion.

FYI, I plan to explicitly illustrate the principle in my next 
Set::Relation update, since its types are immutable, so that any 
operations which involve comparing two relations or tuples or 
headings or values therein with === will have a side-effect of 
consolidating them if they are equal.  Later on, if this happens at 
the language level, I would less likely have to do it myself.


-- Darren Duncan


Re: CORRECTION: optimizing with === immutable comparitor

2006-07-14 Thread Ruud H.G. van Tol
Darren Duncan schreef:

 What I propose concerning non-premature === optimizing is a system
 where, at any time that two appearances of the same immutable value
 are compared with ===, they are immediately consolidated into a
 single appearance.

That should only be done voluntarily. A bit like memoization.

Something else: An immutable composite value can have unfinalized parts.
Finalizing them for the sake of a deep comparison, can hurt performance.
Does a lazy system need something like 'undecided' or 'NaB'
(not-a-boolean)?

-- 
Groet, Ruud