Subject: Re: [Fwd: the state of the art of predicate dispatching]
From: Craig Chambers (chambers@cs.washington.edu)
Date: Wed Jul 11 2001 - 13:27:37 PDT
Sorry, I forgot that you all got on the cc list already.
-- Craig
Craig Chambers wrote:
>
> 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
_______________________________________________
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 - 13:28:04 PDT