Oliver, Objects and monads are really not the same. At it's heart the concept of monad is an appropriately parametric notion of composition. If you have any experience with abstract algebra, you might recognize that the notion of a group <http://en.wikipedia.org/wiki/Symmetry_group> is an appropriately parametric notion of symmetry. Groups give an exceptionally well abstracted account of symmetry. Monads give an exceptionally well abstracted notion of composition. This is a lot easier to see in the Category Theoretic presentation.
A monad <http://en.wikipedia.org/wiki/Monad_%28category_theory%29> is presented by three pieces of data: - An endofunctor <http://en.wikipedia.org/wiki/Functor> M : C -> C (intuitively, think of M as a parametric type constructor and C as the universe of types and maps) - A natural transformation<http://en.wikipedia.org/wiki/Natural_transformation>unit: Id -> M -- this is a higher-order critter: it takes maps to maps; but i'll give you a metaphor in just a moment. - A natural transformation mult: M^2 -> M One picture you can have in your mind is M is a kind of "box" factory. Then unit says how you can put things into a box, and mult says how you can flatten nested boxes into an ordinary box (this is the origins of flatMap in Scala's presentation). Another way of understanding this is that M is a kind of higher-order compositor, i.e. a way of combining things just like multiplication, as in a*b, is a way of combining things. Then the unit is the analog of having a unit for your multiplication and mult is the analog of an associativity law ( a*(b*c) = (a*b)*c ). These line up with the box analogy more easily if you write things with prefix notation instead of infix notation. - Let's write {*| a, b |*} instead of a*b. The reason we adopt this more verbose notation is that we can note the different kind of boxes with the 'color' of the braces. M-colored braces, {M| a, b |M}, are associated with an M-box. - Then unit( a ) = {M| a |M}, it puts a in an M-box. This has an alternate presentation of the form {M| |M}.{M| a |M} = {M| a |M}. i mention it to point out the analogy with the binary operation _*_, but it muddies the water a little with begging the question about the _._. So, i will just leave it -- without explanation -- for you to explore. - And mult( {M| {M| a11, ..., a1J |M} ... {M| aI1, ... aIJ' |M} |M} ) = {M| a11, ..., aIJ' |M}. It tells you how to canonically flatten M-boxes. This functions as an association because if boxes canonically flatten, then {M| a, {M| b, c |M} |M} = {M| a, b, c |M} = {M| {M| a, b |M}, c |M}. The apparent lexical connection between this way of thinking about things and XML *is not accidental*. Monads can be viewed as colored braces, aka matched tags. Monads are a semantical creature that presents syntactically like XML. This way of thinking about things is really different from objects. To be sure, there are notions of objects that are universal and so can be made to fit or encode just about anything; but, that doesn't mean the encodings are nice, or scalable or maintainable. You have only to to look at something like LINQ -- which is really just a presentation of monads -- to see just how flexible and yet compact the monadic way of structuring composition is. Specifically, both set-comprehension notation and SELECT-FROM-WHERE, when interpreted polymorphically, provide a natural representation of the monad. - { pattern | t1 <- generator1, ..., tn <- generatorN, constraint1, ..., constraintK } - SELECT pattern FROM generator WHERE constraint Those to pieces of computational machinery have very simple, and natural mappings to the monad operations. You will win if you work these out for yourself. Phil Wadler has excellent papers to provide cheat sheets. The Scala for-comprehension and the corresponding operations of map, flatMap and filter are also excellent cheat sheets. But, you get the joy if you work this out for yourself. Best wishes, --greg 2009/6/17 Oliver Lambert <olambo...@gmail.com> > > > 2009/6/18 Meredith Gregory <lgreg.mered...@gmail.com> > >> Oliver, >> >> The short answer is no. The longer answer is >> >> - i worked this all out on my own; so, you guys -- who can program >> lift on top of scala on top of JVM and are therefore about 20X smarter >> than >> i am -- can too. >> >> I think if we were all 20X (or 2X) smarter than you, we would have taken > over Google by now. > >> >> - And also, help is always available, if there is something specific >> you don't understand, let me know and i will do my best to convey it to >> you. >> >> As suggested by another kind person, I may have to start by going back to > (an American?) school. > > Heres a question, why should I care about Monad's when they are already in > OO, just not called Monads? > > >> >> - >> >> Best wishes, >> >> --greg >> >> P.S. Here is a version of the paragraph with links to useful bits of lore >> from the literature. >> >> For myself, i was unhappy with the notion of name. The >> π-calculi<http://en.wikipedia.org/wiki/Pi-calculus>and lambda >> calculi <http://en.wikipedia.org/wiki/Lambda_calculus> suffer a >> dependence on a notion of name. Both families of calculi require at least >> countably >> infinitely <http://en.wikipedia.org/wiki/Countable> many >> names<http://www.cs.nps.navy.mil/research/languages/statements/gordon.html>, >> and a notion of equality on names. If names have no internal structure then >> these theories *cannot be >> effective<http://en.wikipedia.org/wiki/Computable_function> >> *. The reasons is that the notion of equality must then be realized as an >> infinitary table which cannot fit in any computer we have access to. >> Therefore, in effective theories, names must have internal structure. Since >> they have internal structure and are at least countably infinite, one is in >> danger of undermining the foundational character of these proposals for >> computing. Therefore, the only possible solution is that the notion of >> structured name must come from the notion of program proposed by the model. >> This argument is airtight. If you want a foundational model of computing >> with nominal structure, the nominal structure must derive from the notion of >> computation being put forward, i.e. it must *reflect* the notion of >> computation<http://svn.biosimilarity.com/src/open/papers/trunk/concurrency/rho/ex_nihilo_entcs/ex_nihilo_finco.pdf>. >> This gives rise to all kinds of new an beautiful phenomena. One measure of >> your way into compositional thinking is whether this is happening. Is your >> approach to compositional thinking beginning to yield whole new aspects of >> computing, and new 'wholes' of computation, new forms of organization. >> >> >> 2009/6/16 Oliver Lambert <olambo...@gmail.com> >> >>> >>> >>> 2009/6/17 Meredith Gregory <lgreg.mered...@gmail.com> >>> >>>> Jeremy, >>>> >>>> Most excellent question award to you, sir! >>>> >>>> How to bootstrap thinking compositionally... this is what i did >>>> >>>> - learn some compositional idioms by heart >>>> - do you know the shape of the paradoxical combinator by heart >>>> - do you know the data making up a monad >>>> - do you know the data making up a distributive law between >>>> monads >>>> - use them in real world applications and see where they fail >>>> - when is calculating the least/greatest fixpoint of a recursive >>>> spec for a problem the suboptimal solution >>>> - when is a monad not the answer >>>> - when is an indexed form of composition inadequate >>>> - improve them >>>> - is it a situational improvement or >>>> - a fundamental improvement >>>> - see where the very programming model itself fails >>>> - is functional composition the only sort of composition >>>> - how is parallel composition like functional composition >>>> - is parallel composition easily represented in categorical >>>> composition >>>> - improve it >>>> - what is the view of the world in your notion of composition >>>> - play with new programming models >>>> - does your new notion of composition give rise to a whole >>>> generation of different models >>>> - invent new idioms in these models >>>> - what are the things these models naturally express >>>> - and teach them to someone who wishes to bootstrap thinking >>>> compositionally >>>> >>>> For myself, i was unhappy with the notion of name. The π-calculi and >>>> lambda calculi suffer a dependence on a notion of name. Both families of >>>> calculi require at least countably infinitely many names, and a notion of >>>> equality on names. If names have no internal structure then these theories >>>> *cannot be effective*. >>> >>> >>> Do we need to do some sort of course to understand this language? >>> >>> >>>> The reasons is that the notion of equality must then be realized as an >>>> infinitary table which cannot fit in any computer we have access to. >>>> Therefore, in effective theories, names must have internal structure. Since >>>> they have internal structure and are at least countably infinite, one is in >>>> danger of undermining the foundational character of these proposals for >>>> computing. Therefore, the only possible solution is that the notion of >>>> structured name must come from the notion of program proposed by the model. >>>> This argument is airtight. If you want a foundational model of computing >>>> with nominal structure, the nominal structure must derive from the notion >>>> of >>>> computation being put forward, i.e. it must *reflect* the notion of >>>> computation. This gives rise to all kinds of new an beautiful phenomena. >>>> One >>>> measure of your way into compositional thinking is whether this is >>>> happening. Is your approach to compositional thinking beginning to yield >>>> whole new aspects of computing, and new 'wholes' of computation, new forms >>>> of organization. >>>> >>>> Best wishes, >>>> >>>> --greg >>>> >>>> On Tue, Jun 16, 2009 at 7:31 PM, Jeremy Day <jeremy....@gmail.com>wrote: >>>> >>>>> Greg, >>>>> >>>>> On Tue, Jun 16, 2009 at 6:38 PM, Meredith Gregory < >>>>> lgreg.mered...@gmail.com> wrote: >>>>> >>>>>> It takes some serious training to think compositionally. >>>>> >>>>> >>>>> No doubt it is extremely tough to think compositionally, and it's all >>>>> too easy to fall back on non-compositional ways of thinking. In a similar >>>>> vein it's all too easy to fall into procedural patterns when learning or >>>>> working with functional programming in a multi-paradigm language. But >>>>> what >>>>> are good ways for programmers to learn to think compositionally and, more >>>>> importantly, practice? Do you know of any books or online references that >>>>> might help make the transition for anyone who is interested? >>>>> >>>>> Jeremy >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> L.G. Meredith >>>> Managing Partner >>>> Biosimilarity LLC >>>> 1219 NW 83rd St >>>> Seattle, WA 98117 >>>> >>>> +1 206.650.3740 >>>> >>>> http://biosimilarity.blogspot.com >>>> >>>> >>>> >>> >>> >>> >> >> >> -- >> L.G. Meredith >> Managing Partner >> Biosimilarity LLC >> 1219 NW 83rd St >> Seattle, WA 98117 >> >> +1 206.650.3740 >> >> http://biosimilarity.blogspot.com >> >> >> > > > > -- L.G. Meredith Managing Partner Biosimilarity LLC 1219 NW 83rd St Seattle, WA 98117 +1 206.650.3740 http://biosimilarity.blogspot.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
