By the way, I think you are referring to the work done by Reps's thesis advisor, Tim Teitelbaum, and his Cornell Program Synthesizer. Teitelbaum and Reps still work together to this day. Over a year ago I e-mailed Reps asking, "Why did the Synthesizer Generator fail to become mainstream?" Reps, from what I could tell, hated my question. My word choice was poor. I think he took the word "Fail" personally. Also, he claims that his company still uses the Synthesizer Generator internally for their static analysis tools, even though they no longer sell the Synthesizer Generator.
The only earlier approach I know of, superficially, is a 1971 paper linked to on Wikipedia [1] that I have not read. [1] http://en.wikipedia.org/wiki/Structure_editor#cite_note-hansen-0 On Thu, Apr 12, 2012 at 7:31 PM, Alan Kay <alan.n...@yahoo.com> wrote: > Hi John > > The simple answer is that Tom's stuff happened in the early 80s, and I was out > of PARC working on things other than Smalltalk. > > I'm trying to remember something similar that was done earlier (by someone > can't recall who, maybe at CMU) that was a good convincer that this was not > a great UI style for thinking about programming in. > > An interesting side light on all this is that -- if one could avoid > paralyzing nestings in program form -- the tile based approach allows > language building and extensions *and* provides the start of a UI for doing > the programming that feels "open". Both work at Disney and the later work > by Jens Moenig show that tiles start losing their charm in a hurry if one > builds nested expressions. An interesting idea via Marvin (in his Turing > Lecture) is the idea of "deferred expressions", and these could be a way to > deal with some of this. Also the ISWIM design of Landin uses another way to > defer nestings to achieve better readability. > > Cheers, > > Alan > > > ------------------------------ > *From:* John Zabroski <johnzabro...@gmail.com> > *To:* Florin Mateoc <fmat...@yahoo.com>; Fundamentals of New Computing < > fonc@vpri.org> > *Sent:* Thursday, April 12, 2012 3:59 PM > > *Subject:* Re: [fonc] Kernel & Maru > > 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 > > > > _______________________________________________ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
