Re: Variable Types Vs Value Types

[Dave Whipp]

John Williams wrote:

Do they?  One is obviously an array, and one is obviously a scalar.
You may get an error (cannot alias an array as a scalar) or $b get aliased
to the array-in-scalar-context (a reference).

This is one of those "how we think about the fundamentals" things. I am taking the viewpoint that "everything is in object". A number is an object; an array is an object, a hash is in object. The only thing that differs is that they implement different interfaces.

Perl6 provides syntaxes for those interfaces. $a and @a are both holders of objects. One of the issues I hoped to provike discussion of is the difference between

$b = @a;
and
$c := @a;

The former obviously creates a reference to the array; but does the latter? An ArrayRef is an object that provides indirection to an array object. But for $c, I have requested a binding, not an assignment. $c should hold, literally, the same object as @a. If an ArrayRef is a new object, then we shouldn't create this new object as part of a binding operation. But if @a is just an object -- with a vtable + data -- like any other object, then $c should be able to hold that object.

Conversly, an C<tie> operation should be nothing more than

$obj = new ArrayLikeThing;
@a := $obj; # the tie

$b = @a; # creates arrayRef: \$obj
$c := @a; # eq:ID $obj

The abstraction I'm getting at is that the @ and $ sigils simply provide different DWIMing behavior: there is no fundamental difference between the objects they can hold: an object is an object.

Let us
suppose that the type-definition syntax allows us to tell perl: "when
you use this variable in numeric context, call your object's C<sum>
method.". now, when we code

That would happen when you override the .num method, or whatever the
value-in-numeric-context method is called.

If only objects have types then yes, you'd override the .num method. But that sidesteps the issue: what if a *variable* has its own behaviour. The default scalar type might, indeed, call .num when it is used in numeric context: but this is just a mapping between a static context and a vtable entry. Lets avoid the question of the semantics of @ vs $: lets assume that I can say

my Foo $a = ...;
my Bar $b := $a;

Assuming that Foo and Bar are both compatible with the referenced object, do both $a and $b behave identically? Or can the variable's type influence the behavior of that variable (remember that variable types are always lexically scoped, unlike their values).

This type of thing need not be limited to the implicit method calls introduced by perl to DWIM. It might be as simple as type Bar saying that "a call to .aaa will actually call .bbb". So $a.aaa will invoke a different method than $b.aaa -- even though both variables hold the same object.

This might seem like a silly thing to want to do; but it seems to me that there are often cases where we want different behaviors in different contexts. Sure, we can define multiple interfaces; but then we run into issues with namespace conflicts. I'm not sure how useful this stuff would be; nor how bad the potential for confusion is. But it feels like a good conceptual unification.


Dave.