Well, ahem (cough, cough) a bit off-topic, but since you ask... I've always believed that the sort of mental versatility and adaptability that leads one to such creativity does tend to drive one away from the black and white of most ideology and toward the shades-of-gray of radical non-ideological thought. (Though the right end of the political spectrum is more likely to embrace black/white thinking, there are plenty on the so-called "left" who just don't get it, much to the delight of right-wing ideologues.)
That said, as I've gotten older I've realized that this continuum is better mapped via emotional signifiers, and that even the most lithe intellect can be hamstrung by emotional insecurity and a need for "concrete" answers and rigid structures. Of course, the desideratum is not intellect, but wisdom, and intellect is not the same as wisdom. Wisdom is intelligence applied with compassion, so it has both intellectual and emotional aspects. The whole left-right political spectrum is a canard, pretending a significant difference where none exists. The real continuum is forward-backward (or up-down), with forward indicating an increased ability to comprehend and appreciate complexity and subtle nuance -- to see the world as constantly changing, with everything interconnected and blending together -- and backward indicating a desire to simplify, polarize, isolate, and set in stone. Conveniently, Dr. Chomsky has a surfeit of both intellect and compassion, so much so that when he opened his mouth to speak in my presence, I found myself weeping uncontrollably. The emotional impact was overwhelming. I had expected an arrogant intellectual. Instead, I encountered an enlightened being, and having never been in the physical presence of one before, I was utterly unprepared for the effect. I was joking about the commie pinko stuff, of course. Chomsky defies categorization, and attempts to do so tell you much about the categorizer, and very little about Chomsky. Still, he's welcome to manage any open source project I ever undertake. Chas. P.S. You do know that I am a linguist by training, right? Meredith Gregory wrote: > Chas, > > You know, with all his research on 'Manufacturing Consent', Noam might > have a 3rd career in managing open source projects. Since you've pinned > the tail on the donkey, so to speak, do you think there might be a > connection between ideology and design skills? i mean his work on > grammars and computability was really wicked clever. You don't think his > pinko commie leanings could like have any connection to his insights on > linguistics and computation, do you? > > Best wishes, > > --greg > > On Fri, May 15, 2009 at 12:47 PM, Charles F. Munat <[email protected] > <mailto:[email protected]>> wrote: > > > Ooooo. You've polished this up a bit. Very nice. > > Chomsky? Isn't he that commie pinko America-hater? > > Chas. > > Meredith Gregory wrote: > > Chas, > > > > You're too kind. Fortunately, i can take none of the credit: > > language-based design goes all the way back to Chomsky. ;-) For those > > who are not familiar with this approach, a little cheat sheet goes a > > long way. > > > > Classes ~ Types = Grammatical Categories > > > > In English, the category associated with a symbol in a grammar is > > essentially a type in a functional language, and for a good chunk of > > OO-style classes, such a category also corresponds to a class. > The main > > trick is to recognize that this is not just for parsing, anymore. The > > abstract syntax tree associated with such a grammar is essentially a > > family of classes/types that addresses some domain model. This is > really > > solid for FP types, and for the POJO-style classes (which are > > essentially relations). > > > > To illustrate, suppose we wanted to model some basic idea of > reporting. > > That is, we had > > > > * a basic report structure -- that was a list of queries and > their > > responses > > * an aggregate report structure -- that was merely a roll up of a > > bunch of sub-reports > > * a dependent report structure -- in which a report was a > function > > of some other reports > > * an "application" report structure -- in which we apply > dependent > > reports to argument reports > > > > One way to go about modeling this is as a little language of reports. > > > > Report ::= BasicReport | AggregateReport | DependentReport | > > ApplicationReport > > BasicReport ::= ReportID { (Query,Response)* } > > AggregateReport ::= [ Report* ] > > DependentReport ::= ( Formal* ){ Report } > > ApplicationReport ::= Report Report* > > Formal ::= Variable > > Query ::= ... > > Response ::= ... > > > > This is enough information to generate the entire class > structure, with > > persistence, plus a concrete language (with parser) that can be > used for > > testing (or other nefarious) purposes. To see an example of this > -- the > > little demo i gave Chas -- look here > > <http://code.google.com/p/reportatrope/>. Note that this > specifies only > > the /structural/ aspects of the relationships governing our model of > > reports. It doesn't give any sense of > > > > * how to render reports, or even > > * how to calculate the application of a dependent report to some > > arguments > > > > To this last point, those with a little more experience will spot > that > > this structure is remarkably similar to... (wait for it) the lambda > > calculus. Yes, i've snuck in a little programming language > structure to > > my model because ... well... it turns out it's really necessary > for most > > moderately rich domains. This comes with a notion of evaluation that > > can, in principle, provide a reasonable semantics for how one > calculates > > application reports. That gives some insight into why choose > rlambda as > > the archetype. It also indicates that adding some sort of rewrite > rules > > to the grammar above might be a good thing. In this case, the rewrite > > rule is something like > > > > ( f1, ..., fn ){ R } R1 ... Rn -> R{ R1/f1, ..., Rn/fn } > > > > In English, a dependent report with formal parameters f1, ..., fn, > > applied to arguments R1, ..., Rn evaluates to the body of the > dependent > > report with the parameters replaced by the arguments. This > indicates we > > have to add one production to the grammar above > > > > VariableReport ::= Variable > > > > so that variables can actually occur in the body of reports! > > > > There are a lot of technical details i'm eliding here. Further, > it's not > > like one is going to be able to autogenerate a production quality > > language like Scala from a specification of this kind (yet!). > But, it is > > a lot better than beginning with a blank slate. > > > > To the first bullet above, it turns out that there are some natural > > default rendering's of structure so defined that -- in my view -- > line > > up very well with Charles' vision of the web app pipeline. > > > > Best wishes, > > > > --greg > > > > On Fri, May 15, 2009 at 9:47 AM, Charles F. Munat <[email protected] > <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> wrote: > > > > > > I've seen this demonstrated and the conceptual part is actually > > drop-dead simple. But maybe watching it work helps a lot. > > > > I might also add that watching Greg write some > straightforward BNF to > > describe a complex relationship between objects in a simple > DSL and then > > generate a Lift app from in -- all in about half an hour -- > was so > > astonishing that I haven't been able to stop thinking about > it and can > > barely wait to run into him again to ask questions about it. > > > > I'm not very bright, so Greg can correct me if I'm wrong > here, but > > essentially you just write up your DSL in BNF, then you run > the BNF > > compiler and out pops some Java classes (which you dump in > your model > > directory). Then you extend those classes using Scala and you're > > good to go. > > > > Chas. > > > > Timothy Perrett wrote: > > > Greg, I find this very interesting. > > > > > > How can I help you out here? I can certainly review your > lift code, > > > not so sure about some of the crazy conceptual stuff though! > > > > > > Cheers, Tim > > > > > > On May 14, 8:41 pm, Meredith Gregory > <[email protected] <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>>> wrote: > > >> Lifted, > > >> > > >> i've added support to the rlambda lift > > >> project<http://code.google.com/p/rlambda/>taking it > within range of > > >> being a candidate DSL-archetype. At this point it > > >> is possible simply to supply a .cf file in the src/main/bnfc > > directory and > > >> it will generate everything from that. i've still got to > > conditionally > > >> include the Eval and Compile functionality for DSL that > > have/don't have this > > >> capability. > > >> > > >> i've two remaining questions for this leg of the work. > > >> > > >> - Does anyone know how to reference maven dependencies > within > > some flavor > > >> of maven-antrun-plugin? The original version does not > appear > > to have this > > >> functionality and Sun's maven-antrun-extended-plugin > (which > > is supposed to > > >> supply this functionality) has so little documentation > (that > > i could find) > > >> that i couldn't get it to work after an hour our so. > > >> - This version requires that BNFC, as an executable, be > > available on the > > >> path. Is there a blessed way to handle this sort of > dependency? > > >> - i've got a hare-brained scheme that will fix this > -- a > > >> meta-compiler-compiler from BNFC's input format to > ANTLR's. i > > >> could include > > >> such a transform as a part of the project or a > dependency and > > >> test for the > > >> availability of BNFC and fall back to ANTLR if it's not > > available. > > >> > > >> If anybody wanted to give this round of updates a whirl, even > > give me a code > > >> review, i would be very grateful. > > >> > > >> Best wishes, > > >> > > >> --greg > > >> > > >> -- > > >> 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
