Predicate Classes 
Author Message
 Predicate Classes

> >       case
> >       non_empty_state() & non_full_state()        => #"partially_full_state"
> >       non_empty_state()                       => #"non_empty_state"
> >       non_full_state()                        => #"non_full_state"
> >       ~non_empty_state()                      => #"full_state"
> >       ~non_full_state()                       => #"empty_state"
> >       end;

>   But with the above case stmt will you ever get to #"non_full_state"?
>   Only if the buffer becomes empty? But what if you wish to dispatch
>   it is empty...

Ok, good point.  I didnt think that one through.  In this case you'd
actually need more than one state determiner for each context (where a
"context" is defined as some set of non-overlapping states).  However, this
implies potentially duplicating some code across
similar-but-not-quite-the-same state determiners.  Not as well factored as
with predicate classes where a single set of predicates can get reused in
various combinations.


>  My point is that FINDING the points at which a state-transition can
>  in the arbitrary predicate case is hard.  If you wish to "cherry pick"
>  the case where the predicates denote non-overlapping states and these
>  state-transitions are easy to find the an optimizing compiler could just
>  dynamically change the object's "class" ( where the predicate classes
>  be legitamate runtime classes ). This would require no extra slots
>  and fits transparently into the method dispatch process.
>  [ Indeed in Cecil objects are "classless" and created using


Writing a parser for an arbitrary grammar is hard too - but that doesn't
stop people from finding the "cherry-picked" case of LR(1) grammars useful.
 They're efficient and sufficiently flexible for most needs. Likewise I can
think of many possible real-world situations where finding the
state-transitions is not particularly hard, for example :-

- many objects that need specialized handling of boundary conditions
- communications protocols that define various states
- "configurable" objects
- any kind of finite-state machine

Whats more, just as it is argued that one of predicate-classes advantages
is the fact that each "state" is clearly documented, it can also be argued
that documenting the state-transitions is just as advantageous.  The fact
that there are situations where finding state-transitions is hard should
not be justification for avoiding techniques that require state-transitions
to be known.  There are really no "magic bullets" and you can find
trade-offs in any technique or algorithm.

As for smart compilers optimising predicate method dispatch by
automatically figuring out where the transitions take place and changing
the objects "class" at that point - I find that very doubtful.  Even if all
the predicates do is trivially test the value of some variable, figuring
out *when* that variable can change  would take something like HAL 9000.
Yet a programmer would often have that knowledge readily available and can
therefore use it to optimize things.

> >> "State Dispatch Construction Defect"
> ...
> >Actually, what I had in mind was a macro that defined the "state
> >stub methods".  ie.

> >define state-dispatched-method name( p1, p2, ... ) using discriminant x;

> > ( expands to ) =>

> >       define method name( p1, p2, ... )
> >               _name( x( p1 ), p1, p2, ... )
> >       end;

>    Seems awfully single argument dispatch oriented to me. What if the
>    predicate object specializer is the second, third, etc. argument?  
>    What if the method has two or more arguments that can be predicate


True, though it can be generalised using something like :-

define state-dispatched-method( p1, p2, ... ) using discriminant x on p1, y
on p2, ...;

which expands to,

        define method name( p1, p2, ... )
                _name( x( p1 ), y( p2 ), p1, p2, ... )

ie. you get a singleton specialiser for each state-determiner function.
The basic idea holds.

Overall, I concede that predicate classes allow you to factor your code
better in the (reasonably common) case where you have overlapping states.
Without predicate classes however, then even with overlapping states, the
"state-dispatch-via-singletons" approach would still be much better than
inlining the dispatch with if/case statements scattered across all your

Louis Madon

Sun, 29 Aug 1999 03:00:00 GMT  
 [ 1 post ] 

 Relevant Pages 

1. Predicate Classes ( was Re: Circle/Ellipse )

2. predicate classes

3. Predicates that create new predicates.

4. Code for simplifying predicate expressions

5. No directoryp predicate in MSWLogo ?

6. No directoryp predicate in MSWLogo ?

7. predicate names

8. LOGO-L> predicate writing

9. Collection operations taking pseudo-predicates?

10. What predicates should a teaching prolog have?

11. Equivalence predicates

12. Predicate dispatching implementation in Scheme?


Powered by phpBB® Forum Software