Hi, Am 24.02.2009 um 16:03 schrieb Michel Salim:
I'd need to sit down sometimes and read both monad implementations. I was toying with it myself -- 'return' in particular is problematic as the type is "whatever the consuming expression wants". Rewriting is a cute hack, but definitely not elegant -- do you and Konrad have write-ups showing the evolution of your monad implementations? That would be interesting for programming language pedagogy.
Here a short summary (as far as I understand things). Konrad's version first used keywords to denote the monad operations like bind, return and friends. With defmonad a new monad is defined, which is basically a map containing the operations. Whenever one wants to use a monad, one has to use with-monad to provide the specific implementations. Previously this was done by replacing the keywords with the functions from the map before executing the code. Now the function are bound using a surrounding let. In my version the monads are a map carrying a type tag and the payload (whatever content you want in the monad). The monadic operations are defined as multimethods dispatching on the type tag. As you said: "return" is a problematic case, because Haskell gets the information for free from the type system. In Clojure one has to carry this information somehow. Also Disclaimer: I don't fully grok monadsyet. So there might even be conceptual mistakes in my implementation.....
Congratulations! Must be an exhilirating (and sleepless) time for the family.
Indeed. :) But also a very nice time! :D
That's perfectly reasonable. We'd probably want something that looks Fact-esque (James suggested forall as the syntax), built on top of test-is as far as possible. We can reuse the value generators from test-is.. there are, presumably, some features from ClojureCheck that would be nice to add to the mix as well?
Similar to James, I wanted a different way to report the test results. I'm a fan of the test anything protocol which is very wide spread in the Perl community. I tried to look into test-is, but back then the reporting and the testing was closely intertwined and it was hard to change the way things are reported. So I started out clojure-tap (which later changed to ClojureCheck). ClojureCheck consists of two parts. First the tests. The are implemented the is macro similar to test-is. But is immediately dispatches on the first of the given form using a multimethod where is from test-is does some other work before. The second part is the reporting. This is handled using a harness which is basically represented by *the-harness* Var and a set of multimethods. The standard simply prints TAP to *out*, suitable to be used with Perl's prove utility. This allows to easily change the way reporting is handled. The following thread contains some information I posted to the list. http://groups.google.com/group/clojure/browse_frm/thread/9b53d12a4ddb3fac/3853b227b4355e4d The "ClojureCheck" part itself is modelled closely to QuickCheckby implementing generators etc. This is still a construction site though.
There are quite a number of changes, which are still in the patch queue and not pushed to the public repo. From my perspective I'd like to see the a more flexible reporting in test-is. Although I must confess I didn't follow through all the changes. Maybe this is already obsolete. Sincerely Meikel
smime.p7s
Description: S/MIME cryptographic signature