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:
All the
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;
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
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_PAIR
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
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
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 holds a
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 sneak in
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[$_]
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.
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
will deal
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, couldn't
12 matches
Mail list logo
