Dan Sugalski wrote: > 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.
That's what's beautiful about this: ->visit isn't providing the traversal algorithm at all. This vtable is agnostic to the traversal algorithm. Breadth-first or depth-first; seen hash or mark bit or what have you; zero-resource or resource-consuming: Whatever is best suited to the requirements at hand. And it cleanly exposes that core functionality to HLLs (which may have algorithmic requirements for traversals that involve queues or stacks). If parrot is embedded multi-threaded in an RDBMS or web server (which strikes me as a more likely scenario than parrot embedded in a resource-constrained embedded environment), then blocking the interpreter for a serialization on one thread will negatively impact response time, concurrency, and scalability. That might be considered more damaging than additional resource consumption. ->visit neatly enables BOTH resource-consuming, threadsafe serialization AND zero-resource, blocking serialization. -- Gordon Henriksen IT Manager ICLUBcentral Inc. [EMAIL PROTECTED]
