Autrijus Tang <[EMAIL PROTECTED]> writes:
> On Fri, Jul 22, 2005 at 03:40:34PM -0700, Larry Wall wrote:
>> I dunno. I'm inclined to say that it should default to Item|Pair, and
>> let people say Any explicitly if they really want to suppress autothreading.
>> Otherwise conditionals and switches are going to behave oddly in the
>> presence of "accidental" junctions.
>
> Okay. However, in that view, I suspect many builtins will be defined on
> Item|Pair, for example &perl, &clone, &id, as well as various coercion
> builtins. Considering that builtins are Code objects but not Routines,
> maybe they, too, should default to Item|Pair -- except the ones that
> operates on junctions, of course.
>
> This leads me to think that maybe users don't really need to write down
> the two junctive types, under the hierarchy below:
>
> - Object
> - Any
> - Item
> - ...pretty much everything
> - Pair
> - Junction
> - num, int, str...
>
> Since junctions are still boxed objects, having the Object type to
> effectively mean Any|Junction seems natural ("everything is an object").
>
> Also, since Any unifies Item and Pair, the rule for implicit types of
> argument becomes:
>
> sub ($x) { } # Item $x
> -> $x { } # Any $x - i.e. Item|Pair but not Junction
> { $^x } # Any $x - i.e. Item|Pair but not Junction
Maybe there's a case for introducing Bundle types, akin to CPAN bundles. These
would be types only in the very losest sense, that could be used in function
prototypes to stand for particular bundles of types. So instead of Any being in
the class hierarchy where you propose it'd be a bundle that expanded to the
equivalent of doing:
any(Object.all_subclasses.grep -> $class { !$class.does(Junction) })
That way we get to arrange the class hierarchy in the way that makes the most
sense conceptually, but slice still slice it appropriately for Type
specifiers.
Just a thought.
