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
