On Fri, Feb 25, 2005 at 12:45:45AM +0800, Autrijus Tang wrote: : On Wed, Feb 23, 2005 at 12:17:19PM -0800, Larry Wall wrote: : > : And how does all this combine with the notion of context? : > : > Lazily, for the most part. In some cases we can determine context at : > compile time, but often not. Certainly a subroutine cannot determine : > what context it was called in until it's actually called, unless we : > venture into return-value MMD, which has problems resolving against : > parameter MMD. : : Ugh. Pugs currently does return-value based MMD, and it has indeed : the core reason behind my recently-reported dilemma on MMD tiebreaking. : If we lose retval-MMD, many sensible cases can then be resolved without : the need of "is default".
Though not all. : However, retval-based MMD is neccessary to ensure compile-time : dispatch, and plays really well with type inferencing in general. : So another solution is to mark ambiguate retval-based dispatches as : ill-typed, and let the programmer resolve it by explicit type : annotation. But making it default is probably too much B&D. Depends on where it has to be marked. Anyone can choose their B&D level within their own lexical scope, as long as they don't impose it on other lexical scopes. : 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... 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. 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... Larry
