Re: Quick question: '1.28' * '2.56'

[Luke Palmer]

On 5/17/05, Rob Kinyon <rob.k...@gmail.com> wrote:
> > Maybe s/Num/NumLike/ or something? Anyway, that's how I think of it
> > at least: not that a Str is converted into a Num, but rather that
> > certain Strs are Nums.
>
> If that's the case, then if I change a variable that isa Str (that isa
> Num), does it change what it inherits from?

Er, Str is not a Num. Num is a subtype of Str, so Num is a Str. If
you change a Str, it could cease to be a Num.

$x = "123"; # $x does Str & Num & Int
$x .= ".45"; # $x does Str & Num
$x .= "xyz"; # $x does Str

But again, don't take this as gospel. This is just a tidbit from the
object model which I will probably not end up proposing. I find it
quite elegant when used with pure (as in, non-manhattan) MMD. It
doesn't really make sense with manhattan-style, since we can't
determine what a "level of inheritance" is with subtypes.

Luke

[Luke Palmer]

On 5/17/05, Autrijus Tang <autr...@autrijus.org> wrote:
> Imagine:
>
> pugs> '1.28' * '2.56'
> 3.2768
>
> What is (or should be) going on here here?
> ...
> [6] something else?

I still don't quite have a handle on the object system. Maybe:

subtype Num of Str where /^ <number> $/;

?

Maybe s/Num/NumLike/ or something? Anyway, that's how I think of it
at least: not that a Str is converted into a Num, but rather that
certain Strs are Nums.

Luke

[Rob Kinyon]

> Maybe s/Num/NumLike/ or something? Anyway, that's how I think of it
> at least: not that a Str is converted into a Num, but rather that
> certain Strs are Nums.

If that's the case, then if I change a variable that isa Str (that isa

Num), does it change what it inherits from?

Rob

[Autrijus Tang]

Imagine:

pugs> '1.28' * '2.56'
3.2768

What is (or should be) going on here here?

[1] role NumRole {
method infix:<*> returns Num (NumRole $x, NumRole $y: ) { ... }
}
Str.does(NumRole);

[2] multi sub infix:<*> (Str $x, Str $y) returns Num { ... }

[3] multi sub prefix:<+> (Str $x) returns Num { ... }
multi sub infix:<*> (Num $x, Num $y) returns Num { ... }
multi sub infix:<*> (Any $x, Any $y) returns Num { +$x * +$y }

[4] multi sub infix:<*> (Num $x, Num $y) returns Num { +$x * +$y }
# ...and the MMD dispatcher forces incompatible type into
# the type with shared ancestors and closest distance...

[5] none of the above -- that should be a type error. ;)

[6] something else?

Thanks
/Autrijus/

[Larry Wall]

On Tue, May 17, 2005 at 09:04:19PM +0800, Autrijus Tang wrote:
: Imagine:

I tend to think of it most like [3], but it's possible that it's the
same as [1] if the role is supplying the coercion assumed in [3].

Larry

[Sam Vilain]

Rob Kinyon wrote:
> If that's the case, then if I change a variable that isa Str (that isa
> Num), does it change what it inherits from?

Please don't use "inherits" when talking about these core types. Classical
inheritance just doesn't work with the varied sets of numbers. All those
stories you were told about Classical Inheritance being able to describe any
problem were naďve lies. Roles-based inheritance (or Traits-based if you
like Smalltalk, or Haskell's Classes) is a superset of classical inheritance.

In fact it seems reasonable to me at this point in time that a Perl 6 Class
is a subtype of a Role. The distinctions seem minor enough not to matter.

See also http://svn.openfoundry.org/pugs/docs/src/number-types.png

Sam.

[Sam Vilain]

Larry Wall wrote:
> : pugs> '1.28' * '2.56'
> : 3.2768
> : What is (or should be) going on here here?
> : [1] role NumRole {
> : method infix:<*> returns Num (NumRole $x, NumRole $y: ) { ... }
> : }
> : Str.does(NumRole);

> : [3] multi sub prefix:<+> (Str $x) returns Num { ... }
> : multi sub infix:<*> (Num $x, Num $y) returns Num { ... }
> : multi sub infix:<*> (Any $x, Any $y) returns Num { +$x * +$y }

> I tend to think of it most like [3], but it's possible that it's the
> same as [1] if the role is supplying the coercion assumed in [3].

I like #3, because it doesn't have any nasty implications to the type
calculus.

I don't really have the theoretical or practical knowledge to really be
able to back this up, but I have a strong hunch that value-based type
shifting is the type system equivalent of $&.

Sam.