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

Re: Optional binding

Thread Previous | Thread Next
Larry Wall
March 7, 2005 16:58
Re: Optional binding
Message ID:
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 (*@coords) {...}
: >
: >and deal with it as in Perl 5 as a variadic list.  I suppose one could say
: >
: >    sub bar (*@coords 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


: while:
:     sub bar(*@coords 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.


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