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

Re: How are types related to classes and roles?

Thread Previous | Thread Next
Thomas Sandlaß
February 27, 2005 14:48
Re: How are types related to classes and roles?
Message ID:

Larry Wall wrote:
> On Fri, Feb 25, 2005 at 12:45:45AM +0800, Autrijus Tang wrote:
> : So, I think late binding is a sensible (and practical) default, but
> : do you think it may be a good thing to have a type inference mode that
> : assign static contexts to expressions, and prebind as much as possible?
> : It may be possible to enable via a pragma or a compiler switch...

Well, that is the optimizer everybody keeps talking about. And the more
type input it has, the better it can pre-select multi methods. A very
interesting feature for later versions of Perl 6 could even allow to perform
complete program optimization where code passages in modules that can't be
pre-selected on local information alone could be optimized when all type
information is available.

> It's certainly something to explore.  If I recall, I took some kind of
> compromise position in the Apocalypse where I said we probably wouldn't
> treat return-type-MMD with the same authority as parameter MMD, but
> we might be able to use return type as a tie-breaker on otherwise
> equivalent routines.

I guess "equivalent routines" shall mean "same specificity of invocant type"?
At that point to choose the multi with the lower return type seems tricky
and might lead to surprises. Note the following little diagram where the two

   <:  subtype
   :>  supertype

---which BTW would make nice standard operators :) ---
are used to show the function subtyping and method selection in one picture:

  method selection           covariant
                 +-------------------------- <: ----------------------+
                 |                                                    |
multi sub f2 ( Inv2 : Arg2 ) returns Ret2   <:  multi sub Ret1 f1 ( Inv1 : Arg1 )
                        |              |                    |                |
  subtyping of          |    covariant +---- <: ------------+                |
  Code objects          |                                                    |
                        +------------------- :> -----------------------------+

For method selection the short names have to be the same of course. The Arg
types are handled as type errors at runtime or compile time, right?
No tertiary tie breaking? :)

> Basically, instead of writing a single routine
> with a big switch statement in it, you'd be able to write multiple
> routines with the same parameters but different return types as a
> form of syntactic sugar over the switch statement.  It's not clear if
> such an approach would buy us anything in terms of type inferencing,
> except insofar as sub declarations are easier to mine the return types
> out of than an embedded switch statement.  Maybe that buys us a lot,
> though, just as having class metadata available at compile time is
> a big improvement over Perl 5's @ISA.
> Anyway, I don't profess to have thought deeply about type inferencing.
> But I do know that I don't want to turn Perl 6 into ML just yet...

Hasn't type inferencing become easy with the full power of junctions?
I imagine the compiler annotating the AST with types from the leaves up.
At multi calls which can't be pre-selected at compile time a one() junction
of all possibly matching multi's return types is assigned.

BTW, How many types does  Int|Str|Num produce?
All these: Int|Str|Num, Int|Str, Int|Num, Str|Num, Int, Str, Num?
Or just the last three? What is then the role of Int^Str^Num?

Is the syntax

type Criterion ::= KeyExtractor
                  | Comparator
                  | Pair(KeyExtractor, Comparator)

used in the sort ruling still current? There the RHS looks more like
a grammar rule alternation which is checked in turn than a real any()

TSa (Thomas Sandlaß)

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