Subject: [Fwd: Re: the state of the art of predicate dispatching]
From: Craig Chambers (chambers@cs.washington.edu)
Date: Wed Jul 11 2001 - 13:05:59 PDT
FYI.
-------- Original Message --------
Subject: Re: the state of the art of predicate dispatching
Date: Wed, 11 Jul 2001 12:56:47 -0700
From: Craig Chambers <chambers@cs.washington.edu>
To: Doug Orleans <dougo@ccs.neu.edu>
CC: Michael Ernst <mernst@cs.washington.edu>,Weimin Chen
<chen@darmstadt.gmd.de>, Aaron Ucko <amu@mit.edu>,Greg Sullivan
<gregs@ai.mit.edu>,Jonathan Bachrach <jrb@ai.mit.edu>, cecil@cs.washington.edu
References:
<15177.23414.665786.164752@alioth.ccs.neu.edu><3B4A4C70.6415E8DD@cs.washington.edu>
<15180.13209.75845.394627@vega.ccs.neu.edu>
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.
I see what you're getting at now. Cecil with predicate classes does support
resends to predicate superclasses, and the more general predicate dispatching
could used named predicates in a similar fashion. Your proposal above is a way
to resend to anonymous predicate methods. Yet another alternative is to allow
individual methods to be named, for purposes of resend and otherwise enforcing
ordering or equivalence between methods.
But the static properties of resend always going to an overridden method that
also is an applicable method at the time of the resend are in conflict to the
ability of the predicate state of an object to change during execution of a
method. This is an unresolved problem. I've seen some partial attempts to add
more static reasoning, including typechecking, to predicate class-like
mechanisms, but nothing completely satisfactory yet.
>
> > 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
Yes, we know that work. The external linking part of units is already found in
ML functors and the fully functorized version of structures, by the way. Units
allow recursive external linking, which ML functors do not (there is a paper by
Crary, Harper, et al. on recursive ML modules, which addresses a more
sophisticated type system than the units paper).
-- Craig Chambers
_______________________________________________
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:06:04 PDT