It depends what your goals are. If you want to automatically derive an IDE from a grammar then the best work is the Synthesizer Generator but it is limited to absolutely noncircular attribute grammars IIRC. But it had wicked cool features like incremental live evaluation. Tom Reps won a ACM Disssrtation award for the work. The downside was scaling this approach to so-called very large scale software systems. But there are two reasons why I feel that concern is overblown: (1) nobody has brute forced the memory exhaustion problem using the cloud (2) with systems like FONC we wouldnt be building huge systems anyway.
Alternatively, "grammarware" hasn't died simply because of the SG scaling issue. Ralf Lammel, Eelco Visser and others have all contributed to ASF+SDF and the Spoofax language environment. But none of these are as cool as SG and with stuff like Spoofax you have to sidt thru Big And Irregular APIs for IME hooking into Big And Irregular Eclipse APIs. Seperating the intellectual wheat from the chaff was a PITA.... Although I did enjoy Visser's thesis on scannerless parsing which led me to apprrciate boolean grammars. Alan, A question for you is Did SG approach ever come up in desivn discuszions or prototypes for any Smalltalk? I always assumed No due to selection bias... Until Ometa there hasnt been a clear use case. Cheers, Z-Bo On Apr 11, 2012 10:21 AM, "Florin Mateoc" <fmat...@yahoo.com> wrote: > Yes, these threads are little gems by themselves, thank you! > > I hope I am not straying too much from the main topic when asking about > what I think is a related problem: a great help for playing with languages > are the tools. Since we are talking about bootstrapping everything, we > would ideally also be able to generate the tools together with all the > rest. This is a somewhat different kind of language bootstrap, where > actions and predicates in the language grammar have their own grammar, so > they don't need to rely on any host language, but still allow one to > flexibly generate a lot of boilerplate code, including for example classes > (or other language specific structures) representing the AST nodes, > including visiting code, formatters, code comparison tools, even > abstract(ideally with a flexible level of abstraction)evaluation code over > those AST nodes, and debuggers. This > obviously goes beyond language syntax, one needs an execution model as well > (perhaps in combination with a worlds-like approach). I am still not sure > how far one can go, what can be succinctly specified and how. > > I would greatly appreciate any pointers in this direction > > Florin > > ------------------------------ > *From:* Monty Zukowski <mo...@codetransform.com> > *To:* Fundamentals of New Computing <fonc@vpri.org> > *Sent:* Wednesday, April 11, 2012 12:20 AM > *Subject:* Re: [fonc] Kernel & Maru > > Thank you everyone for the great references. I've got some homework > to do now... > > Monty > > On Tue, Apr 10, 2012 at 2:54 PM, Ian Piumarta <piuma...@speakeasy.net> > wrote: > > Extending Alan's comments... > > > > A small, well explained, and easily understandable example of an > iterative implementation of a recursive language (Scheme) can be found in > R. Kent Dybvig's Ph.D. thesis. > > > > http://www.cs.unm.edu/~williams/cs491/three-imp.pdf > > > > Regards, > > Ian > > > > _______________________________________________ > > fonc mailing list > > fonc@vpri.org > > http://vpri.org/mailman/listinfo/fonc > _______________________________________________ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > > > > _______________________________________________ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
