Re: Monads and Middleware

[James Reeves]

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

[Gary Zhao]

Thanks Michael. 

On Saturday, November 9, 2013 10:26:09 AM UTC-8, Michael Klishin wrote:

 2013/11/9 Gary Zhao gary...@gmail.com javascript:

 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

[Michael Klishin]

2013/11/9 Gary Zhao garyz...@gmail.com

 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

[Timothy Baldridge]

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 carloshsgald...@gmail.comwrote:

 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.
 

Re: Monads usage

[Timothy Baldridge]

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 tbaldri...@gmail.comwrote:

 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 
 carloshsgald...@gmail.comwrote:

 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 

Re: Monads usage

[Armando Blancas]

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

[nicolas.o...@gmail.com]

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

[Michael Bradley, Jr.]

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.

 snip



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

[Stephen Compall]

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

[Armando Blancas]

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

[Andy Fingerhut]

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

[Brian Marick]

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

[Stephen Compall]

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

[Ben Wolfson]

On Fri, Oct 26, 2012 at 8:39 PM, Stephen Compall
stephen.comp...@gmail.com 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 macros

[Konrad Hinsen]

On 12 Jul 2011, at 23:18, Alan Malloy wrote:


On Jul 12, 12:01 pm, Konrad Hinsen konrad.hin...@fastmail.net 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

[Konrad Hinsen]

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

[Ken Wesson]

On Wed, Jul 13, 2011 at 7:19 AM, Konrad Hinsen
konrad.hin...@fastmail.net 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

[Raoul Duke]

On Wed, Jul 13, 2011 at 5:20 AM, Ken Wesson kwess...@gmail.com 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

[Ken Wesson]

On Wed, Jul 13, 2011 at 1:37 PM, Raoul Duke rao...@gmail.com wrote:
 On Wed, Jul 13, 2011 at 5:20 AM, Ken Wesson kwess...@gmail.com 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

[Tamreen Khan]

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 james.w.ke...@gmail.com 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 macros

[David Nolen]

On Tue, Jul 12, 2011 at 9:40 AM, James Keats james.w.ke...@gmail.comwrote:



 On Jul 12, 2:36 pm, Tamreen Khan histor...@gmail.com 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

[László Török]

2011/7/12 David Nolen dnolen.li...@gmail.com

 On Tue, Jul 12, 2011 at 9:40 AM, James Keats james.w.ke...@gmail.comwrote:



 On Jul 12, 2:36 pm, Tamreen Khan histor...@gmail.com 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

[Thorsten Wilms]

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

[Alan Malloy]

On Jul 12, 9:33 am, Thorsten Wilms t...@freenet.de 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

[Raoul Duke]

 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

[Konrad Hinsen]

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

[Christian Marks]

On Jul 12, 9:28 am, James Keats james.w.ke...@gmail.com 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

[Alan Malloy]

On Jul 12, 12:01 pm, Konrad Hinsen konrad.hin...@fastmail.net 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

[Ken Wesson]

On Tue, Jul 12, 2011 at 3:01 PM, Konrad Hinsen
konrad.hin...@fastmail.net 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 m-seq and m-lift

[nicolas.o...@gmail.com]

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
sunil.nandiha...@gmail.com 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 m-seq and m-lift

[Konrad Hinsen]

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

[Ken Wesson]

On Tue, Nov 2, 2010 at 7:58 AM, Konrad Hinsen konrad.hin...@fastmail.netwrote:

 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

[Konrad Hinsen]

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

[Ken Wesson]

On Tue, Nov 2, 2010 at 8:55 AM, Konrad Hinsen konrad.hin...@fastmail.netwrote:

 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

[Sunil S Nandihalli]

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 kwess...@gmail.com wrote:

 On Tue, Nov 2, 2010 at 8:55 AM, Konrad Hinsen 
 konrad.hin...@fastmail.netwrote:

 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.comclojure%2bunsubscr...@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

[Sunil S Nandihalli]

yea .. I was playing around and modified it in the due coarse.. :)
Sunil.

On Tue, Nov 2, 2010 at 5:28 PM, Konrad Hinsen konrad.hin...@fastmail.netwrote:

 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.comclojure%2bunsubscr...@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 tutorial

[jim]

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 b.gh...@ocricket.com wrote:
 The code pagehttp://intensivesystems.net/tutorials/code/monads_101.clj
 is giving a 404 :)

 Regards,
 BG

 --
 Baishampayan Ghose b.gh...@ocricket.com
 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

[kkw]

Hi Jim,

Thanks for writing the tutorial!

Kev

On Apr 16, 2:01 am, jim jim.d...@gmail.com 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 tutorial

[Baishampayan Ghose]

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 b.gh...@ocricket.com
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 in Clojure

[Konrad Hinsen]

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

[Stephen C. Gilardi]

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

[Konrad Hinsen]

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

[Adam Jones]

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

[Konrad Hinsen]

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

[Konrad Hinsen]

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

[jan]

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
-~--~~~~--~~--~--~---