Predicate dispatch would be an interesting topic. The #1 problem with predicate dispatch is method ordering. Predicate dispatch as described in the orignal paper [http://www.cs.washington.edu/homes/mernst/pubs/ dispatching-ecoop98-abstract.html] decides what order to used based on implication between predicates. For example:
def foo(x) where x is Animal = A def foo(x) where x is Chicken = B def foo(x) where x is Bird = C If you call foo(new Crow) you want the method with "where x is Bird" to be called. A Crow is not a Chicken, so we can rule out the Chicken method. But a Crow is also an Animal, so how does the dispatch decide that it calls the Bird method and not the Animal method? The answer of the authors of the predicate dispatch paper is that you determine implication between predicates. If x is a Bird, that implies that x is an Animal. So we test if x is a Bird and only after that we consider the Animal method. This is good but unfortunately checking implication between predicates is undecidable. For example if we define this: def bar(n) where 5^n == 5 mod n = A def bar(n) where prime?(n) = B How is the static analysis going to determine that the second predicate implies the first? You can solve this case by requiring the programmer to provide implication information to the compiler, like this: implication prime?(n) => 5^n == 5 mod n As you can see this isn't nice. In my opinion we need a better way to do method ordering. I've been thinking about this and my proposal is to use the definition order in the source code to decide which methods to check first: try methods that are defined last first. def baz(x) where p(x) = A def baz(x) where q(x) = B def baz(x) where r(x) = C We first check for r(x) and if it's true we execute C. If it's false then we check if q(x) is true and execute B. If q(x) is false we check p(x) and execute A. The implementation of this kind of predicate dispatch is trivial. You don't need a complicated implication checker. It's just a simple macro. But the question is whether this simple method ordering rule works in practice. With this order you can do everything that you can do with a class hierarchy (in Java for example). It also subsumes Clojure's hierarchies by using a predicate this is itself a method. I think it's interesting to explore this further to see if this order still works well for more advanced uses of predicate dispatch, and to explore alternative orderings. Some other research ideas: - Functional reactive programming in Clojure. A problem with FRP is that you have to invert dependencies. Instead of specifying for each cause what its effects are, you have to specify for each effects what its possible causes are. Can you solve this? The problem is much easier if you don't try to prevent glitches as other FRP systems do. Is a system without glitch prevention useful, is introducing glitches for removing cause and effect inversion a good trade off? - Type/value inference with abstract interpretation. Can you write an abstact interpretation to infer possible values of a variable? Is this useful in creating a better compiler. Can the information be used to create better editors (intellisense?). - In a statically typed language like Haskell & Scala you can write a generic sum function that sums a list of things. You cannot do this in any dynamic language that I know of. You want sum to work on any list of things that support +. Suppose that numbers support + and strings support + (maybe they shouldn't but bear with me for this example). sum ([1,2]) = 3. sum(["ab","cd"]) = "abcd". Now comes the problem. What is sum([])? For numbers it should be 0, for strings it should be "". In a statically typed language you can use the type of the list to determine which value to return. How can we write a generic sum function in a dynamic language? Jules On Dec 18, 1:35 pm, Patrick Kristiansen <patrick.kristian...@gmail.com> wrote: > Hi > > We're two students that have been working with concurrent programming > languages (Erlang and Clojure), and while both languages are very > interesting, we would like to work on something related to Clojure in > our masters thesis. > > I once asked on #clojure for ideas, and Rich Hickey suggested looking > into predicate dispatch and it is one idea that we are considering. We > have also considered working on distributed Clojure, but I don't know > if there is already an effort going on in that regard? > > Do you have any other suggestions? We'd be really thankful for any > suggestions. > > Thanks in advance. > > -Patrick -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
