On Thu, Jul 28, 2005 at 03:52:41PM +0200, "TSa (Thomas Sandla�)" wrote: > >And this is a natural extension to guide the inferencer so it won't be > >totally giving up on polymorphic functions such as &id. C) and D) can > >be taken together, resulting to a powerful soft typed language. > > This is my preference. The only known issue with parametric typing is > the proliferation of params as soon as you want to stay away from > unpecificity.
On #perl6, chip reported that during the design team meeting, the two
forms below are introduced to carry full inferential soft typing
information:
sub negate (Num $x --> Num) { ... }
our Num sub negate (Num $x) { ... }
> >However, if we take the view that type annotation are merely storage
> >allocation hints and runtime coercers, then A) is probably the way to go.
>
> Please no. Or at least not exclusively. I see your "storage allocation
> hints" as a data environment needed to implement the type.
The old "returns" form would become a type annotation for the &return
inside it, but does not propagate outwards. From the outside, that
function can return anything it likes.
sub negate (Num $x) returns Num { ... }
I think --> could be right-associative, so we can write things like:
# Function application combinator
sub infix:<$> ( &f:(::A --> ::B) --> A $x --> B ) {
return { f($^x) }
}
However, as these are only transcripts from IRC, I can't vouch for
their accuracy before @Larry confirms it.
Thanks,
/Autrijus/
pgpcOxWgPwlV6.pgp
Description: PGP signature
