On Monday, June 16, 2003, at 11:04 AM, David Storrs wrote:
On Mon, Jun 16, 2003 at 10:15:57AM -0700, Michael Lazzaro wrote:
(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>

Yeah, I would think so.



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.

I am almost positive that the assignment would perform a copy/clone of the original value, but would preserve the properties while doing so.


So if we try to assign C<'foo' but purple> to the Int $b, it:
- clones a new Scalar C<'foo' but purple>, but...
- identifies the copied C<'foo' but purple> as being a Scalar, not an Int, so...
- converts the copied C<Scalar 'foo' but purple> to an Int, resulting in C<Int 0 but purple>
- assigns C<Int 0 but purple> to $b.


... or something like that. But I would expect that the property _would_ be preserved... my gut feeling is that otherwise, they'd be _way_ to easy to accidentally lose, yes?


OT afterthought: In the past, whenever we've gotten embroiled in one
of these thorny, knotty issues, @Larry has pulled a stunningly
beautiful, elegant rabbit out of their hats.  And when I thought that,
I had this vision of a single quantum rabbit simultaneously coming out
of multiple hats with widely divergent spatial coordinates....

Yeah. What I wouldn't give for a quantum bunny, right about now. It's not even that type conversion is a particularly difficult issue, it's just so *very* all-encompassing that it's got to be done precisely, because it chains through everything else about the language... what happens when calling subroutines, what happens in the multimethod dispatcher, what simple lines of code do or don't give big honkin' errors, etc...


MikeL



Reply via email to