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