develooper Front page | perl.perl6.language | Postings from August 2005

Re: The meaning of "returns"

Thread Previous | Thread Next
Autrijus Tang
August 6, 2005 17:10
Re: The meaning of "returns"
Message ID:
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

    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.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About