Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Type annotation on expressions

6 views
Skip to first unread message

Yuval Kogman

unread,
Aug 8, 2006, 5:31:36 AM8/8/06
to perl6-l...@perl.org
Is there any way to type annotate a single expression, without using
a temporary variable?

my Moose $x = $y; # definitely a Moose now, may have been coerced
foo( $x );# foo() doesn't necessarily say it wants Moose

Is it possible to say this one expression? Haskell's syntax is shiny
but everybody wants the colon:

foo( ( $x :: Moose ) );

If we do find something (please ignore the fact that :: is probably
not going to be the syntax), are these two the same?

my $x = ( $y :: Moose );

my Moose $x = $y;

--
Yuval Kogman <nothi...@woobling.org>
http://nothingmuch.woobling.org 0xEBD27418

Daniel Hulme

unread,
Aug 8, 2006, 6:12:11 AM8/8/06
to perl6-l...@perl.org
> Is it possible to say this one expression? Haskell's syntax is shiny
> but everybody wants the colon:
>
> foo( ( $x :: Moose ) );
I may be in a little world of my own here, but isn't this what 'as' is
supposed to do?

foo($x as Moose);

--
"Of all things, good sense is the most fairly distributed: everyone
thinks he is so well supplied with it that even those who are the
hardest to satisfy in every other respect never desire more of it than
they already have." -- Descartes, 1637 http://surreal.istic.org/

signature.asc

Yuval Kogman

unread,
Aug 8, 2006, 7:10:30 AM8/8/06
to perl6-l...@perl.org
On Tue, Aug 08, 2006 at 11:12:11 +0100, Daniel Hulme wrote:

> I may be in a little world of my own here, but isn't this what 'as' is
> supposed to do?
>
> foo($x as Moose);

as is a method invocation not a type annotation... It's related, but
not the same (last I heard)

Luke Palmer

unread,
Aug 8, 2006, 7:22:35 AM8/8/06
to perl6-l...@perl.org
On 8/8/06, Yuval Kogman <nothi...@woobling.org> wrote:
> On Tue, Aug 08, 2006 at 11:12:11 +0100, Daniel Hulme wrote:
>
> > I may be in a little world of my own here, but isn't this what 'as' is
> > supposed to do?
> >
> > foo($x as Moose);
>
> as is a method invocation not a type annotation... It's related, but
> not the same (last I heard)

Yep, in a perl5esque execution model, they should be the same thing,
but in a type-inferred environment they're two different things.
Assume such an environment:

my $x = Foo.new; # $x is a Foo
foo($x as Bar); # passed a Bar
foo($x); # passed a Foo

vs.

my $x = Foo.new; # coersed to Bar
foo($x :: Bar); # passed a Bar
foo($x); # passed a Bar

Which, needless to say, scares me a little. It is difficult to get
coersion and type inference to mix.

Luke

Yuval Kogman

unread,
Aug 8, 2006, 7:35:40 AM8/8/06
to Luke Palmer, perl6-l...@perl.org
Actually this particular example is just like coercion, and it's a
bad one.... sorry.

It's much more relevant for:

fun( $x.foo :: Bar );

in order to annotate the return type for a call's context even if
the 'fun' function's signature accepts Any.

Luke Palmer

unread,
Aug 8, 2006, 7:42:15 AM8/8/06
to Luke Palmer, perl6-l...@perl.org
On 8/8/06, Yuval Kogman <nothi...@woobling.org> wrote:
> It's much more relevant for:
>
> fun( $x.foo :: Bar );
>
> in order to annotate the return type for a call's context even if
> the 'fun' function's signature accepts Any.

Touche, this is independent of type inference.

I'm not up-to-date on coersion; last I checked it was hand-wavily
defined. If its present definition is not already contradicting this,
shouldn't it impose context to its left side? The situation where you
want the function to ignore context and coerce the result looks
esoteric on the surface, so making "as" impose context seems like a
good move.

The esoteric behavior can be regained in an esoteric way:

fun(($x.foo as Any) as Bar)

Luke

Yuval Kogman

unread,
Aug 8, 2006, 9:42:36 AM8/8/06
to Luke Palmer, perl6-l...@perl.org
On Tue, Aug 08, 2006 at 11:42:15 +0000, Luke Palmer wrote:

> I'm not up-to-date on coersion; last I checked it was hand-wavily
> defined.

Currently it's a unary multimethod:

my $hamburger = $cow.as(Food);

However, the MMD rules are counterintuitive for dispatch rules.

The reason annotation came up is because I felt it shouldn't be a
parameter at all, but a nullary multimethod on the return value:

my $hamburger = $cow.as :: Food;

Larry had mentioned that &return.signature is basically the
invocation context.

If we do have a n ullary `as` the annotations are essentially
parameters on the anonymous function that is the CPS continuation.
That continuation's signature is used to perform MMD dispatch on
'as' by matching the --> stuff in opposite priority order.

The current problem is:

12:15 < audreyt> Point is Shape; 3DPoint is Point
12:15 < audreyt> er I mean Poind3d
12:15 < audreyt> Point3d
12:15 < audreyt> you have an object $o
12:15 < audreyt> you want to get back Point
12:15 < audreyt> say $o.as(Point).x
12:16 < audreyt> $o is actually of class Moose
12:16 < audreyt> Moose has
12:16 < audreyt> multi method as (Shape)
12:16 < audreyt> multi method as (Point3d)
12:16 < audreyt> if we list "as" using the normal MMD rule
12:16 < audreyt> proto as ($) {}
12:16 < audreyt> then Point comes in and Shape is selected
12:17 < audreyt> but we want Point3d
12:17 < audreyt> not Shape, to win
12:17 < nothingmuch> isn't .as(Point) going to fail if it
returns a Shape?
12:17 < nothingmuch> i mean
12:17 < nothingmuch> the rules here are reversed
12:17 < nothingmuch> Point is not a parameter to .as in the
natural sense
12:17 < audreyt> it is going to fail only if we consider the
return type

http://colabti.de/irclogger/irclogger_log/perl6?date=2006-08-08,Tue&sel=359#l545
for more discussion.

0 new messages