Subject: [Fwd: the state of the art of predicate dispatching]
From: Craig Chambers (chambers@cs.washington.edu)
Date: Wed Jul 11 2001 - 12:57:01 PDT
FYI.
Doug Orleans wrote:
>
> 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:58:04 PDT