Re: RFC 206 (v1) Array: @#arr for getting the dimensions of an array

2000-09-09 Thread c . soeller
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

Re: RFC 82 (v3) Arrays: Apply operators element-wise in a list context

2000-09-09 Thread Nathan Wiger
[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

Re: RFC 82 (v3) Arrays: Apply operators element-wise in a list context

2000-09-09 Thread Nathan Wiger
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

Re: RFC 82 (v3) Arrays: Apply operators element-wise in a list context

2000-09-09 Thread Jeremy Howard
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

Re: RFC 82 (v3) Arrays: Apply operators element-wise in a list context

2000-09-09 Thread Chaim Frenkel
"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;#

Re: RFC 82 (v3) Arrays: Apply operators element-wise in a list context

2000-09-09 Thread c . soeller
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.

Re: Pre-RFC: undef =~ s/def/initialize/

2000-09-09 Thread John Porter
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

Re: Beefier prototypes (was Re: Multiple for loop variables)

2000-09-09 Thread Chaim Frenkel
"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

Re: Beefier prototypes (was Re: Multiple for loop variables)

2000-09-09 Thread Chaim Frenkel
"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 Frenkel

Re: RFC 52 (v2) List context return from filesystem functions

2000-09-09 Thread Chaim Frenkel
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,