[Uche Ogbuji]
> Quite interesting. I brought up this *exact* point at the
> Stackless BOF at IPC9. I mentioned that the immediate reason
> I was interested in Stackless was to supercharge the efficiency
> of 4XSLT. I think that a stackless 4XSLT could pretty much
> annihilate the other processors in the field for performance.
Hmm. I'm interested in clarifying the cost/performance boundaries of the
various approaches. I don't understand XSLT (I don't even know what it is).
Do you grok the difference between full-blown Stackless and Icon-style
generators? The correspondent I quoted believed the latter were on-target
for XSLT work, and given the way Python works today generators are easier to
implement than full-blown Stackless. But while I can speak with some
confidence about the latter, I don't know whether they're sufficient for what
you have in mind.
If this is some flavor of one-at-time tree-traversal algorithm, generators
should suffice.
class TreeNode:
# with self.value
# self.children, a list of TreeNode objects
...
def generate_kids(self): # pre-order traversal
suspend self.value
for kid in self.children:
for itskids in kid.generate_kids():
suspend itskids
for k in someTreeNodeObject.generate_kids():
print k
So the control-flow is thoroughly natural, but you can only suspend to your
immediate invoker (in recursive traversals, this "walks up the chain" of
generators for each result). With explicitly resumable generator objects,
multiple trees (or even general graphs -- doesn't much matter) can be
traversed in lockstep (or any other interleaving that's desired).
Now decide <wink>.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4