I just want to say that it's educating and awesome (in the true sense of the word) to have you on this list, enriching us with alot of good ideas, theories and concepts.
2009/6/18 Meredith Gregory <lgreg.mered...@gmail.com> > Viktor, > > My co-routine yields back to yours! > > Hey, it's like Garrison Keillor's Tales from Lake > Wobegon<http://en.wikipedia.org/wiki/Lake_Wobegon>: > where *all* of the children are above average. If you think about it, that > just keeps *lift*ing the children higher and higher and higher... > > Speaking of which, i think David's goat rodeo ideas fit pretty well with > some ideas i've been working on regarding a uniform approach to data. This > takes the whole LINQ idea up a couple of notches. To see what i mean, take a > look at the slides for a recent talk i > gave<http://svn.biosimilarity.com/src/open/talks/MonadicDesignPatternsForTheWeb.pdf>. > Comments (peanuts, rotten tomatoes...) would be most welcome. > > Best wishes, > > --greg > > P.S. Oliver's sincere question compelled me to respond with my own best > understanding of the topic. > > 2009/6/18 Viktor Klang <viktor.kl...@gmail.com> > >> 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 >> >> >> >> > > > -- > 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 -~----------~----~----~----~------~----~------~--~---
