What does it have to do with thinking about programming? Are you referring to editing an AST directly? On Apr 12, 2012 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
