Sean O'Rourke:
# > # 4 - the other arrays boosted to the highest dimension
# > 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.
I don't see any cases where it becomes *less* useful by making it more
intelligent. Can you give an example?
As for the ragged array argument, I would argue for the following
statement in the documentation:
The behavior of hyperoperators with ragged and recursive
data structures is undefined (and likely to be downright
weird).
# > 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.
Absolutely. If we know the dimensions at compile-time, we should use
that information. But I have a sneaking suspicion that that won't be
the general case.
# > 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).
I think that when dimensions aren't known until runtime, we'll need a
'hyper' opcode. Keep in mind how much it could inflate the bytecode if
we render a ton of generic, N-dimensional hyper-operator logic into
bytecode.
I suspect that rendering this into C will:
a) keep the general logic in one reusable place
b) shrink the bytecode size
c) possibly speed up execution (optimizer gooooood...)
# > (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.
Perhaps. Looking for identical subs seems like an obvious size
optimization to me, but I'm not really a compiler guy. :^)
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
"In other words, it's the 'Blow up this Entire Planet and Possibly One
or Two Others We Noticed on our Way Out Here' operator."
--Damian Conway
