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 monads
yet. 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 QuickCheck
by 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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to