--- 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
