This is a question about the expressiveness of Clojure vs other languages such as Haskell. The broader issue is solutions to the Expression Problem
This question reached the conclusion that in general Clojure protocols (and multimethods) were less expressive than Haskell typeclasses because protocols dispatched on first argument, and Haskell typeclasses could dispatch on return type. (Now I think this reasoning is really interesting, and have no interest in starting a language war. I'm just interested in clarity of thought).
As part of breaking this reasoning down - my question is - can't we make a Clojure multimethod that dispatches on return type (or type hint). I think we can put the following expression into a Clojure multimethod:
(= java.lang.String (:tag (meta #'my-string)))
where the function is:
(defn ^String my-string []
"hello world")
Edit: The point is that I can run:
(meta #'my-string)
and get the the following result without function evaluation:
{:arglists ([]), :ns #<Namespace push-price.core>, :name my-string, :column 1,
:line 1, :file "/private/var/folders/0l/x6hr0t1j2hvcmm_sqq04vdym0000gn/T/form-
init7576840885484540032.clj", :tag java.lang.String}
ie I have some information about the intended type of my function without evaluating it.
Edit 3 (24 Apr 2014):
Suppose I have the following types: (deftype string-type [])
(deftype int-type [])
Then I have the following functions defined in terms of these types:
(defn #^{:return-type string-type} return-string []
"I am returning a string")
(defn #^{:return-type int-type} return-int []
42)
Now I write a function to dispatch on their return type like so:
(defn return-type-dispatch [fn-arg]
(let [return-type (:return-type (meta fn-arg))]
(cond
(= return-type string-type)
"This function has a return type of the string type"
(= return-type int-type)
"This function has a return type of the integer type"
:else (str "This function has a return type of:" return-type))))
Then I write a macro to run it at compile-time
(defmacro compile-time-type-check-string []
(println (return-type-dispatch #'return-string)))
(compile-time-type-check-string)
Then I test it like so:
lein uberjar
This gives the following result:
$ lein uberjar
Compiling dispatch-type-compile-time.core
This function has a return type of:class dispatch_type_compile_time.core.string-type
...
So I appear to be dispatching on return type.
Let's imagine there were return type polymorphism in Clojure. That would allow us to write something like the Haskell class
class Default a where def :: a
In Haskell this works because it's a compile-time error to have a fragment like
def
as it's known to be ambiguous at compile time as to what that means. In a similar vein, if we were to write the Clojure fragment
(def)
it'd be impossible to know how to dispatch that call to the proper instance. To be more clear, the evaluation order for Clojure is that that in the fragment
(foo x y z)
the expressions x, y, and z get evaluated all prior to foo. In order for (def) to work it would need to somehow examine foo (and thus force its evaluation) in order to get information about how the return value of (def) will be used.
This could be done after a CPS transformation in which case (def) would be transformed into a function like (in Haskell type notation)
class Default a where def :: (a -> r) -> r
and now we see that we could examine the continuation function in order to learn information about the type of the parameter it expects and then dispatch off of that.
Finally, given enough macro magic this could be done... but likely for now less effort than implementing a Haskell-style type system atop Clojure. Typed Clojure could be a great model for this except it's been explicitly designed so that the semantics of Clojure cannot be affected by the inferred types. This is exactly what happens in return type polymorphism and so it's explicitly impossible in Typed Clojure.