Re: Monads and Middleware
Functions are a type of monad, and function composition is a type of monadic binding. You could certainly say that middleware are a type of monad, but so many things can be thought of as monads that's not hugely useful in and of itself. - James On 1 July 2016 at 18:14, Scott Klarenbach wrote: > I'm looking for some insight into the relationship between Monads and > Middleware. > > It seems to me that middleware (ala Ring, Boot) is really just a subset of > Monads, where bind and lift are globally agreed upon conventions, rather > than explicitly defined. For example, with middleware you need every > function to accept and return the same signature so as to be composable, > whereas with monads you explicitly provide the code for binding and lifting > into and out of the monad world. > > My basic questions are: > > 1.) Is middleware really a monad with a different name? > 2.) Is there any compelling reason to use monads in clojure instead of > middleware? > 3.) Are there classes of problems that can be solved with monads that > can't be solved with middleware? > 4.) Is there any benefit (beyond curiosity) to porting/re-implementing > middleware as monads? > > Thanks. > > Scott Klarenbach > www.invisiblerobot.io > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: monads not working in Clojure 1.4.0
Thanks Michael. On Saturday, November 9, 2013 10:26:09 AM UTC-8, Michael Klishin wrote: > > 2013/11/9 Gary Zhao > > >> NoSuchMethodError >> clojure.lang.RT.mapUniqueKeys([Ljava/lang/Object;)Lclojure/lang/IPersistentMap; >> >> clojure.algo.monads/loading--4910--auto-- (monads.clj:11) >> > It means you have some code compiled against 1.5.1 in monads, one of the > other libraries or your own code. > > Run lein clean and try again. > -- > MK > > http://github.com/michaelklishin > http://twitter.com/michaelklishin > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: monads not working in Clojure 1.4.0
2013/11/9 Gary Zhao > NoSuchMethodError > clojure.lang.RT.mapUniqueKeys([Ljava/lang/Object;)Lclojure/lang/IPersistentMap; > clojure.algo.monads/loading--4910--auto-- (monads.clj:11) > It means you have some code compiled against 1.5.1 in monads, one of the other libraries or your own code. Run lein clean and try again. -- MK http://github.com/michaelklishin http://twitter.com/michaelklishin -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Monads usage
Last week I released a project with a monadic translator that needed to: - work on sequences of expressions, arbitrarily nested - generate Clojure code or stop and report the first error - maintain a symbol table with easy access but not global state The relevant code is here: https://github.com/blancas/eisen/blob/master/src/main/clojure/blancas/eisen/trans.clj The code uses a StateT monad transformer and Either monad wrapped in five API functions: ->left, ->right, get-se, modify-se, run-se. Functions report errors with (->left); function (->right) wraps good values. The macro (monad) corresponds to Haskell's do; it chains monadic values or short-circuits and propagates errors. (defn trans-binop "Translates the application of a binary operator." [ast] (monad [x (trans-expr (:left ast)) y (trans-expr (:right ast))] (let [f (-> ast :op :value str symbol)] (->right `(~f ~x ~y) The symbol table is available through get-se and modify-se. A typical use case is to enter declared names, translate the expressions, then remove the names from the symbol table. (defn trans-let "Translates a let expression." [{:keys [decls exprs]}] (let [env (map (comp symbol :name) decls)] (monad [_ (modify-se into env) decls (trans-bindings decls) exprs (trans-exprs exprs) _ (modify-se difference env)] (->right `(let [~@(apply concat decls)] ~@exprs) To translate expressions in a sequence it uses the generic function (seqm); function (run-se) evaluates the resulting sequenced monads using an initial state "predefs". The result from (run-se) feeds (either) which evaluates to the first form on ->left and to the second on ->right. (let [job (monad [v (seqm (map eval-ast coll))] (->right v))] (either [res (run-se job predefs)] {:ok false :error res} {:ok true :decls (map first res) :value (-> res last second)}))) On Monday, April 8, 2013 7:56:35 AM UTC-7, Carlos Galdino wrote: > > Hi, > > I've been reading about monads for the past couple of weeks and I think I > got the idea, but I still don't know when to use it since I don't have > enough experience with functional programming. > > So, I'd like to ask you guys if you can point me to some examples of > Monads usage "in the wild". Because I've seen a lot of simple examples but > not a real one, used in a library, etc. > > Does anyone know a good example of real world usage? > > Thanks in advance. > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Monads usage
I don't know if this is adequately "in the wild" (since it's part of a monad lib itself), but part of my monads library uses a continuation monad to let two mutually recursive functions traverse and rebuild a tree structure without blowing the stack. It would be a pain to do this kind of thing by hand, since (unlike in the typical even/odd example where the built-in trampoline function is simple to use) the recursive calls aren't naturally written as tail calls. The use of a continuation monad effectively results in the functions' being rewritten in CPS, and the implementation does the trampolining for you: https://github.com/bwo/monads/blob/master/src/monads/cont.clj#L62 -- (declare reorg-binds) (defn- reorg-plus [m] (if-instance Mplus m (let [l (.l m) r (.r m)] (mdo li <- (reorg-binds l) ri <- (reorg-binds r) ri <- (if-instance Mplus ri (let [lr (.l ri)] (if-instance Mplus lr (reorg-plus ri) (return ri))) (return ri)) (if-instance Mplus li (let [l-l (.l li)] (mdo ri <- (reorg-plus ri) (reorg-plus (Mplus. l-l (Mplus. (.r li) ri) (return (Mplus. li ri) (return m))) (defn- reorg-binds [m] (if-instance Bind m (let [comp (.comp m)] (if-instance Bind comp (let [i-comp (.comp comp) i-f (.f comp) f (.f m)] (mdo i <- (reorg-plus i-comp) (reorg-binds (Bind. i (fn [x] (Bind. (i-f x) f)) (mdo comp <- (reorg-plus comp) (return (Bind. comp (.f m)) (return m))) (defn reorganize "Reorganize the monadic computation m so that binds nested on the left are moved to the right, i.e. transform expressions like (>>= (>>= (>>= m f) g) h) into expressions like (>>= m (fn [x] (>>= (f x) (fn [y] (>>= (g y) h). A monad implementation for which these two expressions give different results is broken. Similarly reorganizes mplus operations nested on the left: (mplus (mplus (mplus a b) c) d) Becomes (mplus a (mplus b (mplus c d))). And, similarly, an mplus operation which is not associative is considered to be in error. Both transformations are interleaved: (mplus (mplus (>>= (>>= (mplus (mplus a b) c) f) g) d) e) becomes (mplus (>>= (mplus a (mplus b c)) (fn [x] (>>= (f x) g))) (mplus d e)). Note that *only* mplus and bind operations are investigated: the reorganization does not recurse into the monadic-computation arguments of e.g. listen, local, or pass." [m] ;; this reorg-plus is here in case we fall through reorg-binds right ;; away. We can't call reorg-plus in reorg-binds in the else branch ;; of the first if-instance, because it can lead to, yes, stack ;; overflows. (run-cont (reorg-plus (run-cont (reorg-binds m) -- On Mon, Apr 8, 2013 at 7:56 AM, Carlos Galdino wrote: > Hi, > > I've been reading about monads for the past couple of weeks and I think I > got the idea, but I still don't know when to use it since I don't have > enough experience with functional programming. > > So, I'd like to ask you guys if you can point me to some examples of > Monads usage "in the wild". Because I've seen a lot of simple examples but > not a real one, used in a library, etc. > > Does anyone know a good example of real world usage? > > Thanks in advance. > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- Ben Wolfson "Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure." [Larousse, "Drink" entry] -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/gr
Re: Monads usage
oops, gen-plan was missing a helper function: (defn- with-bind [id expr psym body] `(fn [~psym] (let [[~id ~psym] ( ~expr ~psym)] (assert ~psym "Nil plan") ~body))) On Mon, Apr 8, 2013 at 9:32 AM, Timothy Baldridge wrote: > I have a love/hate relationship with monads. I think their use in Clojure > programming is much more limited than most would like to admit. > > However, I have found a very nice use for them: in my case, I'm attempting > to insert a very complex AST into Datomic. I'd like all my data to go into > Datomic as one large transaction (a vector of hashmaps). My first attempt > at this code looked like this: > > Assume my data is: > > {:type :+ > :arg0 {:type :const > :value 1} > :arg1 {:type :const > :value 2} > > > Insert for the + node: > > (let [[arg0-id with-arg0] (insert-node (:arg0 this) plan) > [arg1-id with-arg1] (insert-node (:arg1 this) with-arg1) > [this-id with-this] (assert-entity {:arg0 arg0-id :arg1 arg1-od})] > [this-id with-this]) > > So basically every single function has to return the last inserted id as > well as a db tx plan that contains all items that need to be inserted. Not > only is this code ugly, but I found it very error prone. Sometimes I would > pass the wrong plan name in, and things would break. So I looked at this > and said "why not use the state monad". So now insert-node looks like this: > > (insert-node [ent] > (fn [plan] > . do stuff . > [ent plan])) > > > I created a monad binding function called "gen-plan": > > (defmacro gen-plan [binds id-expr] > (let [binds (partition 2 binds) > psym (gensym "plan_") > f (reduce >(fn [acc [id expr]] > `(~(with-bind id expr psym acc) >~psym)) >`[~id-expr ~psym] >(reverse binds))] > `(fn [~psym] >~f))) > > And our example above looks like this: > > (gen-plan > [arg0-id (insert-node (:arg0 this)) >arg1-id (insert-node (:arg1 this)) >this-id (assert-entity {:arg0 arg0-id :arg1 arg1-id})] > this-id) > > Notice how the state monad makes the plan implicit. > > And now I can write super complex functions like this, without drowning in > the code. Notice how this block (which generates a tx for writing a SSA > style if expression to Datomic) is clear from any mentions of explicit > state, but yet is remains completely functional. > > (gen-plan > [fnc (get-in-plan [:state :fn]) > > test-id (write-ssa test) > test-block (get-block) > > pre-then-block (add-block fnc) > _ (set-block pre-then-block) > then-val (write-ssa then) > post-then-block (get-block) > then-terminated? (terminated? post-then-block) > > pre-else-block (add-block fnc) > _ (set-block pre-else-block) > else-val (write-ssa else) > post-else-block (get-block) > else-terminated? (terminated? post-else-block) > > merge-block (add-block fnc) > _ (set-block merge-block) > phi-val (add-phi) > > _ (set-block test-block) > br-id (terminate-block :inst.type/br test-id pre-then-block > pre-else-block) > > _ (if then-terminated? > (no-op) > (gen-plan >[_ (set-block post-then-block) > _ (terminate-block :inst.type/jmp merge-block) > _ (add-to-phi phi-val post-then-block then-val)] >nil)) > > _ (if else-terminated? > (no-op) > (gen-plan >[_ (set-block post-else-block) > _ (terminate-block :inst.type/jmp merge-block) > _ (add-to-phi phi-val post-else-block else-val)] >nil)) > > _ (set-block merge-block)] > phi-val) > > > > So I look at this way, I see monads as a purely academic exercise 90% of > the time. To try to go "whole hog" and apply them to every problem at hand > is just nonsense. However, there are times (like in this example) where > monads end up being the perfect tool for the job at hand. So I say, instead > of looking at a problem and saying "what monad is this?" Instead, look at > ugly code and say "hrm...I wonder if programming method X could make this > cleaner". If that method is a monad, awesome! > > Timothy > > > > On Mon, Apr 8, 2013 at 8:56 AM, Carlos Galdino > wrote: > >> Hi, >> >> I've been reading about monads for the past couple of weeks and I think I >> got the idea, but I still don't know when to use it since I don't have >> enough experience with functional programming. >> >> So, I'd like to ask you guys if you can point me to some examples of >> Monads usage "in the wild". Because I've seen a lot of simple examples but >> not a real one, used in a library, etc. >> >> Does anyone know a good example of real world usage? >> >> Thanks in advance. >> >> -- >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure
Re: Monads usage
I have a love/hate relationship with monads. I think their use in Clojure programming is much more limited than most would like to admit. However, I have found a very nice use for them: in my case, I'm attempting to insert a very complex AST into Datomic. I'd like all my data to go into Datomic as one large transaction (a vector of hashmaps). My first attempt at this code looked like this: Assume my data is: {:type :+ :arg0 {:type :const :value 1} :arg1 {:type :const :value 2} Insert for the + node: (let [[arg0-id with-arg0] (insert-node (:arg0 this) plan) [arg1-id with-arg1] (insert-node (:arg1 this) with-arg1) [this-id with-this] (assert-entity {:arg0 arg0-id :arg1 arg1-od})] [this-id with-this]) So basically every single function has to return the last inserted id as well as a db tx plan that contains all items that need to be inserted. Not only is this code ugly, but I found it very error prone. Sometimes I would pass the wrong plan name in, and things would break. So I looked at this and said "why not use the state monad". So now insert-node looks like this: (insert-node [ent] (fn [plan] . do stuff . [ent plan])) I created a monad binding function called "gen-plan": (defmacro gen-plan [binds id-expr] (let [binds (partition 2 binds) psym (gensym "plan_") f (reduce (fn [acc [id expr]] `(~(with-bind id expr psym acc) ~psym)) `[~id-expr ~psym] (reverse binds))] `(fn [~psym] ~f))) And our example above looks like this: (gen-plan [arg0-id (insert-node (:arg0 this)) arg1-id (insert-node (:arg1 this)) this-id (assert-entity {:arg0 arg0-id :arg1 arg1-id})] this-id) Notice how the state monad makes the plan implicit. And now I can write super complex functions like this, without drowning in the code. Notice how this block (which generates a tx for writing a SSA style if expression to Datomic) is clear from any mentions of explicit state, but yet is remains completely functional. (gen-plan [fnc (get-in-plan [:state :fn]) test-id (write-ssa test) test-block (get-block) pre-then-block (add-block fnc) _ (set-block pre-then-block) then-val (write-ssa then) post-then-block (get-block) then-terminated? (terminated? post-then-block) pre-else-block (add-block fnc) _ (set-block pre-else-block) else-val (write-ssa else) post-else-block (get-block) else-terminated? (terminated? post-else-block) merge-block (add-block fnc) _ (set-block merge-block) phi-val (add-phi) _ (set-block test-block) br-id (terminate-block :inst.type/br test-id pre-then-block pre-else-block) _ (if then-terminated? (no-op) (gen-plan [_ (set-block post-then-block) _ (terminate-block :inst.type/jmp merge-block) _ (add-to-phi phi-val post-then-block then-val)] nil)) _ (if else-terminated? (no-op) (gen-plan [_ (set-block post-else-block) _ (terminate-block :inst.type/jmp merge-block) _ (add-to-phi phi-val post-else-block else-val)] nil)) _ (set-block merge-block)] phi-val) So I look at this way, I see monads as a purely academic exercise 90% of the time. To try to go "whole hog" and apply them to every problem at hand is just nonsense. However, there are times (like in this example) where monads end up being the perfect tool for the job at hand. So I say, instead of looking at a problem and saying "what monad is this?" Instead, look at ugly code and say "hrm...I wonder if programming method X could make this cleaner". If that method is a monad, awesome! Timothy On Mon, Apr 8, 2013 at 8:56 AM, Carlos Galdino wrote: > Hi, > > I've been reading about monads for the past couple of weeks and I think I > got the idea, but I still don't know when to use it since I don't have > enough experience with functional programming. > > So, I'd like to ask you guys if you can point me to some examples of > Monads usage "in the wild". Because I've seen a lot of simple examples but > not a real one, used in a library, etc. > > Does anyone know a good example of real world usage? > > Thanks in advance. > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr.
Re: monads
In a few lines: Monads are a common framework to represent any sequential computation. What is a sequential computation? - either no computation at all. return :: a -> m a does that. - or I have already a computation and want to go on with my computation. But then, I need to be able to look at the result of the first part of the computation to now what to do next: bind :: m a -> (a -> m b) -> m b This tells: If I have a computation returning a value of type a, and when I will know a, I will be able to create a computation returning some b, then I can sequence those and make a computation returning some b. When I want to run it, I will run the first and use the result to construct the second and then run it. * What is interesting is that you have a representation of sequential computations and can use a common libraries of functions to work with any kind of sequential things. And there are a lot of things that corresponds to this: side-effects, logic programming, parsing... Nicolas. * The monadic notion of sequential computation allows to look at intermediate results to determine what to do next. You obtain other notion of computations like Arrows or Applicative functors if you restrict this right. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: monads
On Friday, October 26, 2012 11:06:59 AM UTC-5, Brian Craft wrote: > I've read about four tutorials on monads so far, but it still escapes me. > > In fact, I'm still not sure what problem it solves. I'm familiar with the > problem of having, say, three functions like f(a) -> b, g(c) -> d, h(e) -> > f, which you'd like to chain like f(g(h(x))), but you can't because b is a > different type from c and d is a different type from e. The monad tutorials > all start with a problem like this, but I still can't tell if they're > actually providing a solution, because it appears every monad is specific > to a particular type. E.g. a sequence monad. So, great, I have something > that takes a scalar and returns a sequence. That might solve g(h(x)) if f > is a scalar and c is a sequence by letting me write g(s(h(x))), but it > doesn't solve the whole problem, since I still have f() to worry about. > > > Brian, you may have looked at it already, but I found Konrad Hinsen's 4-part tutorial linked from the README in Clojure's algo.monads repository to be quite helpful: https://github.com/clojure/algo.monads By the way, the links in that README to Jim Duey's tutorials are broken; here is the correct link to Part 1 of Jim's tutorials: http://www.intensivesystems.net/tutorials/monads_101.html I read Jim's tutorials first, and then tried Konrad's. I found the latter a bit more helpful. Also, Konrad's explanation of the state monad in Part 3 really "clicked" with me, so I felt it was worth working through Parts 1 and 2, even though I was still scratching my head a bit when I finished Part 2. Jim also has a more recent set of blog posts dedicated to exploring monads: http://www.clojure.net/archive.html I worked from the bottom of that list to the top, after reading the other tutorials, and came away with a basic but sound understanding of the core concepts: m-result, m-bind, the Monad Laws, etc. Also note that Jim has developed a new monads library for Clojure, implemented with protocols: https://github.com/jduey/protocol-monads Working through that library's test suite seems like a good way improve one's understanding of monads; also, I'm going to try to "port" the examples from algo.monads over to protocol-monads. I haven't done that yet, but when I do you will be able to find them in my fork of protocol-monads (if things go well, I'll submit a pull request): https://github.com/michaelsbradleyjr/protocol-monads/blob/examples/src/examples/monads.clj The original examples for algo.monads: https://github.com/clojure/algo.monads/blob/master/src/examples/clojure/examples/monads.clj -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: monads
I found these articles very valuable in understanding the original motivation for monads and their use for practical development. Imperative Functional Programming Simon Peyton Jones, Philip Wadler http://research.microsoft.com/pubs/67066/imperative.ps.z Monadic Parser Combinators Graham Hutton http://eprints.nottingham.ac.uk/237/1/monparsing.pdf On Friday, October 26, 2012 9:06:59 AM UTC-7, Brian Craft wrote: > > I've read about four tutorials on monads so far, but it still escapes me. > > In fact, I'm still not sure what problem it solves. I'm familiar with the > problem of having, say, three functions like f(a) -> b, g(c) -> d, h(e) -> > f, which you'd like to chain like f(g(h(x))), but you can't because b is a > different type from c and d is a different type from e. The monad tutorials > all start with a problem like this, but I still can't tell if they're > actually providing a solution, because it appears every monad is specific > to a particular type. E.g. a sequence monad. So, great, I have something > that takes a scalar and returns a sequence. That might solve g(h(x)) if f > is a scalar and c is a sequence by letting me write g(s(h(x))), but it > doesn't solve the whole problem, since I still have f() to worry about. > > So, two specific questions. First, do monads provide a generic solution, > so I can apply f(g(h(x)))? Second, is it the whole point of monads to use > macros so you don't see the glue functions, like s(), in my example? I > mean, we can always write glue functions so we can compose functions with > different input/output types without using monads. What exactly are monads > adding? > > Oh, and one more. If I were to actually use a monad in a piece of > production code, what are the chances that the next person working on the > code would have the faintest idea how it worked? ;-p > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: monads
On Fri, 2012-10-26 at 21:55 -0700, Ben Wolfson wrote: > f :: a -> b > g :: c -> d > h :: e -> j [renamed from "f"] > > and "you'd like to chain [them] like f(g(h(x))), but you can't because > b is a different type from c and d is a different type from e.", how > does m-chain help? > > I would have expected, given the "b is a different type from c" thing, > that the chaining would go h(g(f(x)), but it's not as if that helps, > unless the types work out like: > > b ~ m c > d ~ m e I assume that Brian's original example involved such constraints, implicitly; i.e., a, b, c, d, e are metasyntactic variables in prose referring to values, not type variables. -- Stephen Compall "^aCollection allSatisfy: [:each | aCondition]": less is better than -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: monads
On Fri, Oct 26, 2012 at 8:39 PM, Stephen Compall wrote: > On Fri, 2012-10-26 at 09:06 -0700, Brian Craft wrote: >> First, do monads provide a generic solution, so I can apply >> f(g(h(x)))? > > Yes. control.algo.monads provides it as m-chain. Can you expand on this? If the functions are f :: a -> b g :: c -> d h :: e -> j [renamed from "f"] and "you'd like to chain [them] like f(g(h(x))), but you can't because b is a different type from c and d is a different type from e.", how does m-chain help? I would have expected, given the "b is a different type from c" thing, that the chaining would go h(g(f(x)), but it's not as if that helps, unless the types work out like: b ~ m c d ~ m e in which case f >=> g >=> h :: a -> j works fine (assuming j is a monadic value). But as a general matter I don't see how monadic composition solves the problem. -- Ben Wolfson "Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure." [Larousse, "Drink" entry] -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: monads
On Fri, 2012-10-26 at 09:06 -0700, Brian Craft wrote: > First, do monads provide a generic solution, so I can apply > f(g(h(x)))? Yes. control.algo.monads provides it as m-chain. The closest equivalent to m-chain in Haskell is (foldl' (>=>) return), but in most situations you would favor f =<< g =<< h x for your example, or more compositionally (f <=< g <=< h) x. > Second, is it the whole point of monads to use macros so you don't see > the glue functions, like s(), in my example? I mean, we can always > write glue functions so we can compose functions with different > input/output types without using monads. We can always write things out explicitly instead of exploiting existing abstractions. As for macros, the above samples use ordinary Haskell function calls. -- Stephen Compall "^aCollection allSatisfy: [:each | aCondition]": less is better than -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: monads
On Oct 26, 2012, at 11:06 AM, Brian Craft wrote: > I've read about four tutorials on monads so far, but it still escapes me. > > In fact, I'm still not sure what problem it solves. Monads are hard to understand, and I too found I wasn't the target audience for the explanations I read. I finally had to write my own as a way to force me to understand. Advertisement: the explanation is in chapter 10 and the optional chapters 15 and 16 of my book. (URL in my signature.) People seem to like mine because I start with the implementation, not the abstract ideas. Also, I lie when necessary on the way to the complete explanation. The problem monads solve is twofold: 1. Suppose you have a series of computational steps. The results of those steps have to be combined in some way. A monad lets you move the combination rules away from the steps, so that you don't have to look at them. You just look at the steps and keep the rules in the back of your mind. That reduces code clutter. 2. Often, the rules are more general purpose than the steps. For example, it's common to want to break out of a series of steps when an error happens. Rather than scattering `if`s between some steps, you can point the Error monad at them. (When is that better than just using try/catch? -- that's still an open question to me.) That said, the *really* general-purpose monads tend to get written into the language as special forms. Clojure's `let` and `for` are both monads, but you don't need to know that to use them. One thing that's important to realize about monads is that they apply the *same* rule to every step. That seems to make them clunky when you're working on problems that aren't nicely structured. But for certain structured problems, especially ones that lend themselves to combinations of predefined rules that apply to every step, monads are just The Right Thing. Even if you don't use them, I'm inclined to think monads are a useful example of how to think about functions in a functional language. It helps you avoid just writing C code in Clojure. - Brian Marick, Artisanal Labrador Contract programming in Ruby and Clojure Occasional consulting on Agile Writing /Functional Programming for the Object-Oriented Programmer/: https://leanpub.com/fp-oo -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: monads
I can't say I grok monads completely yet, but was one of the tutorials you read this one? http://blog.sigfpe.com/2006/08/you-could-have-invented-monads-and.html I like the style of showing how they solve problems that arise naturally in the context of purely functional programming, with several examples of those kinds of problems. Andy On Oct 26, 2012, at 9:06 AM, Brian Craft wrote: > I've read about four tutorials on monads so far, but it still escapes me. > > In fact, I'm still not sure what problem it solves. I'm familiar with the > problem of having, say, three functions like f(a) -> b, g(c) -> d, h(e) -> f, > which you'd like to chain like f(g(h(x))), but you can't because b is a > different type from c and d is a different type from e. The monad tutorials > all start with a problem like this, but I still can't tell if they're > actually providing a solution, because it appears every monad is specific to > a particular type. E.g. a sequence monad. So, great, I have something that > takes a scalar and returns a sequence. That might solve g(h(x)) if f is a > scalar and c is a sequence by letting me write g(s(h(x))), but it doesn't > solve the whole problem, since I still have f() to worry about. > > So, two specific questions. First, do monads provide a generic solution, so I > can apply f(g(h(x)))? Second, is it the whole point of monads to use macros > so you don't see the glue functions, like s(), in my example? I mean, we can > always write glue functions so we can compose functions with different > input/output types without using monads. What exactly are monads adding? > > Oh, and one more. If I were to actually use a monad in a piece of production > code, what are the chances that the next person working on the code would > have the faintest idea how it worked? ;-p -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: monads > macros
On Wed, Jul 13, 2011 at 1:37 PM, Raoul Duke wrote: > On Wed, Jul 13, 2011 at 5:20 AM, Ken Wesson wrote: >> Oh, I'm not saying my own is exploding -- just that macros can be >> tough for some people to get their heads around, and monads even more >> so, so combining the two ... > > maybe call them something else and it won't be so bad. when people see > the need for something, they are generally willing to pursue it and > learn it, i think. the people using clojure are probably somewhat > self-selectingly smart enough ;-) as long as you don't call them > monads ha ha. I'd probably be more insulted by being called macro. -- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: monads > macros
On Wed, Jul 13, 2011 at 5:20 AM, Ken Wesson wrote: > Oh, I'm not saying my own is exploding -- just that macros can be > tough for some people to get their heads around, and monads even more > so, so combining the two ... maybe call them something else and it won't be so bad. when people see the need for something, they are generally willing to pursue it and learn it, i think. the people using clojure are probably somewhat self-selectingly smart enough ;-) as long as you don't call them monads ha ha. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: monads > macros
On Wed, Jul 13, 2011 at 7:19 AM, Konrad Hinsen wrote: > On 13 Jul 2011, at 05:04, Ken Wesson wrote: > >>> One approach that has been proposed to improve composability of macros is >>> to >>> adopt a continuation-passing style. This would make macros a candidate >>> for >>> the continuation monad, so perhaps monads may be of use in implementing >>> complex macros. >> >> That popcorn-popping sound you hear is heads exploding out there in >> the audience. > > Maybe this article will help understand what I was referring to - noting > that this is for Scheme and not Clojure: > > http://okmij.org/ftp/papers/CPS-Macros.ps.gz Oh, I'm not saying my own is exploding -- just that macros can be tough for some people to get their heads around, and monads even more so, so combining the two ... -- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: monads > macros
On 13 Jul 2011, at 05:04, Ken Wesson wrote: One approach that has been proposed to improve composability of macros is to adopt a continuation-passing style. This would make macros a candidate for the continuation monad, so perhaps monads may be of use in implementing complex macros. That popcorn-popping sound you hear is heads exploding out there in the audience. Maybe this article will help understand what I was referring to - noting that this is for Scheme and not Clojure: http://okmij.org/ftp/papers/CPS-Macros.ps.gz Konrad. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: monads > macros
On 12 Jul 2011, at 23:18, Alan Malloy wrote: On Jul 12, 12:01 pm, Konrad Hinsen wrote: The composability issue with macros lies in writing them, not using them. Strongly disagree. Macros compose reasonably well when writing them (eg, using let in the implementation of with-open is trivial); it's That's not composition, that's use. What I mean by composition is writing a complex macro in terms of simpler macros and macro composers, just as one writes complex functions in terms of simple functions and higher-order functions. There is no equivalent of higher- order functions in the macro universe, for example. composing already-written macros with other pieces of your codebase that's hard. (reduce and xs) won't test that every element of xs is truthy, because and is a macro and thus can't be used as a higher- order function. That's exactly the kind of problem I was thinking of. So in fact we agree, except for the label to put on the problem. Konrad. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: monads > macros
On Tue, Jul 12, 2011 at 3:01 PM, Konrad Hinsen wrote: > On 12 Jul 2011, at 15:40, James Keats wrote: > >> My humble understanding is that macros complicate composability, >> whereas monads facilitate it. > > The composability issue with macros lies in writing them, not using them. > Monads are all about composing computations with specific properties, where > the monad abstracts away those properties. But I don't see any common point > between macros and monads other than that both words start with 'm'. Well, they *do* also have a total of five letters, including an 'a' and and an 'o' as well as two consonants besides the initial 'm'. Oh, and the second letter is a vowel in both cases. I think maybe Haskell also relies on monads for some of the things where a Lisp traditionally relies on macros, such as implementing control structures -- Haskell has lazy function arguments, and it's already clear from sequence-m and maybe-m that monads can implement some kinds of conditionals and loops and even a form of exception handling. > One approach that has been proposed to improve composability of macros is to > adopt a continuation-passing style. This would make macros a candidate for > the continuation monad, so perhaps monads may be of use in implementing > complex macros. That popcorn-popping sound you hear is heads exploding out there in the audience. -- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: monads > macros
On Jul 12, 12:01 pm, Konrad Hinsen wrote: > The composability issue with macros lies in writing them, not using them. Strongly disagree. Macros compose reasonably well when writing them (eg, using let in the implementation of with-open is trivial); it's composing already-written macros with other pieces of your codebase that's hard. (reduce and xs) won't test that every element of xs is truthy, because and is a macro and thus can't be used as a higher- order function. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: monads > macros
On Jul 12, 9:28 am, James Keats wrote: > I'm mildly concerned about macros being seen as the "secret weapon" of > clojure(/lisp). > In their place, i wish monads would get a wider attention and embrace. > > Discuss? :-) What is your concern, specifically? I don't see a position being articulated. Can you cite the relevant literature on type theory and macros? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: monads > macros
On 12 Jul 2011, at 15:40, James Keats wrote: My humble understanding is that macros complicate composability, whereas monads facilitate it. The composability issue with macros lies in writing them, not using them. Monads are all about composing computations with specific properties, where the monad abstracts away those properties. But I don't see any common point between macros and monads other than that both words start with 'm'. One approach that has been proposed to improve composability of macros is to adopt a continuation-passing style. This would make macros a candidate for the continuation monad, so perhaps monads may be of use in implementing complex macros. Konrad. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: monads > macros
>> In their place, i wish monads would get a wider attention and embrace. please y'all note that there's much more to category-theory-in-programming-languages than just monads. :-) http://www.haskell.org/haskellwiki/Typeclassopedia sincerely. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: monads > macros
On Jul 12, 9:33 am, Thorsten Wilms wrote: > It's not my perception that there is a lot of noise about macros, > whereas articles about monads are like bunnies and have taken to the > meta-level. I was going to write an article about how to use monads to simplify the implementation of the code for your monad+macro article, but it sounds like someone's beaten me to it. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: monads > macros
On 07/12/2011 03:28 PM, James Keats wrote: I'm mildly concerned about macros being seen as the "secret weapon" of clojure(/lisp). In their place, i wish monads would get a wider attention and embrace. Do you want to suggest that it would be common that an issue can be solved with either a macro or a monad, or is it all about attention and how often one or the other is mentioned? At least some monads, even if not called so, are present in lots of languages. But good macro functionality is typical for lisps. It's not my perception that there is a lot of noise about macros, whereas articles about monads are like bunnies and have taken to the meta-level. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: monads > macros
2011/7/12 David Nolen > On Tue, Jul 12, 2011 at 9:40 AM, James Keats wrote: > >> >> >> On Jul 12, 2:36 pm, Tamreen Khan wrote: >> > Are monads all that special? My understanding is that even in Haskell >> > its wise to not use monads all that much, since it starts to make the >> > code look a little too imperative if not wielded correctly. They're >> > not really the meat of haskell/fp. Macros on the other hand are an >> > important part of lisp, although their overuse is also discouraged :) >> > >> >> My humble understanding is that macros complicate composability, >> whereas monads facilitate it. >> > > Monads bring their own composability issues. Read up on monad transformers > and how they result in complexities like the monad zipper. > +1 plus read Jim Duey's http://intensivesystems.net/writings.html then try to write code with monads...you can spend a week trying to fit the pieces together, i'm not sure the holy grail of composability (whatever that means to you) is worth the investment Las > David > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- László Török Skype: laczoka2000 Twitter: @laczoka -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: monads > macros
On Tue, Jul 12, 2011 at 9:40 AM, James Keats wrote: > > > On Jul 12, 2:36 pm, Tamreen Khan wrote: > > Are monads all that special? My understanding is that even in Haskell > > its wise to not use monads all that much, since it starts to make the > > code look a little too imperative if not wielded correctly. They're > > not really the meat of haskell/fp. Macros on the other hand are an > > important part of lisp, although their overuse is also discouraged :) > > > > My humble understanding is that macros complicate composability, > whereas monads facilitate it. > Monads bring their own composability issues. Read up on monad transformers and how they result in complexities like the monad zipper. David -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: monads > macros
On Jul 12, 2:36 pm, Tamreen Khan wrote: > Are monads all that special? My understanding is that even in Haskell > its wise to not use monads all that much, since it starts to make the > code look a little too imperative if not wielded correctly. They're > not really the meat of haskell/fp. Macros on the other hand are an > important part of lisp, although their overuse is also discouraged :) > My humble understanding is that macros complicate composability, whereas monads facilitate it. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: monads > macros
Are monads all that special? My understanding is that even in Haskell its wise to not use monads all that much, since it starts to make the code look a little too imperative if not wielded correctly. They're not really the meat of haskell/fp. Macros on the other hand are an important part of lisp, although their overuse is also discouraged :) On Tuesday, July 12, 2011, James Keats wrote: > > I'm mildly concerned about macros being seen as the "secret weapon" of > clojure(/lisp). > > In their place, i wish monads would get a wider attention and embrace. > > Discuss? :-) > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: monads m-seq and m-lift
yea .. I was playing around and modified it in the due coarse.. :) Sunil. On Tue, Nov 2, 2010 at 5:28 PM, Konrad Hinsen wrote: > On 02.11.2010, at 11:45, Sunil S Nandihalli wrote: > > > following is the extract from the monads example ... > > It looks quite modified and no longer returns pairs! Here is the original: > > (with-monad sequence-m > (defn pairs [xs] > ((m-lift 2 #(list %1 %2)) xs xs))) > > > ; Another way to define pairs is through the m-seq operation. It takes > > ; a sequence of monadic values and returns a monadic value containing > > ; the sequence of the underlying values, obtained from chaining together > > ; from left to right the monadic values in the sequence. > > (with-monad sequence-m > >(defn pairs [xs] > > (m-seq (list xs xs > > > > can somebody help me understand what is happening in the second one .. ? > > when would it be more appropriate to use m-seq instead of m-lift .. > > In most real-life cases you wouldn't have that choice, as m-lift and m-seq > do very different things. It's just for making pairs that either one is > fine. > > One example for the use of m-seq is given right after the pairs example: > > (with-monad sequence-m > (defn ntuples [n xs] > (m-seq (replicate n xs > > This is a generalization from pairs to n-tuples. You couldn't do this using > m-lift applied to the list function because m-lift requires a fixed arity. > > Another example is given later in the example collection under "random > number generators". > > Konrad. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: monads m-seq and m-lift
Hi Konrad, nicolas and Ken, Thanks for help. I am sure I will need more help when I try to walk through the rest of the examples. But the idea of monads is really neat..:).. Sunil. On Tue, Nov 2, 2010 at 7:19 PM, Ken Wesson wrote: > On Tue, Nov 2, 2010 at 8:55 AM, Konrad Hinsen > wrote: > >> On 02.11.2010, at 13:34, Ken Wesson wrote: >> >> > This wouldn't work?: >> > >> > (with-monad sequence-m >> > (defn ntuples [n xs] >> > (apply (m-lift n list) (replicate n xs >> >> No. >> >> > (If m-lift is a macro that requires the arity arg to be known at >> macroexpansion time: >> > >> > (with-monad sequence-m >> > (defn ntuples [n xs] >> > (apply (eval `(m-lift ~n list)) (replicate n xs >> > >> > instead. Icky, mind you.) >> >> That should work. But once you are at that level of Lisp proficiency, you >> should also have heard the "eval is evil" lesson a few times ;-) > > > Yeah, I wouldn't actually use it for something like that in production > code. In this case I'd use m-seq. In fact the only time I've used eval in > production code, thus far, was in a system that had to generate new > functions on the fly based on data only available at runtime, and for > efficiency reasons those needed to become bytecode and potentially subject > to JIT compilation. So there was a compiler function that took some data, > constructed (fn ...) forms and eval'd them, and returned the resulting > function objects to its caller. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: monads m-seq and m-lift
On Tue, Nov 2, 2010 at 8:55 AM, Konrad Hinsen wrote: > On 02.11.2010, at 13:34, Ken Wesson wrote: > > > This wouldn't work?: > > > > (with-monad sequence-m > > (defn ntuples [n xs] > > (apply (m-lift n list) (replicate n xs > > No. > > > (If m-lift is a macro that requires the arity arg to be known at > macroexpansion time: > > > > (with-monad sequence-m > > (defn ntuples [n xs] > > (apply (eval `(m-lift ~n list)) (replicate n xs > > > > instead. Icky, mind you.) > > That should work. But once you are at that level of Lisp proficiency, you > should also have heard the "eval is evil" lesson a few times ;-) Yeah, I wouldn't actually use it for something like that in production code. In this case I'd use m-seq. In fact the only time I've used eval in production code, thus far, was in a system that had to generate new functions on the fly based on data only available at runtime, and for efficiency reasons those needed to become bytecode and potentially subject to JIT compilation. So there was a compiler function that took some data, constructed (fn ...) forms and eval'd them, and returned the resulting function objects to its caller. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: monads m-seq and m-lift
On 02.11.2010, at 13:34, Ken Wesson wrote: > This wouldn't work?: > > (with-monad sequence-m > (defn ntuples [n xs] > (apply (m-lift n list) (replicate n xs No. > (If m-lift is a macro that requires the arity arg to be known at > macroexpansion time: > > (with-monad sequence-m > (defn ntuples [n xs] > (apply (eval `(m-lift ~n list)) (replicate n xs > > instead. Icky, mind you.) That should work. But once you are at that level of Lisp proficiency, you should also have heard the "eval is evil" lesson a few times ;-) Konrad. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: monads m-seq and m-lift
On Tue, Nov 2, 2010 at 7:58 AM, Konrad Hinsen wrote: > On 02.11.2010, at 11:45, Sunil S Nandihalli wrote: > > > following is the extract from the monads example ... > > It looks quite modified and no longer returns pairs! Here is the original: > > (with-monad sequence-m > (defn pairs [xs] > ((m-lift 2 #(list %1 %2)) xs xs))) > > > ; Another way to define pairs is through the m-seq operation. It takes > > ; a sequence of monadic values and returns a monadic value containing > > ; the sequence of the underlying values, obtained from chaining together > > ; from left to right the monadic values in the sequence. > > (with-monad sequence-m > >(defn pairs [xs] > > (m-seq (list xs xs > > > > can somebody help me understand what is happening in the second one .. ? > > when would it be more appropriate to use m-seq instead of m-lift .. > > In most real-life cases you wouldn't have that choice, as m-lift and m-seq > do very different things. It's just for making pairs that either one is > fine. > > One example for the use of m-seq is given right after the pairs example: > > (with-monad sequence-m > (defn ntuples [n xs] > (m-seq (replicate n xs > > This is a generalization from pairs to n-tuples. You couldn't do this using > m-lift applied to the list function because m-lift requires a fixed arity. This wouldn't work?: (with-monad sequence-m (defn ntuples [n xs] (apply (m-lift n list) (replicate n xs (If m-lift is a macro that requires the arity arg to be known at macroexpansion time: (with-monad sequence-m (defn ntuples [n xs] (apply (eval `(m-lift ~n list)) (replicate n xs instead. Icky, mind you.) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: monads m-seq and m-lift
On 02.11.2010, at 11:45, Sunil S Nandihalli wrote: > following is the extract from the monads example ... It looks quite modified and no longer returns pairs! Here is the original: (with-monad sequence-m (defn pairs [xs] ((m-lift 2 #(list %1 %2)) xs xs))) > ; Another way to define pairs is through the m-seq operation. It takes > > > ; a sequence of monadic values and returns a monadic value containing > > > ; the sequence of the underlying values, obtained from chaining together > > > ; from left to right the monadic values in the sequence. > > > (with-monad sequence-m >(defn pairs [xs] > (m-seq (list xs xs > > can somebody help me understand what is happening in the second one .. ? > when would it be more appropriate to use m-seq instead of m-lift .. In most real-life cases you wouldn't have that choice, as m-lift and m-seq do very different things. It's just for making pairs that either one is fine. One example for the use of m-seq is given right after the pairs example: (with-monad sequence-m (defn ntuples [n xs] (m-seq (replicate n xs This is a generalization from pairs to n-tuples. You couldn't do this using m-lift applied to the list function because m-lift requires a fixed arity. Another example is given later in the example collection under "random number generators". Konrad. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: monads m-seq and m-lift
As I understand it, m-seq is transforms a list of monadic computation into a computation returning the list of result. The resulting computation just sequentially does every computationin the sequence and keep the result. It is useful when the arity is not known at runtime foir example. On Tue, Nov 2, 2010 at 10:45 AM, Sunil S Nandihalli wrote: > Hello everybody, > I was looking at the functions/macros defined with them I find that m-lift > is very easy and intuitive .. > following is the extract from the monads example ... > > (with-monad sequence-m > (defn pairs [xs] > ((m-lift 4 #(list :a %1 :b %2 :c %3 :d %4)) > (range 0 3) > (range 10 13) > (range 100 103) > (range 1000 1003 > (pairs (range 2)) > ; Another way to define pairs is through the m-seq operation. It takes > > > ; a sequence of monadic values and returns a monadic value containing > > > ; the sequence of the underlying values, obtained from chaining together > > > ; from left to right the monadic values in the sequence. > > > (with-monad sequence-m > (defn pairs [xs] > (m-seq (list xs xs > can somebody help me understand what is happening in the second one .. ? > when would it be more appropriate to use m-seq instead of m-lift .. > Thanks, > Sunil. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- Sent from an IBM Model M, 15 August 1989. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Monads tutorial
The sample code is available now. Took a little bit to get it set. It's the code from the tutorial with a little bonus. I implemented an HTTP protocol parser, using the parser-m monad, as an example. Jim On Apr 16, 12:37 am, Baishampayan Ghose wrote: > The code pagehttp://intensivesystems.net/tutorials/code/monads_101.clj > is giving a 404 :) > > Regards, > BG > > -- > Baishampayan Ghose > oCricket.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Monads tutorial
jim wrote: > I've just posted a tutorial on using monads in Clojure at > > http://intensivesystems.net/tutorials/monads_101.html > > It's one big chunk of text since I haven't had time to break it up > yet. It's also kind of rough, so if you see any typos, misspellings, > errors, etc., post 'em here. Comments as well. The code page http://intensivesystems.net/tutorials/code/monads_101.clj is giving a 404 :) Regards, BG -- Baishampayan Ghose oCricket.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Monads tutorial
Hi Jim, Thanks for writing the tutorial! Kev On Apr 16, 2:01 am, jim wrote: > I've just posted a tutorial on using monads in Clojure at > > http://intensivesystems.net/tutorials/monads_101.html > > It's one big chunk of text since I haven't had time to break it up > yet. It's also kind of rough, so if you see any typos, misspellings, > errors, etc., post 'em here. Comments as well. > > Thanks, > Jim --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Monads in Clojure
On Nov 25, 2008, at 9:06 AM, Konrad Hinsen wrote: > But it would be fairly easy to implement symbol- > macrolet on top of my replace-syms. Would that be something of > interest to the Clojure community? I have no experience with it myself, but I've seen it discussed as something that would be a welcome addition to Clojure. It's on Rich's to-do list as the second item listed under "Long-term": http://richhickey.backpackit.com/pub/1597914 --Steve --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Monads in Clojure
On Nov 21, 2008, at 17:10, Chouser wrote: > This is pretty code. Did you just implement symbol-macro-let? > Very nice. I just saw a reference to symbol-macrolet with a description. My function replace-syms is indeed very similar, the difference being that it takes a map for defining the substitutions to be done, instead of a let-like sequence. The difference is not just in syntax though, as expressions in symbol-macrolet can refer to earlier "bindings" (they aren't really bindings) whereas my replace-syms doesn't check for substitutions to be made inside other substitutions. But it would be fairly easy to implement symbol- macrolet on top of my replace-syms. Would that be something of interest to the Clojure community? Konrad. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Monads in Clojure
On Nov 23, 1:15 pm, Konrad Hinsen <[EMAIL PROTECTED]> wrote: > On 21.11.2008, at 20:10, Adam Jones wrote: > > >> The file contains the macro definitions, the definitions of three > >> popular monads (maybe, list, state), and some illustrations of their > >> use. Comments are welcome! > > > Since they support mzero and mplus, aren't these equivalent to > > Haskell's MonadPlus? (i.e. they're a little more than *just* monads) > > You can define :plus and :zero if they are appropriate for a monad. > If they are defined, you can use them. None of the predefined monad > machinery will use them at the moment, but I plan to implement > conditions, which work only if :zero is defined. > > In Haskell there are two different types of monads because of the > type system, but the Clojure implementation doesn't use the type > system at all, so :plus and :zero are simply used by convention. > > > I've been kicking around the idea of re-implementing Haskell > > typeclasses on top of multimethods. Now that I think more about it, > > this probably wouldn't be much work. > > You need to find a way to store the type information with the data. > That is easy if you limit yourself to a specific data structure, say > a map with a key reserved for type information. But if you want to be > able to use typeclasses for general Clojure data (e.g. make sequences > an instance of Monad), I don't see a simple way to do it. That's the problem I've been thinking on. I'm looking for a decently sane way to build on the multimethod dispatch system here instead of explicitly relying on types. The concept probably doesn't work very well without a guaranteed unique method of identifying an object, like a data type. -Adam > > Konrad. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Monads in Clojure
On 21.11.2008, at 20:10, Adam Jones wrote: >> The file contains the macro definitions, the definitions of three >> popular monads (maybe, list, state), and some illustrations of their >> use. Comments are welcome! > > Since they support mzero and mplus, aren't these equivalent to > Haskell's MonadPlus? (i.e. they're a little more than *just* monads) You can define :plus and :zero if they are appropriate for a monad. If they are defined, you can use them. None of the predefined monad machinery will use them at the moment, but I plan to implement conditions, which work only if :zero is defined. In Haskell there are two different types of monads because of the type system, but the Clojure implementation doesn't use the type system at all, so :plus and :zero are simply used by convention. > I've been kicking around the idea of re-implementing Haskell > typeclasses on top of multimethods. Now that I think more about it, > this probably wouldn't be much work. You need to find a way to store the type information with the data. That is easy if you limit yourself to a specific data structure, say a map with a key reserved for type information. But if you want to be able to use typeclasses for general Clojure data (e.g. make sequences an instance of Monad), I don't see a simple way to do it. Konrad. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Monads in Clojure
Stuart Sierra writes: > Rich gives out commit permission on clojure-contrib to people who are > interested, but he doesn't dictate what goes in. You have to sign the > Clojure Contributor agreement, which basically says that if the > Clojure license changes at some point, you allow your contribution to > be released under the same license (still open-source, of course). This paper http://www.rosenlaw.com/OSL3.0-explained.pdf suggests an alternative to contributor agreements that might be worth considering. Here is the relevant section: This is also a function that can be performed by the Academic Free License. AFL 3.0 is identical to OSL 3.0 except that licensees are now free "to distribute or communicate copies of the Original Work and Derivative Works to the public, under any license of your choice that does not contradict the terms and conditions, including Licensor's reserved rights and remedies, in this Academic Free License." That makes AFL 3.0 a suitable contributor license to other open source projects, especially (but not only) those projects distributing software under OSL 3.0. The project is then free to revise its outgoing license in accordance with its bylaws and charter as the times dictate. Instead of a contributor agreement, then, I often recommend that contributors offer their contribution to a project by placing the following notice adjacent to their copyright notice: Licensed to Project XYZ under the Academic Free License (AFL 3.0). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Monads in Clojure
On Nov 21, 3:14 am, Konrad Hinsen <[EMAIL PROTECTED]> wrote: > As a first non-trivial exercice, I wrote an implementation of monads > in Clojure. I just uploaded it to the Group: > > http://clojure.googlegroups.com/web/monads.clj > > The file contains the macro definitions, the definitions of three > popular monads (maybe, list, state), and some illustrations of their > use. Comments are welcome! Since they support mzero and mplus, aren't these equivalent to Haskell's MonadPlus? (i.e. they're a little more than *just* monads) I'm trying to work my way through that material too, so I'm not entirely sure. Either way, cool stuff. I've been kicking around the idea of re-implementing Haskell typeclasses on top of multimethods. Now that I think more about it, this probably wouldn't be much work. The two big issues I can see are ensuring incomplete instances can't be created and figuring out how the dispatch function can work sanely. Haskell has an advantage here in that the only thing typeclasses dispatch on is the types involved, so it's trivial to not clobber any existing definitions. -Adam > > One thing I was wondering about: if I want to turn this into a > library module, where could I place it in Java's namespace hierarchy? > I don't have my own domain (and don't need one), and even though I > could have it hosted somewhere (such as SourceForge), it doesn't look > like a good idea to have the package name depend on a hosting site > that might not be forever. How do others approach this problem? > > Konrad. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Monads in Clojure
On Fri, Nov 21, 2008 at 11:40 AM, Konrad Hinsen <[EMAIL PROTECTED]> wrote: > > Thanks! I don't know what symbol-macrolet is/does, so I can't > comment on that. It's probably some Common Lisp thing, right? Probably, though when googling it just now, I seem to have found some third-party implementations, so who knows. My impression, though, is that it provides the ability to define a local macro where the macro doesn't need to be called from the head of a list, but is just a symbol that can be dropped in anywhere. Perhaps someone who actually knows something about a lisp other than Clojure can comment. --Chouser --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Monads in Clojure
On 21.11.2008, at 17:10, Chouser wrote: > On Fri, Nov 21, 2008 at 6:14 AM, Konrad Hinsen > <[EMAIL PROTECTED]> wrote: >> >> As a first non-trivial exercice, I wrote an implementation of monads >> in Clojure. I just uploaded it to the Group: >> >>http://clojure.googlegroups.com/web/monads.clj > > This is pretty code. Did you just implement symbol-macro-let? > Very nice. Thanks! I don't know what symbol-macrolet is/does, so I can't comment on that. It's probably some Common Lisp thing, right? > I noticed that you have a private function (monad-expr) used by a > macro, and was about to comment that that doesn't work -- but your > function is used by the macro, not the *expansion* of the macro, so it > should work just fine. I'll have to keep that in mind. Yes, it is used only at expansion time. > (zero? n) is an idiom for (= 0 n) Good to know! Konrad. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Monads in Clojure
On Fri, Nov 21, 2008 at 6:14 AM, Konrad Hinsen <[EMAIL PROTECTED]> wrote: > > As a first non-trivial exercice, I wrote an implementation of monads > in Clojure. I just uploaded it to the Group: > >http://clojure.googlegroups.com/web/monads.clj This is pretty code. Did you just implement symbol-macro-let? Very nice. I noticed that you have a private function (monad-expr) used by a macro, and was about to comment that that doesn't work -- but your function is used by the macro, not the *expansion* of the macro, so it should work just fine. I'll have to keep that in mind. (zero? n) is an idiom for (= 0 n) Alas even your beautiful, succinct implementation and careful code comments are apparently insufficient for me to understand monads. I'll keep trying. :-) --Chouser --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Monads in Clojure
On Nov 21, 10:06 am, Konrad Hinsen <[EMAIL PROTECTED]> wrote: > Actually, I have no idea of how clojure-contrib works. Is this a > repository for all kinds of Clojure add-ons? Or stuff selected by > Rich for a specific reason? Rich gives out commit permission on clojure-contrib to people who are interested, but he doesn't dictate what goes in. You have to sign the Clojure Contributor agreement, which basically says that if the Clojure license changes at some point, you allow your contribution to be released under the same license (still open-source, of course). -Stuart Sierra --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Monads in Clojure
On Nov 21, 2008, at 15:01, walterc wrote: > how about clojure-contrib? Actually, I have no idea of how clojure-contrib works. Is this a repository for all kinds of Clojure add-ons? Or stuff selected by Rich for a specific reason? Konrad. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Re: Monads in Clojure
how about clojure-contrib? On Nov 21, 7:14 pm, Konrad Hinsen <[EMAIL PROTECTED]> wrote: > As a first non-trivial exercice, I wrote an implementation of monads > in Clojure. I just uploaded it to the Group: > > http://clojure.googlegroups.com/web/monads.clj > > The file contains the macro definitions, the definitions of three > popular monads (maybe, list, state), and some illustrations of their > use. Comments are welcome! > > One thing I was wondering about: if I want to turn this into a > library module, where could I place it in Java's namespace hierarchy? > I don't have my own domain (and don't need one), and even though I > could have it hosted somewhere (such as SourceForge), it doesn't look > like a good idea to have the package name depend on a hosting site > that might not be forever. How do others approach this problem? > > Konrad. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---