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

Reply via email to