Re: RFC 206 (v1) Array: @#arr for getting the dimensions of an array
Perl6 RFC Librarian wrote:
This RFC proposes using @#array, analogous to $#array, to get the list of
upper bounds for a multidimensional array @array. The length of @#array
would indicate the dimensionality of @array.
That's fine. This RFC does not seem to touch on the question what
$#array should be for a multidim array (e.g., $#array == $#{flatten @a}
or rather undef). Or is that dealt with in another RFC?
Christian
Re: RFC 82 (v3) Arrays: Apply operators element-wise in a list context
[EMAIL PROTECTED] wrote: I disagree. You end up with a situation where some @a * @b; are in scalar context, some not. No, everything would be in a scalar context. If you used tie() to specially tie a variable, then you might be able to overload +, *, -, etc, but this is no different from overloading other objects, which you can do currently. And what happens when you say @a = (1,2,2); @b = tie Matrix (1,2,3); @a*@b; Who wins? There are already well-established precedence rules on operator overloading; check out the Camel-3 chapter on it. The methods proposed in RFC 159 would follow these same rules, although this should probably be explicitly stated in the RFC. -Nate
Re: RFC 82 (v3) Arrays: Apply operators element-wise in a list context
Nathan Torkington wrote:
Actually, the only refinement I'd like to see is that boolean operators
(==, , ||) be excepted from the distributive rule.
This is to permit:
if (@a == @b) # shallow comparison
and
@a = @b || @c;# @a=@b or @a=@c; # ish
Yeah, I agree completely with this sentiment. This is far more useful to
me than having them element-wise.
My main fear is that while this RFC seems really good for math ops, but
seems too array- and PDL-specific. Here are some examples of mixed
contexts; how would these be handled under the RFC?
@user_data = @empty || $user;
%files = scalar(get_files()) || @DEFAULT;
$total = @items + $MIN_VALUE;
@full_names = @first_names . "Smith";
What I'd like to see is Perl to really DWIM (especially in that last
one). But to do so you have to redo the rules of the RFC:
Op Type Default homogenous context Mixed context
--- --
--
Math opselement-wise forced to scalar
Boolean ops whole entity forced to list
String ops element-wise forced to list
With these rules, the above examples now work as I'd expect (or at least
want) them to:
@user_data = @empty || $user; # @user_data =
($user);
%files = scalar(get_files()) || @DEFAULT; # %files =
(@DEFAULT);
$total = @items + $MIN_VALUE; # $total = 5 + 2;
@full_names = @first_names . "Smith"; # @full_names = ("Bob
Smith", "Jim Smith");
True, this opens a whole other can of worms, but I think it's closer to
what people would want to use the ops for, and it's also more usable to
us non-PDLers. Note there's a lot of inherent want()-like behavior built
in there.
-Nate
Re: RFC 82 (v3) Arrays: Apply operators element-wise in a list context
Nathan Torkington wrote: Jeremy Howard writes: No, there's no arbitrary decision. *Every* operator is component wise on lists. It is internally consistent, and consistent with most other languages that provide array/list operators. It's easy to get stuck on the '*' example, because different mathematicians have different feelings about what matrix operation should map to '*'. However, there is no consistant and meaningful definition of array operations (for _all_ operators) other than that defined in RFC 82. Actually, the only refinement I'd like to see is that boolean operators (==, , ||) be excepted from the distributive rule. This is to permit: if (@a == @b) # shallow comparison Already works under the RFC (scalar context). and @a = @b || @c; # @a=@b or @a=@c; # ish Doesn't work in P5 (try it!) The math operations are fine to apply to each element. I have no problem with those being distributive, but I think || for default values and == for comparison are too ingrained and they'd be too useful (as opposed to a distributive || or , which is much less useful). == is applied in a scalar context--fine. || as you show it can not be ingrained because it doesn't currently work this way!
Re: RFC 82 (v3) Arrays: Apply operators element-wise in a list context
"NT" == Nathan Torkington [EMAIL PROTECTED] writes: NT Actually, the only refinement I'd like to see is that boolean operators NT (==, , ||) be excepted from the distributive rule. NT This is to permit: NT if (@a == @b) # shallow comparison NT and NT @a = @b || @c;# @a=@b or @a=@c; # ish NT The math operations are fine to apply to each element. I have no NT problem with those being distributive, but I think || for default NT values and == for comparison are too ingrained and they'd be too NT useful (as opposed to a distributive || or , which is much less NT useful). Then how would one get the distributed effect? An apply operator? chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 82 (v3) Arrays: Apply operators element-wise in a list context
Nathan Wiger wrote: what people would want to use the ops for, and it's also more usable to us non-PDLers. I'd like to suggest that it is not a very good idea to start dividing the world into PDLers and non-PDLers. There are a multitude of reasons but I am not keen to go into details. Christian
Re: Pre-RFC: undef =~ s/def/initialize/
Randal L. Schwartz wrote: uninit looks like a typo for "unit". Maybe we need "denit" for "de-nitialize" :)... Yuck. I dislike "de-" anything. "un-" is far more often the correct prefix. Anyway, the counterpart of "init" should be, I think, "exit". But seriously, the opposite of "initio" is "ultimo", right? -- John Porter We're building the house of the future together.
Re: Beefier prototypes (was Re: Multiple for loop variables)
"PS" == Peter Scott [EMAIL PROTECTED] writes:
for ($x,$y,$z) (@a1,@a2,4..12,@a4) { ... }
Probably we'll have to say that the user must explicitly zip if that
is what is desired.
PS Yes, please. I view the flattening of lists as a feature, not a bug, and
PS it has made Perl a lot easier to understand IMHO.
I view it as a mis-feature. One is unable to return multiple arrays,
or to pass through multiple arrays without resorting to messy extra
punctuation characters.
It makes it 'necessary' to explode items onto the stack to operate properly.
(Yes, this can be optomized away, but retrofiting iterators and other
handling is probably a mess.)
The special case where the number of loop variables and the number of
supplied lists are equal should be either made explicit or optomized
if zip/merge/whatever is used.
Or
for ($x,$y,$z) ( (@x,@y,@z) )
an extra set of parenthesis could do the flattening. (only one list
is 'visible' as the argument to the for.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: Beefier prototypes (was Re: Multiple for loop variables)
"DC" == Damian Conway [EMAIL PROTECTED] writes:
my_while { pred() } { # don't gimme no Tcl flac.
...
} # no semicolon needed here!
DC Just added to the RFC :-)
How would the parser handle this? Some '}' would need ';' some don't.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 52 (v2) List context return from filesystem functions
Would returning the array of status be sufficient? @foo = chmod 755, "bar", "baz", "quux"; # @foo == (0, 2, 0); How to convert them to error messages would be a challenge. Unless passing them through $! would do the trick. Hmm, perl -wle '$!=3; print $!' No such process Yup, works. chaim "PS" == Peter Scott [EMAIL PROTECTED] writes: PS At 06:40 AM 8/30/00 -0600, Tom Christiansen wrote: My worry is that it seems like this would return an empty list on success, so: @foo = chmod 755, "bar", "baz", "quux" or die "Whoops, died on success!"; This seems to me to go contrary to the way perl tends to work... are there any other functions (beside system) that do this? Am I misunderstanding this? No, you've hit on the biggest flaw of the RFC. I am less enamored of it now than I once was. I'd still like to get those individual failure reasons but I am beginning to think it is not worth the cost. Anyone got a brainwave on how to have the cake and eat it too? I'm also concerned about all the separate errnos for each of those failures. PS where PerlLIO_chmod is defined as chmod on most righteous systems. So it PS would be a matter of squirreling away the errno for each bad result. PS I just can't get over the result in the successful case being an empty PS list, though. And conversely. Maybe this isn't itching enough to be worth PS scratching this hard, but it seemed like a good direction :-( Anyone got PS any brilliant ideas before I withdraw it? -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
