Phillip J. Eby wrote: > 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. :)
I was thinking about how RuleDispatch might extend built-in type-based generic functions, and I don't think you'd have the opportunity to do the same optimizations. That is, instead of RuleDispatch providing an alternate decorator, it would simply provide an alternate kind of predicate. My understanding of RuleDispatch is that given two predictaes "foo(a) > 10" and "foo(a) < 20", you calculate "foo(a)" once and apply both comparisons on that value. And that you also combine predicates to create a decision tree. However, if all RuleDispatch can do is give opaque boolean-producing functions for its predicates, the generic function machinery would have to scan through all predicates to determine what matched and if there was any ambiguity (except for the occasional condition you wouldn't have to test because of a dominance relationship). > 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. I personally would very much like a general syntax and associated support for unevaluated (and maybe unevaluatable) expressions, beyond just lambda; RuleDispatch is one of several projects already consuming such expressions. But that's a separate topic I was hoping to bring up once the generic function/adapter discussion died down some. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ 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
