HaloO,
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 operators
<: 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 | |
+------------------- :> -----------------------------+
contravariant
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() junction.
Regards, -- TSa (Thomas Sandlaß)
