Jeff G wrote:
>
> Simon Cozens wrote:
> >
> > I've just committed some changes after which Parrot will not compile.
> > This is quite deliberate. Basically, I'm trying to get the keyed stuff
> > working the way we want, and that requires some painful changes to the
> > source. The upshot is:
> >
Simon Cozens wrote:
>
> I've just committed some changes after which Parrot will not compile.
> This is quite deliberate. Basically, I'm trying to get the keyed stuff
> working the way we want, and that requires some painful changes to the
> source. The upshot is:
>
> All the vtable function
On Fri, Feb 08, 2002 at 02:08:54PM -0800, Larry Wall wrote:
> Dan Sugalski writes:
> : At 5:17 PM + 2/8/02, Simon Cozens wrote:
> : >Dan Sugalski:
> : >> Can't. Needs to be a linked list. Otherwise we can't nest data structures
> : >> well.
> : >
> : >Thanks; I knew there had to be a reason,
Dan Sugalski writes:
: At 5:17 PM + 2/8/02, Simon Cozens wrote:
: >Dan Sugalski:
: >> Can't. Needs to be a linked list. Otherwise we can't nest data structures
: >> well.
: >
: >Thanks; I knew there had to be a reason, couldn't remember what it was.
:
: Now all we need to do is figure out w
At 5:17 PM + 2/8/02, Simon Cozens wrote:
>Dan Sugalski:
>> Can't. Needs to be a linked list. Otherwise we can't nest data structures
>> well.
>
>Thanks; I knew there had to be a reason, couldn't remember what it was.
Now all we need to do is figure out whether keys at the lowest levels
wil
Dan Sugalski:
> Can't. Needs to be a linked list. Otherwise we can't nest data structures
> well.
Thanks; I knew there had to be a reason, couldn't remember what it was.
--
> I'm a person, not a piece of property.
Happily, I'm both!
- Lionel and Stephen Harris.
Gregor N. Purdy writes:
: I think of slicing as a shortcut for map.
:
:foo[1,2,3] ===map { foo[$_] } (1,2,3)
:
: I think of multidimensionality as arrays-of-arrays:
:
:foo[1][2]
:
: As for combining the two, I guess that would be
:
:foo[1,2][3,4] =~= temp = map { foo[$_] }
At 4:08 PM + 2/8/02, Simon Cozens wrote:
>Larry Wall:
>> I just think of multidimensionality as another "list of" dimension on
>> top of the slices. Alternately, you can think of it as another
>> dimension on each leaf that turns each scalar into a list. But the
>> extra dimension has to
Larry --
> Simon Cozens writes:
> : Gregor N. Purdy:
> : > I was only involved in a small amount of 'key' discussion. FWIW, I
> : > would have thought the KEY_PAIR thingee was for (array) slice ranges,
> : > not multidimensional indexing...
> :
> : Then it's doubly mis-named, because KEY_PAIR ho
Larry Wall:
> I just think of multidimensionality as another "list of" dimension on
> top of the slices. Alternately, you can think of it as another
> dimension on each leaf that turns each scalar into a list. But the
> extra dimension has to sneak in there somewhere if we're to allow
> multidim
Simon --
> > I was only involved in a small amount of 'key' discussion. FWIW, I
> > would have thought the KEY_PAIR thingee was for (array) slice ranges,
> > not multidimensional indexing...
>
> Then it's doubly mis-named, because KEY_PAIR holds a single key, not a
> pair of anything, and KEY ho
Simon Cozens writes:
: Gregor N. Purdy:
: > I was only involved in a small amount of 'key' discussion. FWIW, I
: > would have thought the KEY_PAIR thingee was for (array) slice ranges,
: > not multidimensional indexing...
:
: Then it's doubly mis-named, because KEY_PAIR holds a single key, not a
Gregor N. Purdy:
> I was only involved in a small amount of 'key' discussion. FWIW, I
> would have thought the KEY_PAIR thingee was for (array) slice ranges,
> not multidimensional indexing...
Then it's doubly mis-named, because KEY_PAIR holds a single key, not a
pair of anything, and KEY holds a
Simon --
I was only involved in a small amount of 'key' discussion. FWIW, I
would have thought the KEY_PAIR thingee was for (array) slice ranges,
not multidimensional indexing...
> > If the KEY* has one KEY_PAIR element which is numeric, you've got an index
> > into an array; if it has one KEY_P
Simon Cozens:
> If the KEY* has one KEY_PAIR element which is numeric, you've got an index
> into an array; if it has one KEY_PAIR element which is a string or a PMC*,
> you've got an index into a hash. If it has multiple KEY_PAIR elements,
> you're dealing with a multidimensional hash or array.
Simon Cozens:
> I'm working on unbreaking it, patches welcome.
Unfortunately, it seems the way that key.c works is currently a lot more
broken than I suspected. :( This is going to take some time.
The plan, such as it is, is that a KEY* structure is an index, rather
than being an aggregate itsel
I've just committed some changes after which Parrot will not compile.
This is quite deliberate. Basically, I'm trying to get the keyed stuff
working the way we want, and that requires some painful changes to the
source. The upshot is:
All the vtable functions _index and index_s are dead; they
17 matches
Mail list logo
