On Mon, Mar 07, 2005 at 10:29:58PM +0100, Aldo Calpini wrote:
: Larry Wall wrote:
: >Or, assuming you might want to generalize to N dimensions someday, just
: >
: > sub bar ([EMAIL PROTECTED]) {...}
: >
: >and deal with it as in Perl 5 as a variadic list. I suppose one could say
: >
: > sub bar ([EMAIL PROTECTED] is shape(3)) {...}
: >
: >and get checking on the argument count.
:
: if I understand correctly, without using multi subs:
:
: sub bar(@coords is shape(3)) { ... }
:
: bar(@xyz); # ok
: bar( [$x, $y, $z] ); # ok
: bar($x, $y, $z); # compile-time error
Yes.
: while:
:
: sub bar([EMAIL PROTECTED] is shape(3)) { ... }
:
: bar(@xyz); # ok
: bar( [$x, $y, $z] ); # ok
: bar($x, $y, $z); # ok
: bar <== $x, $y, $z; # still ok
:
: am I right?
The second one might fail, I think. The declaration says that @coords
as a whole has shape(3), not each individual element. On the other
hand, if you interpret the shape size as a maximum and not an exact match,
then you could end up with a value of [[$x,$y$z],undef,undef], though
of course, that would fail if you had declared it to be an array of int.
In fact, we really haven't specified what happens when you say
my Int @a is shape(3) := [1,2];
my Int @b is shape(3) := [1,2,3,4];
A strict interpretation requires both to be errors, but I can warp my
brain around to thinking either or both is okay. The first is kinda
okay because @a[2] can represent undef, and the array as a whole
successfully holds the whole value. The second is kinda okay
because the @b presents a view into a portion of the bound value,
and there aren't any parts of it that map onto nothingness.
But I also have this nagging feeling that the user wouldn't have
specified shape(3) unless they actually meant it. The question is
what they meant. It could be argued that shape(3) is just a storage
directive saying that we'll emulate the more general array semantics
with 3 elements. But I suspect that in the typical case, they really
do want a 3-element vector, nothing more, nothing less.
Our notation doesn't differentiate those intents, however. Let's
assume the strict intent, and if a different strategy is intended with
looser binding semantics, we can always use a different trait name.
I think a strict interpretation of shape gives a lot more information
to the optimizer.
Larry
