I would have to dust off my copy of the SG thesis, but I am pretty sure Tom made allowances for free-form syntax editing as well. The major drawback to using free-form syntax editing is that you get fewer guard conditions when deciding grammatical correctness, and so error reporting and recovery is harder. When that becomes harder, a lot of the "for free" stuff loses some of its value, too, since you can't do live updates to computations if you can't lex the thing that is supposed to represent the computation.
I've always thought the major question, for me at least, is how well does such an approach adapt to increasingly sophisticated type systems? Reps type checking scheme simply enforces very old school type checking, the kind that enforces data type representation. Consider a very sophisticated type system like Scala, which combines a kitchen sink worth of features. Alternatively, consider Gilad Bracha's Pluggable Types which allows for unbounded type system chicanery. But those questions are neither here nor there, since for FONC all we would really want (I would think) is "Ruby on Rails for Problem-Oriented Languages". On Thu, Apr 12, 2012 at 8:35 PM, Alan Kay <alan.n...@yahoo.com> wrote: > Yes, that was part of Tom's work ... > > Cheers, > > Alan > > ------------------------------ > *From:* John Zabroski <johnzabro...@gmail.com> > *To:* Fundamentals of New Computing <fonc@vpri.org>; Alan Kay < > alan.n...@yahoo.com> > *Sent:* Thursday, April 12, 2012 4:46 PM > > *Subject:* Re: [fonc] Kernel & Maru > > 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
