Re: the state of the art of predicate dispatching


Subject: Re: the state of the art of predicate dispatching
From: Doug Orleans (dougo@ccs.neu.edu)
Date: Wed Jul 11 2001 - 04:08:09 PDT


Craig Chambers writes:
> I haven't thought about it much, but I'm not sure what more you need. Is
> Cecil's possibly-directed resend not all that's needed? Are you asking about
> semantics, or implementation?

Correct me if I'm wrong, but Cecil's resend can only "cast" the
arguments to objects higher up the inheritance graph. How do you do a
resend to a predicate method that doesn't differ on the type of the
arguments but, say, the contents? For example, how would a method
whose predicate applies when the size of a buffer was zero resend to
the method that works for all non-full buffers? Hm, I guess you could
direct the resend to a predicate class, but wasn't one of the points
of the predicate dispatching paper that there were some things you
couldn't do with predicate classes? I guess the canonical example is
testing that two arguments are equal-- how would you resend to the
method that applied when the first argument was less than or equal to
the second?

Hm, maybe the resend can provide the arguments plus an additional list
of predicate assertions, such that the applicable predicates must be
implied by the assertions.

    method foo(x, y) when x == y {
      print("equal");
      foo(x, y) when x <= y;
    }

Maybe that's not the best choice of syntax, but I think something
along those lines would work (maybe "with", or "assert", or "direct"?
"generalize"?). If you allow the same "x@C" syntactic sugar in
function call arguments as you allow in method parameter lists, then
it is backwards-compatible with Cecil's directed resend.

> We have put less effort recently on the boundaries of
> flexibility offered by predicate dispatching, pursuing instead
> modularity solutions (on the language design front) that help in
> "spreading the word" to Java (and ML, and software
> architecture/components) programmers, and on new compiler
> architectures (on the implementation front), plus other things. We
> have limited resources, and pursuing predicate dispatching doesn't
> seem to be the biggest bang for our buck right now, nor the
> greatest area of student interest.

I didn't mean to imply that it was a bad thing not to focus on
predicate dispatching; certainly your other goals are important also.
About modularity solutions: have you looked into "units" from the PLT
team (formerly of Rice, currently transferring to Northeastern)? The
main idea from that (as far as I can tell) is external linkage of
modules, so that their imports are parameterized rather than referring
to specific other modules to be imported. This may be orthogonal to
the problems you're trying to address, but I think it's a useful idea
to consider when doing any sort of module system.

http://www.cs.rice.edu/CS/PLT/Publications/#icfp98-ff

Thanks,
--Doug
_______________________________________________
Cecil mailing list
Cecil@cs.washington.edu
http://majordomo.cs.washington.edu/mailman/listinfo/cecil



This archive was generated by hypermail 2b25 : Wed Jul 11 2001 - 12:50:05 PDT