Hi,

I'm looking for answers/clarificati­on on what (if taken as individual

programs) $x is in each case.

my Int $x; # $x is Int protoobject

say $x; # Int

say $x.WHAT; # Int

class Foo { }

my Foo $x; # $x is Foo protoobject

say $x; # Foo

say $x.WHAT; # Foo

# This means we can only assign to $x something that isa Foo?

role Bar { }

my Bar $x; # $x is ???

say $x; # ???

say $x.WHAT; # ???

# This means we can only assign to $x something that does Bar?

subset EvenInt of Int where { $_ % 2 == 0 };

my EvenInt $x; # $x is ???

say $x; # ???

say $x.WHAT; # Failure?

# This means we can only assign to $x something that matches the constraint

class Dog { }

class Cat { }

my Dog|Cat $x; # $x is ???

say $x; # ???

say $x.WHAT; # Failure?

# This means we can only assign to $x something that isa Dog or isa Cat

Signature? If so, what kind of object does the Signature object

return if I ask it to give me its invocant? Surely not another

Signature object? Whatever it is that Perl 6 returns in that case

My thoughts:

.HOW returns information concerning the implementation type; .WHAT

returns information concerning the value type.

.HOW and .WHAT stringify to something resembling the declarations that

would be used to create them.

.WHAT is a Foo; stringifies to "Foo".

This one's tricky: roles cannot be instantiated, so .WHAT cannot be a

Bar.

My gut reaction is that it's an anonymous class that does Bar

and stringifies to "Bar". As long as you don't have both a role and a

class named "Bar", this should not be a problem, since the value type

isn't concerned with the implementation. If it is possible to have

both a role and a class with the same name, you might be able to look

at .WHAT.HOW (or .^WHAT) to figure out with which you're dealing.

That is, the implementation type of the value type ought to provide

more elaborate detail as to the nature of the value type.

my guess: .WHAT is an EvenInt that stringifies to "EvenInt". If you

want to know about the structure of EvenInt (e.g., which class is it

based on, and which subset restrictions have been applied to it), you

would refer to .WHAT.HOW.

my guess: .WHAT is a Junction that stringifies to "Dog|Cat". To

access the details as to which classes are in the junction and how

they are joined, refer to appropriate methods (I believe that Junction

includes a method that returns a Set of its members) or maybe to

.WHAT.HOW.

As well:

class Dog { }

role Pet { }

my Pet Dog $x;

say $x;

say $x.WHAT;

My guess is that .WHAT would be a (dis)Junction of a Dog and an

anonymous class; the anonymous class does Pet and stringifies to

"Pet", while the Junction stringifies to "Pet Dog".

Jon Lang wrote:

My addition to these thoughts is that the WHAT and HOW are

cascaded. Let's say we start at level 0 with the objects,

thingies or however we want to name the atoms of our discourse.

At the zero level HOW, WHAT etc. are vacuously identical with

the object. They fall apart on level 1 from each other and among

them selfs but they are all sets of level-0 objects. In general

a level n concept contains level 0..^n "objects" and is the name

for a something they share.

What? I would say it is a level 1 WHAT. The next level concept

$x.WHAT.WHAT is role. BTW, there are not very many levels up.

I would argue that $x.WHAT.WHAT is subset. I think the

idea of introspection is to have $x.WHAT.of return Int

as a level 1 WHAT and $x.WHAT.where return the constraint

closure. That said I would expect $x.HOW to be the identical

level 1 HOW object that $x.WHAT.of.HOW returns. When Int.WHAT.WHAT

is a role then this is undef of Int.

On level 1 the WHATs of Dog and Cat are distinct. Dog|Cat is a level 2

WHAT. The level 2 $x.WHAT.HOW is a union. $x.WHAT.WHAT is class.

Hi,

I'm looking for answers/clarificati­on on what (if taken as individual

programs) $x is in each case.

my Int $x; # $x is Int protoobject

say $x; # Int

say $x.WHAT; # Int

class Foo { }

my Foo $x; # $x is Foo protoobject

say $x; # Foo

say $x.WHAT; # Foo

# This means we can only assign to $x something that isa Foo?

role Bar { }

my Bar $x; # $x is ???

say $x; # ???

say $x.WHAT; # ???

# This means we can only assign to $x something that does Bar?

subset EvenInt of Int where { $_ % 2 == 0 };

my EvenInt $x; # $x is ???

say $x; # ???

say $x.WHAT; # Failure?

# This means we can only assign to $x something that matches the constraint

class Dog { }

class Cat { }

my Dog|Cat $x; # $x is ???

say $x; # ???

say $x.WHAT; # Failure?

# This means we can only assign to $x something that isa Dog or isa Cat

Jonathan Worthington wrote:

Correct, and for the same reason. The container checks the role--it

has little to do with what's in $x currently, which *cannot* have

the type of Bar, since you can't instantiate that.

Yes, again, checked by the container, not by $x. $x cannot have the

type of a subset either! The actual type of $x is Int. Objects may

only be blessed as valid storage types of some kind or other. Subsets

are merely extra constraints on a storage type (here Int).

Well, maybe $x is just Object, or whatever is the closest type that

encompasses both Dog and Cat. But note that Object is just the most

generic kind of undef, so this is more or less equivalent to doing

no initialization in p5-think. I don't think I'm interested in making

the run-time system calculate a Dog|Cat storage type, so it comes out

to just a constraint.

Really, the main reason we initialize with an undef of the correct sort

is so that you can say

my Dog $x .= new();

But what would (Dog|Cat).new() do? Constructors are not required to

know about subset types or roles. Constructors just create plain ordinary

classes, I expect. Composition and constraint checking happen

elsewhere.

On Tue, May 06, 2008 at 07:01:29PM -0700, Jon Lang wrote:

: 1. Apparently, my presumption that $x.WHAT was for retrieving the

: value type was wrong; from the above, it's sounding like it is

: supposed to retrieve the implementation type.

I don't know what you mean by those terms.

.WHAT gives you an value

of undef that happens to be typed the same as the object in $x,

presuming your metaobject believes in types. .HOW gives you the

metaobject that manages everything else for this object. It might

or might not believe in classes or types.

: Is this correct? If

: so, for what purpose does $x.WHAT exist that you can't do just as well

: with $x itself?

You can do type reasoning with the WHAT type just as you can with

a real value of the same type. Int is a prototypical integer from

the standpoint of the type system, without actually having to *be*

any particular integer.

In contrast, the .HOW object for Int is very much *not* an Int.

Perl doesn't know or care what the type of the .HOW object is, as

long as it behaves like a metaclass in a duck-typed sort of way.

It's probably a mistake to try to use the type of the .HOW object in

any kind of type-inferential way.

: If it's for the stringification of the container's

: name, couldn't that be accomplished just as easily by means of a

: $x.HOW method, such as $x.^name?

No, that's not what it's for at all. It's only convenient that it

generally stringifies to something that looks like a package name,

assuming it's not an anonymous type. But the primary purpose is to

provide a closed system of types that is orthogonal to whether the

object is defined or not. In Haskell terms, they're all Maybe types,

only with a little more ability to carry error information about

*why* they're undefined, if they're undefined.

: 2. How _do_ you retrieve the value type of $x?

Do you mean the variable, or its contents? The contents returns its

object type via $x.WHAT, which for an Int is always Int, regardless

of any extra constraints imposed by the container.

: That is, how can the

: program look at $x and ask for the constraints that are placed on it?

Placed by the variable, or by the type of the contents? The

constraints on the value are solely the concern of whatever kind of

object it is. If you mean the constraints of the container, then

VAR($x).WHAT will be, say, Scalar of Int where 0..*, and VAR($x).of

probably can tell you that it wants something that conforms to Int.

I'm not sure if the "of" type should include any constraints, or just

return the base type. Probably a .where method would return extra

constraints, if any.

: I don't see $x.HOW being useful for this, since HOW is essentially

: there to let you look at the inner workings of the container; and none

: of the other introspection metamethods in S12 come close to addressing

: this question.

$x.HOW is not the inner workings of the container, but of the value.

You'd have to say VAR($x).HOW to get the inner workings of the

container. Scalar containers always delegate to their contents. In

contrast, @x.HOW would be equivalent to VAR(@x).HOW, because composite

objects used as scalars assume you're talking about the container.

.WHAT gives you an value

of undef that happens to be typed the same as the object in $x,

presuming your metaobject believes in types.

.HOW gives you the

metaobject that manages everything else for this object. It might

or might not believe in classes or types.

You can do type reasoning with the WHAT type just as you can with

a real value of the same type. Int is a prototypical integer from

the standpoint of the type system, without actually having to *be*

any particular integer.

In contrast, the .HOW object for Int is very much *not* an Int.

Perl doesn't know or care what the type of the .HOW object is, as

long as it behaves like a metaclass in a duck-typed sort of way.

It's probably a mistake to try to use the type of the .HOW object in

any kind of type-inferential way.

: That is, how can the

: program look at $x and ask for the constraints that are placed on it?

Placed by the variable, or by the type of the contents? The

constraints on the value are solely the concern of whatever kind of

object it is. If you mean the constraints of the container, then

VAR($x).WHAT will be, say, Scalar of Int where 0..*,

and VAR($x).of

probably can tell you that it wants something that conforms to Int.

I'm not sure if the "of" type should include any constraints, or just

return the base type. Probably a .where method would return extra

constraints, if any.

class C does A does B {...} # enters C into WHAT space

my $y = C.new; # $y.WHAT =:= C

my $b <: B; # automatically re-typing container

my $a <: A; # means e.g. my A $a is autotype

$b = $y; # now $y.WHAT =:= B

$a = $y; # now $y.WHAT =:= (A&B)

This last assignment has to enter the meet type (A&B) into the

type lattice because simply re-typing a B to an A is not possible

unless A <: B holds. This needs to be declared explicitly somewhere.

The declaration of class C doesn't do that, of course. So programs

not using <: don't incur the type calculation overhead.