Ilya Zakharevich wrote:
> On Sun, Oct 01, 2000 at 08:51:04AM +1100, Jeremy Howard wrote:
> > 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 making -Mstrict and -Wall the d
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 pro
Karl Glazebrook wrote:
> Ilya Zakharevich wrote:
> > On Thu, Sep 28, 2000 at 11:39:51AM -0400, Karl Glazebrook wrote:
> > > > > so what is wrong with the statement '@y = 3*@x;' then ?
> > > >
> > > > That other constructs *also* create an array context, in which the
> > > > behaviour of multiplica
get rid of them all!!
Ilya Zakharevich wrote:
>
> On Thu, Sep 28, 2000 at 11:39:51AM -0400, Karl Glazebrook wrote:
> > > > so what is wrong with the statement '@y = 3*@x;' then ?
> > >
> > > That other constructs *also* create an array context, in which the
> > > behaviour of multiplication you
On Thu, Sep 28, 2000 at 11:39:51AM -0400, Karl Glazebrook wrote:
> > > so what is wrong with the statement '@y = 3*@x;' then ?
> >
> > That other constructs *also* create an array context, in which the
> > behaviour of multiplication you propose is not appropriate.
>
> for example?
A prototypel
Ilya Zakharevich wrote:
> > so what is wrong with the statement '@y = 3*@x;' then ?
>
> That other constructs *also* create an array context, in which the
> behaviour of multiplication you propose is not appropriate.
for example?
> I did not see any viable proposal on changing things in a majo
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
Ilya Zakharevich wrote:
>
> On Sat, Sep 23, 2000 at 11:32:58AM -0400, Karl Glazebrook wrote:
> > Yes this is the point. I guess another way of looking at it is
> > saying that 3*@a operates in a list context not a scalar context
>
> Well, this shows that you entirely miss the problem of cryptoco
On Sat, Sep 23, 2000 at 11:32:58AM -0400, Karl Glazebrook wrote:
> Yes this is the point. I guess another way of looking at it is
> saying that 3*@a operates in a list context not a scalar context
Well, this shows that you entirely miss the problem of cryptocontexts.
Context is determined by the
[EMAIL PROTECTED] wrote:
>
> Ilya Zakharevich wrote:
> > ...Do you say you are confused by using vectors (=scalars) instead of
> > arrays?
>
> I'm not having a problem with that personally but *many* users of PDL
> have complained about being confused by this.
> They assume ndim == array == perl
Ilya Zakharevich wrote:
>
> On Sat, Sep 23, 2000 at 10:41:07AM +1100, Jeremy Howard wrote:
> > Many Perl users operate on lists of data. Requiring explicit loops every
> > time a programmer wants to operate on a list is asking the programmer to fit
> > in with how a computer thinks. That's not r
Ilya Zakharevich wrote:
>
> 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
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 language
Ilya Zakharevich wrote:
> Are you trying to convince me/us that is going to be used often?
>
Yes, I am. You made the unsupported statement that array operations are
rarely used. I'm suggesting otherwise (although to say that they're rarely
used in Perl 5 is a tautology, of course!).
> > Array not
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 simplif
Karl Glazebrook wrote:
> Ilya Zakharevich wrote:
> > You are trading a frequently used shortcut @a == 1 + $#a for a
> > rarely-used-but-beautiful/intuitive semantic. I'm not sure it is a win.
>
> It's now boiling down to a matter of opinion and we'll have to agree to
> differ. Of course I use arr
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
> somethin
Ilya Zakharevich wrote:
> > > Moveover,
> > >
> > > $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?
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?
Ilya Zakharevich wrote:
> You are trading a frequently used shortcut @a == 1 + $#a for a
> rarely-used-but-beautiful/intuitive semantic. I'm not sure it is a win.
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 h
Karl Glazebrook wrote:
> Ilya Zakharevich wrote:
> > f(3*@a)
> >
> > would typically be a list context - and suddently instead of 3*(1+$#a)
> > you get C.
>
> This is true, what I would propose is we declare 3*(1+$#a) outmoded and
> always have it mean C in all contexts.
>
> This of course wi
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 C.
>
> This is true, what I would propose is we declare 3*(1+$#a) outmoded and
> always have it mean C in
Ilya Zakharevich wrote:
> But with Fortran such things are not *needed*. Compilers are smart
> enough to convert (equivalents to)
>
> map 3*$_, 34..67
This is true, but easier (and less buggy) to say what you
exactly what you mean. 102:201:3
Anyway the idea has been proposed, it won't break
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 cor
At 03:35 PM 9/21/00 -0400, Buddha Buck wrote:
>At 03:26 PM 9/21/00 -0400, Karl Glazebrook wrote:
>
>> > > Finally as an overload expert what do you think about the proposals
>> > > to make arrays overloadable objects so one can say things like:
>> > >
>> > > @x = 3 * @y;
>
>What do you think of:
>
At 03:26 PM 9/21/00 -0400, Karl Glazebrook wrote:
> > > Finally as an overload expert what do you think about the proposals
> > > to make arrays overloadable objects so one can say things like:
> > >
> > > @x = 3 * @y;
>I can see that allowing expressions on @x would require considerable
>chan
Ilya Zakharevich wrote:
> As shipped: no. But if this is made a primitive (which I would not
> like), then the only change which is needed is to make the
> tie::multi::range() token to be followed by 3 numbers.
>
> [Aside: Why not make ternary-range operator into 10 :: 20 :: 2 ?]
That would wor
On Tue, Sep 19, 2000 at 08:41:34AM +1200, Christian Soeller wrote:
> > Finally as an overload expert what do you think about the proposals
> > to make arrays overloadable objects so one can say things like:
> >
> > @x = 3 * @y;
>
> Is this where RFC 231's suggestion for OO slicing comes in (see
On Mon, Sep 18, 2000 at 08:56:28AM -0400, Karl Glazebrook wrote:
> Firstly does your proposal allow for a slice like 10..20:2 (i.e. with
> a stride of 2) ?
As shipped: no. But if this is made a primitive (which I would not
like), then the only change which is needed is to make the
tie::multi::r
> Finally as an overload expert what do you think about the proposals
> to make arrays overloadable objects so one can say things like:
>
> @x = 3 * @y;
Is this where RFC 231's suggestion for OO slicing comes in (see quote)?
> For example,
>
>$matrix1->[2..5; 2..4] * $matrix2->[1,3,
Hi Ilya,
I have three questions about your RFC:
Firstly does your proposal allow for a slice like 10..20:2 (i.e. with
a stride of 2) ?
If not is there an easy way to incorporate that?
Secondly, what about having multidim support in the core so that the
tie-tokenisers get optimised away? i.e.
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)
Ilya Zakharevich wrote:
> 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
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
Ilya Zakharevich wrote:
> On Sat, Sep 16, 2000 at 11:08:18AM +1100, Jeremy Howard wrote:
> > - How does it relate to RFC 204? Is it an alternative, or an addition?
>
> 204 cannot be implemented since it prohibits usage of overloaded
> objects as array indices.
>
Why is it important for overloaded
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 b
> =head1 TITLE
>
> Data: Multi-dimensional arrays/hashes and slices
<...>
> =item *
>
> proposes a convenient syntax to slice multi-dimensional arrays;
>
> =item *
>
> proposes a convenient syntax create subobjects which behave as slices;
>
> =item *
>
> does it with as little overhead as possib
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Data: Multi-dimensional arrays/hashes and slices
=head1 VERSION
Maintainer: Ilya Zakharevich <[EMAIL PROTECTED]>
Date: 15 September 2000
Mailing List: [EMAIL PROTECTED]
Number: 231
Version: 1
St
38 matches
Mail list logo
