On Fri, Feb 08, 2002 at 02:08:54PM -0800, Larry Wall wrote: > Dan Sugalski writes: > : At 5:17 PM +0000 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 with slices and ranges, or whether we should emit chunks of > : bytecode to explicitly iterate through things. > > The object at the bottom has to be able to process slices and ranges > in case it wants to return a lazy list of its own. You can't just > iterate it on behalf of the object. > > Larry
Unless you wrapped up the chunk of bytecode and called it a closure. Though closures usually have a single entry point and there might be multiple complex accessors, so you'd either have to disambiguate with a parameter or have multiple entry points. In which case you could call it an interface object. Or you could just implement the complex accessor vtable entries in parrot bytecode. It all ends up looking the same. Or it doesn't, because the API could be different -- will there be vtable entries for slice/range lookups or not? I thought someone was talking about wrapping up the slice/range in a PMC, in which case it wouldn't show up in the API. Or it would in another form, if you didn't want to diddle with the slice/range PMC directly and instead had a get_next() vtable entry on such PMCs. But before they drag me away, I'll suggest that get_next() could be called get_integer() for arrays and get_string/_struct/_value for hashes.
