On Fri, 24 Oct 2003, Gordon Henriksen wrote:
On Monday, October 20, 2003, at 11:40 , Jeff Clites wrote:
My solution was to define a new vtable method--I've called it visit(),
though the name's not the important part--to which you pass a callback
(plus an optional context argument). It's job is to invoke that
callback on each of it's referenced "children" (also passing the
context object with each invocation), and that's it. The PMC doesn't
know or care what the callback does--in a GC context the callback may
set a flag on what's passed in and stash it for later processing; in
another context it may be used inside of an iterator which vends out
objects one-by-one and guards against loops.
Great! This is exactly the fundamental operation I'd been musing would be the best building block to enable serialization and pretty-print operations, and I'm sad to see that your post has been Warnocked. :(
Allow me to haul out this bucket of ice-water I keep around for just such
an eventuality. :)
There's a low limit to the complexity of any sort of traversal we can
provide. We *can't* go recursive in a traversal, if it crosses the
C->Parrot or Parrot->C boundary as part of the recursion, or stays
entirely in C. We can only count on a 20-40K stack *total*, and it doesn't
take too many calls into a recursive procedure to eat that up. That limits
the mechanisms we can use to traverse the graph of objects pretty badly.
The linked list mechanism the DOD system is using is one of the few that
isn't recursive.
There are other mechanisms that can be used for traversal that avoid
recursion, but they generally trade off pretty heavy memory usage for that
lack, which makes them unsuitable for general use.
Who said anything about recursion?
JEff
