I write a unit testing framework in every new language I learn. I find it's a great workout because making it usable for yourself is immediately assessable, and it often forces you into deeper areas of the language, including reflection and meta-programming.
You might want to have a look at QuickCheck. Trying to port it's techniques to other languages will also give you some insight (and will result in valuable tools).
And make you miss the ability to overload functions just on return type. Same thing happens if you use Haskell's regex library or try t port monads to another language.
Indeed. Overloading on return type is one of the few things that you can't do in dynamic languages by design (and in most statically typed ones, neither, but that's an accident).
Please do! It's very interesting; I'm not good enough in PLT to try and find out the answer for myself (in such a short amount of free time I have lately) but I'm very curious if it's true that you cannot have overloading on return type in unityped languages by principle.
This is not hard to understand: under usual semantics for function calls it is clearly impossible to do return type overloading in a dynamically typed language. But, as I pointed out above, it is perfectly practical to cheat and provide an indication of the desired return type as an extra hidden argument to every function call (this is what Perl does with wantarray: it is a "builtin function" but the effect is really that of an extra boolean parameter to every function call that specifies whether the result should be an array or not).
Ok, this much I understand, but I wouldn't call this overloading on return type... It's - clearly - overloading on input type, either implicit (wantarray - I checked the docs, it seems to be a variable set automaticaly depending on context by the interpreter) or explicit, but input type nevertheless.
So, the short answer is - as I thought previously - that no, you can't have implicit dispatch on return type in dynamically typed language.
Contracts are probably getting close, but you still need a version of apply that will get expected return type and a bunch of functions to introspect (or a macro that would do the same, but let's not wander there, as lispy macro systems are equivalent with static type systems anyway).
And you can generalize from wantarray's Boolean to a more general parameter indicating required return type.
It gets harder and harder though, to provide information about more and more distant parts of the program in a dynamically typed (or untyped) environment.
From what I've heard, Racket's contract system is another interesting attempt to provide something that's typically done in a static setting---the benefits of dependent typing---in a dynamic one.
