"CLOS allows me to dispatch based on the types of all of the arguments."
But can it dispatch based on the return value?
But can it dispatch based on the return value?
Mind you - its 20 years since I was paid to write Lisp/CLOS so take this with a grain of salt :-)
http://stackoverflow.com/questions/22740178/clojure-dispatch...
(The Haskell purists point out that the dispatch isn't determined at compile time - form your own opinion about whether they have a point).
The return type isn't enforced, incidentally:
user> (defn ^String my-function [^Integer foo] (apply concat (repeat foo "x")))
#'user/my-function
user> (my-function 3)
(\x \x \x)
You also can't use the metadata on a function introduced by (defn ^ReturnType ...) in more or less any useful way, if you don't have a reference to the var itself. If you pass it to a function, you basically can't recover it:
user> (defn do-something-interesting-with-return-type [f] (println "here's my metadata:" (meta f)))
#'user/do-something-interesting-with-return-type
user> (do-something-interesting-with-return-type my-function)
here's my metadata: nil
nil
You can tell that something fishy is going on in the SO answer because the author has to pass in the function by name, #'return-string.
Are there examples where this actually leads to clearer code in the wild?
The bounds of a bounded type:
minBound :: Bounded a => a
maxBound :: Bounded a => a
toEnum :: Enum a => Int -> a
fromIntegral :: (Integral a, Num b) -> a -> b
read :: Read a => String -> a
mempty :: Monoid m => m
return :: Monad m => a -> m a
mconcat :: Monoid m => [m] -> m
mconcat = foldr mappend mempty
mconcat [Just "foo", Nothing, Nothing, Just "bar"]
=
Just "foobar" name :: constraints_for_type => type_of_name
So,
minBound :: Bounded a => a
maxBound :: Bounded a => a
These two are more values than functions, but the polymorphism happens the same way. If you use them where some particular bounded type is expected, that's the type they evaluate to. If you use them where an unbounded type is expected, you'll get a compile error.
----
toEnum :: Enum a => Int -> a
i.e., Convert an int to the Enum type that the context is asking for.
----
fromIntegral :: (Integral a, Num b) => a -> b
The tuple syntax just means that all these constraints need to apply. I'm not actually certain why the syntax requires it.
----
read :: Read a => String -> a
----
mempty :: Monoid m => m
This is particularly interesting when you start doing polymorphic things with fold and friends.
----
return :: Monad m => a -> m a
Here we see a "higher-kinded type" - m is a function at the type level that takes a type argument and produces another type, like a C++ template.
e.g. List parameterized by Integer gives us a List of Integers (List is spelled [] in Haskell)
----
mconcat :: Monoid m => [m] -> m
mconcat = foldr mappend mempty
I am curious on minBound and maxBound. They seem to be the same... What distinguishes them? Or, you are just saying these are two values that are defined. And they can only be given a value of a type that can be bounded?
Also, thanks for expanding!
So the Bounded typeclass is defined as
class Bounded a where
minBound :: a
maxBound :: a
allLessThan :: (Enum a, Bounded a)=> a -> [a]
allLessThan x = [minBound..x]
To implement the typeclass you use `instance`, like so:
data MyType = A | B | C | D
instance Bounded MyType where
minBound = A
maxBound = DSo in the case of minBound and maxBound in particular, you'd define them appropriately for a particular type when you declare a type to be Bounded.
trait Bounded {
fn min_bound() -> Self;
fn max_bound() -> Self;
}
fn add_min_to_set<T:Bounded, S:MutableSet<T>>(set: &mut S) {
set.insert(Bounded::min_bound())
}
let mut i: u8 = Bounded::min_bound();
while i < Bounded::max_bound() { println!("{}", i); i += 1; }
Can you explain this with an example of what the syntax would look like, along with a description of the fantasy semantics?
Of course if a specializable argument to a CLOS generic function call is itself a function call expression, then it is evaluated to its return value, and the type of that value is dispatched on.
The return value of the generic function itself doesn't dispatch anywhere; return "dispatches" to the caller.
We can think about dispatching a different method based on some type which the caller expects. A way to do it in CLOS is to add an extra parameter, perhaps a class symbol. CLOS can dispatch on symbols via the (eql ...) specialization, so we can do something like (foo 'integer arg) to call that specialization of foo which returns integers. This won't be deduced from context; evaluation of a form is context free in ordinary Lisp. Doing that sort of thing requires a code walker to transform the program.
(Not sure why I got a downvote. Is there a possible perception that I wasn't being civil?)
It occurs to me that some dynamic dispatch can take place based on what the method call returns. Suppose we split the computation of the function into two functions: the function proper, and a fixup which is applied to the return value.
The main function's method could have a CLOS :around method wrapped around it which obtains the return value of the primary method (via en explicit (call-next-method) call, and then invokes the fixup method on the argument. The fixup method is then dynamically dispatched on this return value, and possibly provides the ultimate return value.
Of course, this is different from dispatching a method based on the context in which it occurs. Still, no time machine needed.
Splitting functions is an interesting idea, though unless you're passing in context as an argument it'd be another way of dispatching on the same arguments (with, presumably, more user control but probably also more boiler plate).
By the way, it appears I can explain why I had used the word "fantasy": I have been recently involved in some discussions about Gödel's Incompleteness Theorem. That stirred up distant memories of reading Hofstadter, dredging up some of his vocabulary.