On Sat, Jan 28, 2006 at 06:30:06PM +0100, dakkar wrote:
: 4) It's written:
: 
:        (Conjectural: Within the body you may also use exists on the
: parameter name to determine whether it was passed. Maybe this will have
: to be restricted to the ? form, unless we're willing to admit that a
: parameter could be simultaneously defined and non-existant.)
: 
:    Ok, this is 'conjectural', but... if i don't pass a parameter in an
: invocation, and that parameter had a defined default, that it would be
: both defined and non-passed... here I'm sure I'm missing something

That's precisely the point.  It's just a bit strange to have something
that is defined but doesn't "exist".

: 5) while talking about pipes, it says that
: 
:      (0..2; 'a'..'c') ==> my @;tmp;
:      for @;tmp.zip { say }
: 
:    produces
: 
:       [0,'a']
:       [1,'b']
: 
:    etc. Right. But then it says:
: 
:      for @;tmp.each -> $i, $a { say "$i: $a" }
: 
:    as far as I understand, this should say
: 
:      0: undef
:      'a': undef
: 
:    etc., since 'each' is visiting the multidimensional array 'by rows',
: and producing 1 value at a time, which when bound to the 2-ary signature
: would leave the $a parameter without a value, and so undef (I'm assuming
: that pointy sub positional parameters are implicitly optional, otherwise
: that statement would be a run-time error). I'm pretty sure I don't know
: what 'each' does...

The "each" is just producing a sequence of values (without bundling
them up into tuple objects like "zip").  It's the "for" that is
deciding to take these list values 2 at a time because of the arity
of the block's signature.  That is why, if you use "zip", you have
to put the args as [$i, $a] in order to present an arity of 1 to "for".

: 6) It's written:
: 
:      Every lexical scope gets its own implicitly declared @; variable,
: which is the default receiver.
: 
:    To me, that is a variable with a null name ('@;' being a twigil).
: Should it not be @;_ ?

I suppose there's an argument for that.  We certainly haven't hesitated
(much) to define $! differently from $!foo, for instance.  And Perl 5
distinguishes $#foo from $# (that latter being deprecated, of course).
On the other hand there's no reason in principle that a twigil *has*
to mean something entirely different just because it has a null name.
Plus I think people would rebel if all "underlying" objects had to have
an underline.  We'd end up with $/_ instead of $/, and $!_ instead of $!,
and would $!_ then be misinterpreted as a private attribute named "_"?

Larry

Reply via email to