I yield to your superiority. Seriously. 2009/6/18 Meredith Gregory <lgreg.mered...@gmail.com>
> 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 > > > > -- Viktor Klang Scala Loudmouth --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
