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