in multi-dimensional arrays. I modified the array in a
loop, but when that loop was finished and I printed the array in
another loop it had incorrect values. Below is some code that
demonstrates the behavior. @d[0..3;1] should be 3,5,7,9, but instead
they're all 9. This was tested on the trunk,
-- Forwarded message --
From: Carl Mäsak
Date: Sun, Apr 5, 2009 at 9:30 AM
Subject: Re: Multi-Dimensional arrays
To: Peter Schwenn
Peter (>):
> I've had inconsistent/incorrect results, once having created an array
> of array of arrays, both while addressing ele
-- Forwarded message --
From: Peter Schwenn
Date: Apr 4, 2009 3:14 PM
Subject: Re: Multi-Dimensional arrays
To: Carl Mäsak
I've had inconsistent/incorrect results, once having created an array
of array of arrays, both while addressing elements in it as
@A[l][m][n]=x and
Peter (>):
> Am I right that multi-dimensional arrays do not yet work fully in Rakudo?
Yes, you are.
That is to say, you can't do this yet:
my @a[4;2]; # Valid indices are 0..3 ; 0..1
There's nothing stopping you from creating an array of arrays, though.
// Carl
Am I right that multi-dimensional arrays do not yet work fully in Rakudo?
#x27;t need that.
I'm going to be a bit annoying here -- I'm going to refer to another
language, and I'm going to recommend that it's of interest to this group.
Briefly: There's a language (K, see www.kx.com), which has been used
to implement a rather elegant (fast, smal
At 02:07 PM 6/12/2001 -0500, David L. Nicol wrote:
>Dan Sugalski wrote:
>
> > I'm still trying to formulate a good set of rules on how I think active
> > data should perform under optimization to pass on to Larry.
> >
>
>How about, Active data doesn't get optimized. Static data doesn't
>care if y
Dan Sugalski wrote:
> I'm still trying to formulate a good set of rules on how I think active
> data should perform under optimization to pass on to Larry.
>
> Dan
How about, Active data doesn't get optimized. Static data doesn't
care if you access ir or
At 10:33 PM 6/11/2001 -0500, David L. Nicol wrote:
>[EMAIL PROTECTED] wrote:
>
> > You may wish to read this thread about lazy arrays and object
> > persistence to get an idea of what you're getting into.
> > http://www.geocrawler.com/archives/3/3024/2001/3/0/5427925/
>
>Taking lazy as far as we c
On Mon, Jun 11, 2001 at 10:33:20PM -0500, David L. Nicol wrote:
> Taking lazy as far as we can, has anyone been thinking about
> a compilation mode in which all expensive accesses get deferred until
> there is a decision to be made? I know some functional languages
> (and Algol 68?) do this
Hask
I think you could only delay function calls automatically like this if you
could ensure that they are truely functional. That is, their output must
depend only on the arugments given and must have no mutation
side-effects. It seems to me that this is hard to guarantee in Perl, even
for the compi
[EMAIL PROTECTED] wrote:
> You may wish to read this thread about lazy arrays and object
> persistence to get an idea of what you're getting into.
> http://www.geocrawler.com/archives/3/3024/2001/3/0/5427925/
Taking lazy as far as we can, has anyone been thinking about
a compilation mode in whic
Vijay Singh wrote:
> >"Just how much $foo can dance on the head of a dot operator"
The current Annals Of Improbable Research (http://www.improb.com)
has a piece on applying modern physics to the age-old question, you
know, about the boogieing angels.
--
> -Original Message-
> From: Simon Cozens [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 11, 2001 3:46 AM
> To: Vijay Singh
> Cc: Me; [EMAIL PROTECTED]
> Subject: Re: Multi-dimensional arrays and relational db data
>
>
> On Sun, Jun 10, 2001 at 10:13:28
At 04:43 PM 6/11/2001 +0100, Simon Cozens wrote:
>On Mon, Jun 11, 2001 at 11:20:15AM -0400, Dan Sugalski wrote:
> > nice things about PL/SQL), but I would like to note that this statement,
> > while true, is effectively meaningless. Might as well say the same about
> > perl 5 because anyone who wa
At 04:43 PM 6/11/2001 +0100, Simon Cozens wrote:
>On Mon, Jun 11, 2001 at 11:20:15AM -0400, Dan Sugalski wrote:
> > nice things about PL/SQL), but I would like to note that this statement,
> > while true, is effectively meaningless. Might as well say the same about
> > perl 5 because anyone who wa
On Mon, 11 Jun 2001, Daniel S. Wilkerson wrote:
> For example, the
> "going back in time and preventing your grandparents from having sex"
> situation.
Bah, who needs sex these days? A little in vitro here, a little
cloning with genetic tweaking there...a whole new person, no sex inv
Dan Sugalski wrote:
> At 04:20 PM 6/11/2001 +0100, Simon Cozens wrote:
> >On Mon, Jun 11, 2001 at 08:16:12AM -0700, Daniel S. Wilkerson wrote:
> > > At *runtime*? You won't need computed gotos or eval anymore. You just
> > have
> > > one block of generic-looking code and you change what the syn
Simon Cozens wrote:
>
> This is the kind of thing that can be dealt with perfectly satisfactorily
> with external modules; ergo, it does NOT need to be in the core. Ergo,
> it probably *does* *not* *need* *discussing* *here*.
Much of the discussion on this list seems to concern what will be the
On Mon, Jun 11, 2001 at 11:20:15AM -0400, Dan Sugalski wrote:
> nice things about PL/SQL), but I would like to note that this statement,
> while true, is effectively meaningless. Might as well say the same about
> perl 5 because anyone who wanted to could hack toke.c.
OK, I'll put it another w
At 04:20 PM 6/11/2001 +0100, Simon Cozens wrote:
>On Mon, Jun 11, 2001 at 08:16:12AM -0700, Daniel S. Wilkerson wrote:
> > At *runtime*? You won't need computed gotos or eval anymore. You just
> have
> > one block of generic-looking code and you change what the syntax means
> before
> > it exe
On Mon, Jun 11, 2001 at 08:16:12AM -0700, Daniel S. Wilkerson wrote:
> At *runtime*? You won't need computed gotos or eval anymore. You just have
> one block of generic-looking code and you change what the syntax means before
> it executes. Three routines in one!
Before? Bah, woosy. *AS* it ex
At 10:26 PM 6/10/2001 +0100, Simon Cozens wrote:
>It doesn't matter, because the user can redefine the syntax anyway.
I'm staying completely out of the argument that spawned this (Though the
idea of welding SQL directly into perl has some appeal--it was one of the
few (okay, the only one I can
Me wrote:
> I don't think it's reasonable to say I propose you change
> something that hasn't yet been defined. Rather, it is
> precisely because you haven't yet defined the MD array
> syntax that I thought it worth at least considering how it
> parallels db data BEFORE you define it.
Considerin
Sam Tregar wrote:
> Perl 6 will allow you to mutate your syntax at runtime any way you want.
At *runtime*? You won't need computed gotos or eval anymore. You just have
one block of generic-looking code and you change what the syntax means before
it executes. Three routines in one!
Daniel
OK. My last addition to this painful thread.
> Your position depends on having a syntax so simple
> that it is somehow worth implementing as a native
> capability instead of the tied modules others have
> pointed out.
No it does not. I am not suggesting that a rdb modelling
tied version of MD ar
On Sun, Jun 10, 2001 at 10:13:28PM -0800, Vijay Singh wrote:
> Why is it that "Me" is *mouthing off*, but you're not? Why is that?
> What makes you so *special*?
In "Me"'s defence, at least they do occasionally produce some useful
thoughts about Perl 6, and are not here simply for personal attac
As this has drifted off-topic, I've set the Reply-To on this to
POOP-group, please send replies there and not perl6-language.
On Sun, Jun 10, 2001 at 06:06:27PM -0500, Me wrote:
> > modeling of the whole database
>
> Doesn't seem like it's hard to do.
HA! Think "Lights Out": It...is...harder
Previously, on St. Elsewhere...
Simon(e) writes...
> But of course, I'm sure you already know what makes
> good language design, because otherwise you wouldn't
> be mouthing off in here...
Why is it that "Me" is *mouthing off*, but you're not? Why is that?
What makes you so *special*? The fact
At 11:07 PM 6/10/01 -0500, Me wrote:
> > > [joining 2d arrays]
>
> > I can't envisage this... Perhaps you could reveal an example.
>Seems simple to me. Perhaps you meant the concrete
>method and/or syntax to achieve the join, or to reference
>the two arrays, or to reference the result table. But t
On Sun, Jun 10, 2001 at 03:31:09PM -0700, Peter Scott wrote:
> He's right. I do a lot of DBI stuff with Oracle, and every so often I have
> a hankering for some kind of structured tied variable that would look like
> my database. Then I wake up and realize that modeling of a single table
> do
On Sat, Jun 09, 2001 at 10:57:25PM -0500, Me wrote:
> For this post (and hopefully thread), I'm interested in focusing
> on the fact that a multi-dimensional array syntax, whatever it
> might end up being, is clearly going to be a direct analog of
> tables
You're on the wrong list. All the langu
On Sun, Jun 10, 2001 at 04:05:20PM -1000, Tim Jenness wrote:
> At the risk of receiving a flame perl5 does not have multi-dimensional
> arrays. It has something that will do the job with a massive memory
> overhead ands lots of pain when dimensionality is high.
If you need it, I can f
verloading in Perl 5
> to access relational databases in Perl 5. Are you going to make me show
> you an example before you believe me?
>
At the risk of receiving a flame perl5 does not have multi-dimensional
arrays. It has something that will do the job with a massive memory
overhead ands
> > [joining 2d arrays]
> I can't envisage this... Perhaps you could reveal an example.
Well, for a trivial example, here's two 2d arrays:
foo, bar, baz,
qux, quux, waldo
and
rab, foo, baz,
xuuq, qux, zug
Joining the first col of array 1 with the second col of
array 2 would
On Sun, Jun 10, 2001 at 03:31:09PM -0700, Peter Scott wrote:
> Even if your database is so simple that you do just want to model single
> tables, it would be easy to build atop DBI.
That'd be Tie::DBI, then.
This is the kind of thing that can be dealt with perfectly satisfactorily
with externa
At 06:06 PM 6/10/2001 -0500, Me wrote:
>Dataset from multiple 'joined' tables
>
> (A pair of joined tables can be visualized as two
> spreadsheet like grids that intersect at right angles
> with the intersection point being the joined column.
> The vertical slice picks out rows whe
> modeling of the whole database
Doesn't seem like it's hard to do.
With MD arrays, you are all but there anyway:
Table:
A 2d array.
Whatever is introduced to more directly support
handling MD arrays could very plausibly help in
more directly supporting handling of single tabl
Sam, I don't think we're on the same wavelength.
So a direct response seems pointless.
Larry himself said:
"while allowing multidimensional arrays to distinguish
between [this and that] in a manner more conducive to
database programming"
Ok, I did s/numerical/database/, but what's
At 05:58 PM 6/10/2001 -0400, Sam Tregar wrote:
>SQL via DBI. It's got a terrible learning curve but it's still around for
>a reason. You learn all about SQL's strengths if you start trying to
>replace it with arrays and hashes. Go forth and learn!
He's right. I do a lot of DBI stuff with Orac
On Sun, 10 Jun 2001, Me wrote:
> Agreed. So long as you are talking about Perl 5's arrays.
>
> I disagree, if you are talking about 2 dimensional structures.
You appear to have some fundamental misunderstanding about Perl 5. Perl 5
does indeed support multidimentional arrays:
my @matrix = (
> If array syntax really is a good analogy to database
> access (it's not)
Agreed. So long as you are talking about Perl 5's arrays.
I disagree, if you are talking about 2 dimensional structures.
If you don't think a two dimensional structure is a good
basic fit with a lot of database access, w
On Sun, Jun 10, 2001 at 01:56:21PM -0500, Me wrote:
> Yes. But if the syntax for arrays and db data are to
> be simultaneously the same and as ideal as possible,
> then either the core array syntax needs to be relatively
> ideal for relational db data, or one needs to redefine
> the array syntax t
match a created db syntax and thus
> have a version of perl that doesn't use the standard
> array syntax.
>
> While the latter is pretty cool, it's a whole lot less cool
> than the former (assuming that multi-dimensional arrays
> and relational db data are as close cou
array syntax to match a created db syntax and thus
have a version of perl that doesn't use the standard
array syntax.
While the latter is pretty cool, it's a whole lot less cool
than the former (assuming that multi-dimensional arrays
and relational db data are as close cousins as I think
they may be).
On Sat, Jun 09, 2001 at 10:57:25PM -0500, Me wrote:
> B) any syntaces chosen for core features won't jar with what
> makes sense for the relational data sub-language (at least
> not accidentally).
But since the end user is going to be able to redefine the syntax anyway,
this isn't an issue.
--
(The intent is that) Perl 6 will be a better general purpose
programming language for building application specific
sub-languages.
I'm interested in how far Perl 6 could go in providing support
for a high-level expressive syntax sub-language for dealing
with relational data. To the extent the gen
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
Christian Soeller wrote:
> Karl Glazebrook wrote:
> > Buddha Buck wrote:
> > > >
> > > > @x = 3 * $y[|i];
> > > >
> > > >It's not as clean as @x = 3 * @y, but it is cleaner context-wise.
> > >
> > > And one could argue that:
> > >
> > > @x = map 3*^_, @y;
> > >
> > > is cleaner yet...
> >
>
Karl Glazebrook wrote:
>
> Buddha Buck wrote:
> > >
> > > @x = 3 * $y[|i];
> > >
> > >It's not as clean as @x = 3 * @y, but it is cleaner context-wise.
> >
> > And one could argue that:
> >
> > @x = map 3*^_, @y;
> >
> > is cleaner yet...
>
> PDL already allows $x = 3*$y
>
> why step back
Buddha Buck wrote:
> >
> > @x = 3 * $y[|i];
> >
> >It's not as clean as @x = 3 * @y, but it is cleaner context-wise.
>
> And one could argue that:
>
> @x = map 3*^_, @y;
>
> is cleaner yet...
PDL already allows $x = 3*$y
why step backwards?
KArl
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 additi
> =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;
>
> =ite
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
Vers
88 matches
Mail list logo
