Log of /PEAK-Rules/DESIGN.txt

Parent Directory

No default branch
Bookmark a link to HEAD: (view) (download)

Fix some 3.3+ shallow failures

Fix various shallow test failures on 3.x

Unify exception reprs across 2.x and 3.x so tests work

Python 3 test compatibility

Allow registering methods for generic functions that aren't imported yet

Fix a problem with ambiguity between (aType,) and (istype(aType),) in 
TypeEngine functions, and add an error message when you define circular 
method precedence rules.

Rename 'precedence' attribute to 'serial', since that's really what it 
is, i.e., a definition order.  While it's true that you *could* try to 
use it for an explicit precedence, it'd be tough to do sanely.  
Therefore, it's better to have it be clear what this actually is at
the moment, and avoid confusion with all the other aspects of 
"precedence" (like implication and method-override order).

Implement 'value()' convenience API for defining methods that just 
return a constant value.  Add memoizing to engine.apply_template, so 
that we don't create a crapload of function objects for identical 
method combinations.

Overhaul method compilation: renamed optimized() to compiled() and made 
__call__ optional.  Support template-compiled methods.  Moved method 
combination docs to "user manual" (such as it is) and simplified the 
custom combination example.  Method invocation overhead should now be 
at an absolute minimum, with only a single overhead layer for before, 
after, and default-combination methods (and zero for around and standard 
methods), and no *arg/**kw overhead at call time.

Begin separating API from core, so that peak.rules main module contains
only stuff you need for *using* GF's, not extending/customizing, and
core only contains stuff that's mutually interdependent w/other core
stuff.  Change imports in doctests to reflect intended usage.

Fix typo

Support before/after/around methods in conjunction with custom 
combinations.

Arbitrary method combinations made easy!  You can now trivially emulate
most of CLOS's standard method combinations (e.g. @combine_using(sum) 
emulates CLOS's "+" combination.)

Method compilation - remove some of the function calling overhead for
methods, by preprocessing.  See DESIGN.txt for docs.

Wiki cleanups

Fixed 'after' methods discarding main function return value
(reported by Sergey Schetinin)

Determine sequence (and therefore definition precedence) at
rule *parsing* time, rather than rule *addition* time.  This
ensures that lexical order holds within class bodies, and
also prevents confusion when a ruleset is populated using
data from other rulesets.  (i.e. rulesets no longer generate
sequence numbers.)  Also, created a ParseContext struct to
simplify the signature of the unwieldy parse_rule() function.

Consolidate Rule and ActionDef types, making it easier
to link rulesets.

Design doc cleanups

Improve the robustness of the core bootstrapping process, and flesh out
the ``Engine`` abstract base class a bit.  RuleSets now generate actions
using ``disjunct()``, so they should work with the predicate system now.
``overrides()`` for methods is now distinct from ``implies()``, as that
lowers the self-referentiality complexity just a bit.  :)  Also, it
paves the way to creating a less error-prone way of haing inter-
methodtype priorities (e.g. Around vs. Before/After, etc.).

PEAK-Rules is now as "smart" as RuleDispatch, in that it now
"knows" as much as RuleDispatch does about logical conditions
regarding Python objects, and how to index them efficiently.
The machinery is also better documented (and probably better
tested) than the equivalent bits of RuleDispatch.

Alas, this does not mean that you can actually use Python
expressions for generic function criteria yet, as the actual
tree builder/interpreter hasn't been written.  So we can
evaluate and index expressions, but not build them from an AST
or build/run a dispatch tree from the indexes.  Still, it's
getting *really* close now!

Implement indexing for is/not and </>/==/!= conditions, and general
bitmap-based index facility.  (Still needs class indexing to achieve
parity with the comparable parts of RuleDispatch, but it's getting
close.)

Minor doc tweaks/updates.

Python 2.5 support, common sub-expression caching in the code generator, and
misc. design note updates.

Misc. notes/doc changes left over from a few months ago.

Use struct types for rules and action definitions; correct dependencies 
to BytecodeAssembler 0.1 and DecoratorTools 1.1.

Fix a problem with the before/after decorators.  Get rid of the Rule 
type, so that rules are pure value objects that compare and hash easily 
(making it easier to remove a rule from a ruleset at a later time).  
Minor doc tweaks.

Shuffle some docs/tests around, add quickstart info

Extensible method combination has landed!  around(), before(), after(), 
and when() all work now, and new method types and decorators can be
created without needing to subclass any ruleset or engine classes.
All that's left for the core to be complete is for TypeEngine objects to 
generate wrapper code for the functions they're attached to.

Handle ambiguities in method combination.

Method combination basics: standard methods, "around" methods,
"no" methods, chaining and implication.  The DefaultEngine
doesn't support multiple methods w/identical signatures,
however, and AmbiguousMethods support isn't implemented.
Nonetheless, the core framework is shaping up nicely, it's
just fairly limited in what it can dispatch on.

Bootstrap phase zero: Rules, RuleSets, and a type-based
DefaultEngine that supports only exact type matches, but
is sufficient to implement the "implies()" generic function
(more or less).  The @abstract() and @when() decorators
also exist.  All in all, a highly miniaturized microkernel
version of peak.rules' future self.  The next phase will
be to implement method combination as a generic function,
and to add a bit of code generation to make generic functions
automatically call their __engine__ without needing any
boilerplate code.  (Caching would be good, too.)

Zero-functionality setup for PEAK-Rules: mostly design docs in README 
plus an outline of the functionality for the core framework in
framework.txt.