On Wed, 4 Sep 2002, Brent Dax wrote: > Sean O'Rourke: > # On Wed, 4 Sep 2002, Brent Dax wrote: > # > What if (say) @b is a two-dimensional array? > # > # Then you get "interesting values of undef" :). Seriously, I > # suspect one of the following: > # > # 1 - runtime error > # 2 - each row (or column) of @b numified to its length > # 3 - the first element of each row/col of @b > # 4 - the other arrays boosted to the highest dimension > # > # I like #2, because it is easy and keeps hyper-operation > # simple. If those aren't just numeric operators, but some > > It's already been defined to be #4.
Argh. Then I need to whinge a bit -- what if it's a ragged array? What if different elements have different dimensions themselves, e.g. "[1,[2,3]]"? I think there's serious can-of-worms potential here, and by making hyping more "intelligent", we'll actually make it useful in fewer cases. > My point was that we can't just render it into bytecode that directly, > unless all the arrays are typed (in which case we know the > dimensionality). I've been mostly thinking of the static parts of Perl 6, so add that to the grain of salt you apply to my posts. Along similar lines, I didn't intend that to be a "this is exactly how hyper-operators are implemented" post, but just a "this is one reason why we don't want a `hype' opcode" one. If we have to play dynamic shenanigans with hyperoperators, we can still figure out the appropriate dimensions in bytecode, then do the appropriate looping recursively on each dimension. But for the simple, static case, we should use the simple version. > I'd imagine that we'll have to have an opcode like: > > hyper P0, P1, P2, LABEL I'm not seeing why this should be an opcode. The point of my innocent example was that hyping isn't an ordinary 3-operand kind of thing. Hyperoperators can change the way an entire expression is compiled (for the C++ buffs out there, check out POOMA and/or the matrix template library). The code below will give the correct result, but we can do better by avoiding the temporaries when dimensions are known at compile time (or maybe even at run-time, though I haven't thought it through). > (though a real compiler would fold those into one.) That would be pretty hard (I think), since it involves coalescing two subs into one, then cleaning out a bunch of temporaries. (still reading over code) /s
