I understand that AST-editing and even things like TurleScript are cumbersome for many reasons, and that "trapped" is a good way to describe their limitations. But automatically generating IDEs doesn't require the IDEs it generates require rigid user inputs and modal interaction.
If anything, playing Devil's Advocate, I would call the act of trying to build an IDE from a grammar a "perverted curiosity", and argue that heuristics for each language work just as well and probably better than anything a fancy algorithm could generate. Not losing the forest for the trees, either. The root question is: You've got a bunch of problem-oriented languages, how do you expose tools for them? John Regehr criticized the FONC project for lacking an answer here [1] [2]. I wrote a rebuttal [3]. [1] Can Simplicity Scale? http://blog.regehr.org/archives/663 [2] It's All About Interfaces http://blog.regehr.org/archives/666 [3] http://lambda-the-ultimate.org/node/4436#comment-69040 On Thu, Apr 12, 2012 at 8:56 PM, Alan Kay <alan.n...@yahoo.com> wrote: > Hi John > > Yes you are right about Teitelbaum ... > > As far as "Hansen" the time period is right -- but I think there were > several such ... the one I remember seeing was "syntax driven ..." There > was a feeling of being trapped ... > > Cheers, > > Alan > > > ------------------------------ > *From:* John Zabroski <johnzabro...@gmail.com> > *To:* Alan Kay <alan.n...@yahoo.com>; Fundamentals of New Computing < > fonc@vpri.org> > *Sent:* Thursday, April 12, 2012 5:34 PM > > *Subject:* Re: [fonc] Kernel & Maru > > 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
