At 08:51 AM 4/6/2006, Ian Bicking <[EMAIL PROTECTED]> wrote:
>So... in theory you could register strings, and thus implement
>RuleDispatches behavior (where those strings represent expressions).
>Or, ideally, py3k will have something better than strings to represent
>unevaluated expressions. Though there's lots of optimizations in
>RuleDispatch that would be lost when abstracted in this way.
I wouldn't worry about that. Give me an AST and the ability to edit
and compile it, and I'll move the world. :)
Really, if functions had a writable 'func_ast' attribute,
RuleDispatch could be a *lot* simpler than it currently is. Even the
syntax would be better, since when() could take a lambda function,
and I thus wouldn't have to do string parsing or have the
mini-interpreter. RuleDispatch could just manipulate the ASTs.
My plans for future versions of RuleDispatch had called for using
bytecode generation in order to produce more specialized dispatch
patterns based on the configuration and use of a particular function;
it would be *so* nice not to have to do it with bytecode.
In fact, the only other dream feature I'd ask for to make
RuleDispatch complete would be an AST abstraction for a hash table
lookup; i.e., an optimized form of:
if x==int:
...
elif x==str:
...
That is, I'd like to be able to put a structure like the above in a
while loop that's walking something's mro, and have it be as
efficient as doing a dictionary lookup that just branched within the
function instead of incurring a function call overhead to do a
table-based dispatch.
With that ability (which could also just be that setting func_ast to
such a dispatch tree automatically optimized the if-elifs to a
"computed goto"), RuleDispatch wouldn't have to create a special
"dispatch tree" structure except during compilation -- the AST would
be the runtime dispatch tree. And, Psyco-style, it could leave some
branches of the AST unexpressed except for a stub that requests that
branch be built out at runtime. In other words, delayed
specialization for unneeded branches.
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
