On Sat, Aug 20, 2005 at 12:27:23PM +0300, Yuval Kogman wrote:
: On Fri, Aug 19, 2005 at 21:29:11 -0700, Larry Wall wrote:
:
: > Basically, unaries don't have to worry about reconciling different shapes.
: > They just recurse as much as is "reasonable", whatever that is.
:
: Possible exact semantics of "reasonable":
:
: hyper recurses at least one level, and then tries to match the
: type of the hyper'ed function on each element. If the type does
: not match, more attempts are made at recursion.
Depends on what you mean by "match the type". By one definition, an
array matches the type of +, so it should just hyper on the length of the
array, which is not what people are going to want generally. I think you
have to try to recurse first.
: If at any point the shapes of the current node is different from
: it's corresponding node in the other structure, then a binary
: function is applied regardless of type (resulting in coercion or
: a fatal error).
That doesn't do dimension extension of scalars. We want this to work
1 >>+<< [1,2,3]
at any level in the hyper, but by the definition above it would add
1 to the length of [1,2,3]. Perhaps there's a Hyper role that says
whether a container can hyper, or defines a function that returns
some kind of hyper conformability type, so that scalars, arrays, and
hashes can be recognized, and maybe other types added. I guess what
we're saying is that hyper does a mapping from named type to a general
structural type and then does MMD on the structural types.
Or maybe we just treat Item, Array, and Hash roles as structural
types, and let people add other MMDs if they want hyperdispatch to
other structural types. Though this is getting dangerously close to
letting people change the parallel semantics of hyper for individual
named types, which is something I want to discourage, if not disallow
outright. So I'm inclined to make named types pick one of the Big
Three to behave as before hyper ever sees them.
Though there could be a pecking order. For instance, a match object
can do both the Array and Hash roles. For hyper, it first tries to be
an Array, then a Hash. If it's matched up against an Item or an Array,
it does Array. If it's matched up against another Hash, it does Hash.
For now, I think we can just hardwire the analysis in terms of "does":
given $obj {
when Array { participate_as_array() }
when Hash { participate_as_hash() }
default { participate_as_item() }
}
or maybe it's
given $obj {
when Ordered { participate_as_list() }
when Hash { participate_as_hash() }
default { participate_as_item() }
}
to admit un-indexable lists.
Larry
