Derek, Thanks! An engine is a natural next step! ;-)
Best wishes, --greg On Wed, May 6, 2009 at 12:21 PM, Derek Chen-Becker <[email protected]>wrote: > I'm not an expert at archetypes by any means, but I did kinda/sorta figure > out some basics when I put together the JPA archetypes. I'd be happy to help > if I can. Going one further, I wonder if there would be a way to just make a > single engine that could dynamically generate the artifacts it needs on the > backend. > > Derek > > > On Tue, May 5, 2009 at 4:37 PM, Meredith Gregory <[email protected] > > wrote: > >> Derek, et al, >> >> Thanks for all the kind feedback. i could use a little help with one >> thing. In addition to this project, i've also got >> >> - A project exploring how a relational query language is generated >> from a DSL describing typed sets of >> tuples<http://code.google.com/p/relatrope/> >> - A project exploring how a graph query language is generated from a >> DSL for describing graphs <http://code.google.com/p/graphatrope/> >> - A project exploring how a query language for service descriptions is >> generated from a DSL for describing concurrent >> processes<http://code.google.com/p/parallelatrope/> >> >> All of these projects, plus the rlambda >> one<http://code.google.com/p/rlambda/>, >> are cut of the same cloth in the sense that there is common lift structure >> wrapped around what is generated from the language description that is more >> or less contained in the bnf description. At this point, i'm convinced there >> is a useful lift archetype here. However, i don't know archetypes from myths >> or legends. ;-) If someone could help me get started i think i could flesh >> out a pretty compelling lift archetype for generating DSL's that i would >> love to contribute back to lift. >> >> Long term, if you look at a system like Peter Sewell's >> Ott<http://www.cl.cam.ac.uk/%7Epes20/ott/>, >> you should come away with the idea that it ought to be possible to provide, >> over and above the DSL's grammar, a very minimal specification of the DSL's >> semantics and have an execution engine generated. So, imagine, if you will, >> a lift archetype that takes as input a file approximately the size of the >> rlambda.cf<http://code.google.com/p/rlambda/source/browse/trunk/src/main/bnfc/rlambda.cf>+ >> a couple of rules for beta-reduction and alpha-equivalence, and generates >> the entire REPL-in-web-container, i.e. >> >> - generates a parser >> - an evaluator >> >> Beyond that, i have special sauce that will allow me to take such a spec >> and additionally generate >> >> - a logic >> - a model checker >> - a search engine >> >> That's where i'm headed long-term. But, to get there i need just a little >> bit of help with the archetype stuff. >> >> Best wishes, >> >> --greg >> >> >> On Tue, May 5, 2009 at 3:02 PM, Derek Chen-Becker >> <[email protected]>wrote: >> >>> We just can't be half-assed about anything, can we? ;) Seriously, this is >>> really, really cool. I'm looking forward to seeing how this grows. >>> >>> Derek >>> >>> >>> On Mon, May 4, 2009 at 7:55 PM, Meredith Gregory < >>> [email protected]> wrote: >>> >>>> Lifted, Scalad and lasses, >>>> >>>> Recently Martin passed along a little code challenge regarding scalable >>>> abstractions for building a little lambda calculus evaluator. i've finally >>>> put together a 1st draft response. i've still got a lot of debugging to do, >>>> but the solution<http://code.google.com/p/rlambda/source/browse/trunk/>is >>>> end-to-end. >>>> >>>> - there is a parser and evaluator hosted inside a lift-based >>>> web-container >>>> - the parser is built using BNFC and can target >>>> Java/C#/OCaml/Haskell/F#/... >>>> - the parser comes with visitor pattern support >>>> - the evaluator is built in a two-level type style and demonstrates >>>> that the only OO you need is just enough to make Scala happy -- the >>>> abstractions are all FP-based >>>> >>>> As i said, this is very much a draft and the code falls over most of the >>>> time. But, at this point, it's really a pedagogical device and framework >>>> for >>>> hosting and evaluating different solutions. >>>> >>>> Again, one the main reasons i see for using Scala is it's seamless >>>> interop with Java. The OCaml solution is intriguing (though ther are some >>>> strangenesses in it that i've yet to grok), but i would like to see that >>>> solution hosted in this manner. >>>> >>>> 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 -~----------~----~----~----~------~----~------~--~---
