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