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/

Attachment: pgptom0e50y6k.pgp
Description: PGP signature

Reply via email to