On Thu, Jul 28, 2005 at 09:27:00AM -0700, Larry Wall wrote: > Or maybe Any really does mean "Object" and we're just viewing our > hierarchy too strictly if we make every relationship "isa". That's one > thing that neither this formulation nor Thomas's are making very > clear--which type relations are really subclassing, which are role > composition, and which are subtype constraints.
FWIW, I've been reading up on Scala's formulation of trait/class/delegation hierarchy, and I feel a bit like flipping through a puzzle book to look at the hints, if not answers. :-) http://scala.epfl.ch/docu/files/api/index.html > And I'm still not entirely sure I believe the "not-yet-bound-ness" of > Pairs is all that different from the not-yet-bound-ness of Junctions > to the extent that a different type level is warranted. Junctive autothreading are "outside" bindings -- they can be viewed as a two-phase exception handling from parameter type mismatches that fires away more function applications. Pairs on the other hand are bound normally; they just have a preferred zone unless overriden by the parameter signature; this resolution is strictly within the same one-step binding. I think there may be more types to come that has its preferred binding semantic, than outside-the-box devices like Junctions. > I guess I still think there ought to be a way of marking Pairs on the > call end as to whether they're intended for named args or not, without > warping the whole top-level type system to that end. I can see marking things explicitly for named bindings: foo(:literal<pair>); foo(*%nameds); foo(*$pair); foo([EMAIL PROTECTED]); That will mean that foo($pair) will always be positional. Thanks, /Autrijus/
Description: PGP signature