Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices

2000-10-01 Thread Ilya Zakharevich
On Sun, Oct 01, 2000 at 08:51:04AM +1100, Jeremy Howard wrote: A prototypeless-function call. get rid of them all!! Please no! Anything that makes it harder to write 'quick-and-dirty' scripts is never going to fly--this is part of what makes Perl special. Why? I see no problem in

Re: Perlstorm #0040

2000-09-27 Thread Ilya Zakharevich
== I lie: the other reason qr{} currently doesn't behave like that is that when we interpolate a compiled regexp into a context that requires it be recompiled, Interpolated qr() items shouldn't be recompiled anyway. They

Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices

2000-09-26 Thread Ilya Zakharevich
On Mon, Sep 25, 2000 at 06:30:22PM -0400, Karl Glazebrook wrote: Well, this shows that you entirely miss the problem of cryptocontexts. Context is determined by the "environment" of the operation, not by the operation. Context is propagated: the-left-hand-side-of-assignment ---

Re: RFC 244 (v1) Method calls should not suffer from the action on a distance

2000-09-26 Thread Ilya Zakharevich
On Mon, Sep 25, 2000 at 09:10:49PM -0700, Nathan Wiger wrote: if ( want-{count} 2 ) { return $one, $two } Will that be interpreted as: 'want'-{count} want()-{count} To be consistent, it should mean the first one. That is, the infix operator - should always autoquote the

Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices

2000-09-22 Thread Ilya Zakharevich
On Fri, Sep 22, 2000 at 11:17:40AM -0400, Karl Glazebrook wrote: [Cryptocontext is:] f(3*@a) would typically be a list context - and suddently instead of 3*(1+$#a) you get Cmap 3*$_, @a. This is true, what I would propose is we declare 3*(1+$#a) outmoded and always have it mean

Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices

2000-09-22 Thread Ilya Zakharevich
On Fri, Sep 22, 2000 at 05:24:55PM -0400, Karl Glazebrook wrote: It's now boiling down to a matter of opinion and we'll have to agree to differ. Of course I use array arithmetic all the time as a heavy PDL user. ...Do you say you are confused by using vectors (=scalars) instead of arrays?

Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices

2000-09-22 Thread Ilya Zakharevich
On Sat, Sep 23, 2000 at 09:52:51AM +1100, Jeremy Howard wrote: $x = 3 * @_; suddently being equivalent to $x = @_; does not look very promising... Why are these equivalent? RFC 82 only applies in list context. Am I missing something? Yes, the proposal to make

Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices

2000-09-22 Thread Ilya Zakharevich
On Sat, Sep 23, 2000 at 10:01:11AM +1100, Jeremy Howard wrote: It's now boiling down to a matter of opinion and we'll have to agree to differ. Of course I use array arithmetic all the time as a heavy PDL user. It's not just for number-crunchers either. Array notation greatly simplifies

Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices

2000-09-22 Thread Ilya Zakharevich
On Sat, Sep 23, 2000 at 10:41:07AM +1100, Jeremy Howard wrote: a) You can *already* use vectors as scalars in Perl; That's not what RFC 82 is proposing. Who cares? This already works... b) What we are discussing is Perl, not Mathematica, J, PDL, and so forth. These languages have

Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices

2000-09-21 Thread Ilya Zakharevich
On Thu, Sep 21, 2000 at 03:26:39PM -0400, Karl Glazebrook wrote: [Aside: Why not make ternary-range operator into 10 :: 20 :: 2 ?] That would work. My point is that having a stride is a fundamental feature in other array languages (IDL, Matlab, PDL) and would be useful in the perl core.

Re: RFC 243 (v1) No special UPPERCASE_NAME subroutines

2000-09-20 Thread Ilya Zakharevich
On Tue, Sep 19, 2000 at 08:05:50PM -0700, Nathan Wiger wrote: $_ is not ALLCAPS. @EXPORT_OK should die (see RFC 233). @ISA is on its way to its grave already, see Cuse base. Yeah, but you're still just sidestepping my point. Your position seems poised on the hope that no more special

Re: RFC 243 (v1) No special UPPERCASE_NAME subroutines

2000-09-19 Thread Ilya Zakharevich
== No special UPPERCASE_NAME subroutines Whoa! What about ALLCAPS variables? Should we axe all of them as well? They're the exact same idea. == What ALLCAPS

Re: RFC 244 (v1) Method calls should not suffer from the action on a distance

2000-09-19 Thread Ilya Zakharevich
== Please show me how to write: print STDERR @stuff; without it, while keeping it a method of the STDERR filehandle, and without requiring -. == Why not use -?

Re: RFC 243 (v1) No special UPPERCASE_NAME subroutines

2000-09-19 Thread Ilya Zakharevich
On Tue, Sep 19, 2000 at 04:22:31PM -0700, Nathan Wiger wrote: What ALLCAPS variables? Well, @ARGV comes to mind. I see, and @INC, %INC, %ENV, %SIG. Maybe we should provide a special namespace for these as well, besides main::? This is a nice possible solution. There may be many others

Re: RFC 244 (v1) Method calls should not suffer from the action on a distance

2000-09-19 Thread Ilya Zakharevich
On Tue, Sep 19, 2000 at 04:26:47PM -0700, Nathan Wiger wrote: $IO::STDERR-print @stuff; print $IO::STDERR @stuff; Ok, something here is extreme confused. Is not the second form an instance of indirect object syntax? It is not with a bareword at the second place, so is not causing the

Re: RFC 243 (v1) No special UPPERCASE_NAME subroutines

2000-09-19 Thread Ilya Zakharevich
On Tue, Sep 19, 2000 at 04:50:04PM -0700, Nathan Wiger wrote: Ilya Zakharevich wrote: On the other hand, there are only 5 names, not hundreds of them, and they do not "get in the way", as ADD would do (prohibiting a method named ADD). So letting them be may be also

Re: RFC 244 (v1) Method calls should not suffer from the action on a distance

2000-09-19 Thread Ilya Zakharevich
On Tue, Sep 19, 2000 at 04:52:12PM -0700, Nathan Wiger wrote: Ok, you should clarify this. You're not suggesting that indirect object syntax be removed. You're suggesting that it should not accept barewords. These are two separate things. Agreed. I realized the ambiguity only after I posted

Re: RFC 243 (v1) No special UPPERCASE_NAME subroutines

2000-09-19 Thread Ilya Zakharevich
On Tue, Sep 19, 2000 at 06:39:49PM -0700, Nathan Wiger wrote: The presence of a method STORE is visible outside of the module, and may be required* if the module follows some published (non-Perl) API. Variables are of different ilk. I think you're overlooking they can both be equally

Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices

2000-09-16 Thread Ilya Zakharevich
On Sat, Sep 16, 2000 at 11:08:18AM +1100, Jeremy Howard wrote: proposes a convenient syntax to slice multi-dimensional arrays; It is hard to evaluate this proposal without more context. In particular: - How does it relate to RFC 204? Is it an alternative, or an addition? 204 cannot be

Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices

2000-09-16 Thread Ilya Zakharevich
On Sat, Sep 16, 2000 at 07:15:34PM +1100, Jeremy Howard wrote: Why is it important for overloaded objects to be used as array indices? Overloaded objects should behave the same way as non-objects. Why does RFC 204 rule that out? RFC 204 simply specifies that a list reference as an index

Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices

2000-09-16 Thread Ilya Zakharevich
On Sun, Sep 17, 2000 at 11:07:09AM +1100, Jeremy Howard wrote: I repeat: what does $a[ $ind ] does if $ind is a (blessed) reference to array (1,1), but behaves as if it were 11 (due to overloading)? How $ind is implemented (ie the actual structure that is blessed) does not

Re: RFC 232 (v1) Replace AUTOLOAD by a more flexible mechanism

2000-09-16 Thread Ilya Zakharevich
On Fri, Sep 15, 2000 at 03:11:47PM -0600, Nathan Torkington wrote: Perl6 RFC Librarian writes: This RFC proposes two-stage autoloading: one stage may be registered to act when the symbol is encountered at compile time, the other when the subroutine is called. Autoloading on the second

Re: Proposal for \v and \V, the small- and large- cut regex opera tors.

2000-08-10 Thread Ilya Zakharevich
On Thu, Aug 10, 2000 at 11:12:28AM +0200, Johan Vromans wrote: Of course, we need group names (trivial), and group temporaries. I needed the latter to define a generic pattern to match quoted strings: you need to store the starting quote somewhere to find the ending quote, but I didn't want