develooper Front page | perl.perl6.internals | Postings from September 2002

RE: [netlabs #801] [PATCH] PerlArray in scalar context

Thread Previous | Thread Next
Brent Dax
September 5, 2002 00:25
RE: [netlabs #801] [PATCH] PerlArray in scalar context
Message ID:
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

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

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

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