On Thu, Mar 13, 2003 at 10:21:25PM +1100, Damian Conway wrote:
: But what we can't allow is a reference parameter to coerce its argument. 
: For example:
: 
:       sub loggedincr (Int $i is rw) {
:               print $log: "Incremented $i.id()\n";
:               $i++ unless $i.constant;
:       }
: 
:       # and later...
: 
:       int $x = 7;
:       loggedincr($x);
: 
: The $i parameter *can't* be bound to $x, because $x doesn't have the 
: necessary features to be an Int (e.g. it doesn't have the capacity to 
: respond to method or property lookups).

But we've already said that an int will try to behave like an Int
as much as it can, including calling methods on it as if it were
an Int.  The "int" is just a hint that you'd like compact storage
and fast loops  And it's probably a stronger hint on an array than
on a solitary scalar.

: Even wrapping $x in a temporary Int 
: wouldn't help, since it would render the logging of an .id meaningless. The 
: whole point of having types is to catch this kind of problem at 
: compile-time.

A proxy Int could certainly calculate its id from the location of the
actual int, if it came down to it, so that different proxy Ints have
the same id.  And if the outer scope establishes the proxy Int at the
same time as it allocates the int, there will only be one of it anyway.

And we'd only need to create the proxy if we know we might be passing it
to an C<rw> parameter somewhere.  C<constant> parameters on Int, Num, Str
and Ref should be free to implement themselves with copy semantics anyway.
If you want to take a ref to a parameter, you'll have to declare it C<ref>
or C<rw>, I suspect.

Things get dicier with viewing an Array of int as an Array of Int, but
again, the Array of Int could know that it's a proxy for an Array of int.
It's just an object with an interface, after all.  And it could generate
smart proxy references as the need arises, in cooperation with the Array
of int as necessary to avoid .id bifurcation.

I am not suggesting that we open up the barn doors to allow anything
to be coerced to anything else willy nilly.  I am suggesting that we
maintain the easy integer <-> number <-> string semantics of Perl 5
when the rest of the type system allows it.  Data structures would
still have to be conformant--I'm talking about the leaf semantics,
not the tree semantics.

Larry

Reply via email to