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/
pgpwsP0LMxs4l.pgp
Description: PGP signature
