develooper Front page | perl.perl6.language | Postings from April 2005

Hyper operator corner case?

Thread Next
David Christensen
April 12, 2005 20:58
Hyper operator corner case?
Message ID:
Hey folks,

I wanted to delurk and address an issue that may need clarification in 
regards to hyper operators.

Quoting S03:

> If one argument is insufficiently dimensioned, Perl "upgrades" it:
>      (3,8,2,9,3,8) >>-<< 1;          # (2,7,1,8,2,7)

Now in this example case, it's pretty clear that the scalar 1 gets 
turned into a list of 1s with the length of the lhs.  What about the 
case of a larger-dimensioned or single-dimensioned array?

   (1,2,3,4,5) >>+<< (1,2)

Is this equivalent to:

a) (1,2,3,4,5) >>+<< (1,2,undef,undef,undef) (undef padding)
b) (1,2,3,4,5) >>+<< (1,2,1,2,1) (repetition)
c) (1,2,3,4,5) >>+<< (1,2,2,2,2) (stretching)
d) (1,2) >>+<< (1,2) (truncation)
e) something else, ie, warnings about mismatched dimension, die(), 
segfault, kill -9 1 (whatever your sadism level is).

Additionally, I was wondering if there was a difference between:

(3,8,2,9,3,8) >>-<< 1


(3,8,2,9,3,8) >>-<< (1)

I suppose the answer to that depends on the answer to the above 

If the answer is the a) case as above and undef resolves to 0 
numerically, then we run into another issue to consider.  In the case 
of addition and subtraction, 0 is the identity element, and so:

(1,2,3,4,5) >>+<< (1,2) yields (2,4,3,4,5).

But the intuitiveness goes away with multiplication, and completely 
blows up with division:

(1,2,3,4,5) >>*<< (1,2) yields (1,4,0,0,0), probably not what we wanted.
(1,2,3,4,5) >>/<< (1,2) yields (1,1,NaN,NaN,NaN), and probably die()s 
with division by zero errors.

If in the addition and subtraction cases we want to preserve the 
identity cases for the slots not accounted for, undef is fine because 
it resolves to 0; to provide the same features for multiplication and 
division, the identity element would have to be 1.  But that would 
suppose that the potential hyper-operators would know what their 
appropriate identity elements were (and that such a thing is meaningful 
to them).

Additionally, if there is a difference between the automatic scalar 
promotion and list promotion, we could run into errors where people 
would expect an expression to be a scalar which would be promoted in 
the documented fashion, but would really be promoted in one of a)-e), 
breaking what they expected:

(1..5) >>+<< ($a-$b) # list context for the expression?  Promotes like 
(1..5) >>+<< +($a-$b) # forced scalar context -- promotes like 
(1..5) >>+<< (1) # promotes like what?


David Christensen

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