--- David Storrs <[EMAIL PROTECTED]> wrote: > On Mon, Jun 16, 2003 at 10:15:57AM -0700, Michael Lazzaro wrote: > > > > On Friday, June 13, 2003, at 10:26 PM, David Storrs wrote: > > > > > my $a = 'foo'; > > > my Int $b = $a; # legal; $b is now 0; is there a warning? > > > my $c = $b; # is $c 0, or 'foo'? > > > > 0, I think. Or specifically, C<Int 0>. > > So then conversion from Scalar to Int is not lossless, and > (by extension) conversions from Scalar to any other LargeCapPrimitive > are presumably not lossless either.
Not *guaranteed* lossless. Indeed, how could they be? I suppose you could construct your scalar as: my $a = "foo"; my Int $b = $a; $b == 0 but Scalar("foo"); such that you may reconstruct the Scalarness. But that seems like trouble waiting to happen -- propagating the value means that eventually someone calls C<print $b3> and gets "foo" instead of "0". Unless operator semantics strip extended-value-attributes, so that $b == 0 but Scalar("foo") while C<$c = $b + 1> == 1 but Scalar("1"); Frankly, I prefer to regard Scalar->Int as a narrowing conversion and accept the lossage. > > > (I've been operating under the > > assumption that an "untyped scalar" doesn't _remove_ the type of > > something, it just can store values of _any_ type, and is by > default > > much more generous about autoconverting them for you, so that you > could > > use $c as an Int, int, Num, num, Str, str, etc., without warning or > > > error... but internally, it's actually still storing the value as > an > > C<Int 0>, because that's what you assigned to it.) > > Seems reasonable. > > <pedantic> Although I would assume that it would store and pull the > value from an Int slot, then create a new value of the "converted to" > type, and use that. </pedantic> This goes back to Damian's point some months ago that function call arguments are pass-by-reference and the limitations that imposes on automatic conversion/coercion. In essence, because we say: sub foo(Int $arg) {...} foo($a); The parameter to foo has to be type compatible with Int, or the compiler will have to automatically instantiate a temp and convert in one or more directions. Currently, I believe the pendulum has swung towards "must be type compatible or you get an error." > A better example of what I was driving at would be this: > > my $a = 'foo' but purple; > my Int $b = $a; > > In other words: I've just created an untyped Scalar. This Scalar is > (presumably in it's Str slot) storing a string value which happens > to have a property set on it (i.e., C<foo but purple). Now I assign > this Str to an Int. String values get converted when assigned to > Ints. Are we converting and assigning THE IDENTICAL VALUE or are we > creating a new value (whose value, in a numeric context, is > considered equivalent) and assigning that? In the first case, I > would expect that the property would be preserved. In the latter > case, I would expect it NOT to be preserved. My preference is: $temp = "foo"; $temp.setProperty(purple); $a = $temp; $temp = Str_to_Int($a); # 0, no property. $b = $temp; Although it occurs to me that there might be such a thing as "Int properties" and "Str properties", and maybe the conversion propagates the appropriate ones. That is: my $a = "foo" but $purple ; $a but= false; $a but= prime; $a but= charset("UTF8"); $a but= encoding("text/utf8"); my Int $b = $a; At this point, $b would be C<0 but all(false, prime)>. =Austin