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

Re: Elimination of Item|Pair and Any|Junction

Thread Previous | Thread Next
Larry Wall
July 28, 2005 09:27
Re: Elimination of Item|Pair and Any|Junction
Message ID:
On Thu, Jul 28, 2005 at 05:31:46AM +0800, Autrijus Tang wrote:
: On Thu, Jul 28, 2005 at 03:55:55AM +0800, Autrijus Tang wrote:
: > Hrm.  I thought the original motivation of forcing people to write
: > 
: >     Any|Junction
: > 
: > was precisely to discourage people from accidentally write
: > 
: >     sub foo (Any $x)
: > 
: > and have $x accept a Junction.  In other words, any() should not be of
: > type Any.  Hence it still feels natural for me that Any occurs at the
: > position of Mumble.
: FWIW, if Any is to be ruled to be the top type and includes Junction,
: then I support Darren's proposal of "Single", and maybe the Object type
: can be simply eliminated to Any:

There is something to be said for avoiding "Object" as a word with
too much existing baggage from other cultures.

:     Any - Item - Single
:                - Pair
:         - Junction
:         - int, num, str
: This also means that <int num str> will fit to Any via autoboxing.

Which makes "Any" mean "anything that can act like an Object" rather
than the stricter "anything that 'isa' Object".  Hmm...

Item could take over the 'isa' role of Object, I suppose.  That does
imply that Junctions (and any other syntactic lazinesses we throw into
that slot) aren't really objects.  Maybe we can deal with that.

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.  Certainly some of
Thomas's recombining relations should be viewed as role composition
rather than MI.  And you can view the whole autoboxing issue as an
implementation detail of constrained subtypes, where the constraint
happens to be a restriction on the set of values that can fit into
a particular representation.

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.  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.


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