Re: [fonc] Kernel Maru
In response to a long-dormant thread ... Fisher's thesis seems to have surfaced on the web: http://reports-archive.adm.cs.cmu.edu/anon/anon/usr/ftp/usr0/ftp/scan/CMU-CS-70-fisher.pdf -- Dirk On Tue, Apr 10, 2012 at 11:34 AM, Monty Zukowski mo...@codetransform.comwrote: If anyone finds an electronic copy of Fisher's thesis I'd love to know about it. My searches have been fruitless. Monty On Tue, Apr 10, 2012 at 10:04 AM, Alan Kay alan.n...@yahoo.com wrote: ... Dave Fisher's thesis A Control Definition Language CMU 1970 is a very clean approach to thinking about environments for LISP like languages. He separates the control path, from the environment path, etc. ... ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Kernel Maru
On Mon, Mar 25, 2013 at 11:18 PM, Dirk Pranke dpra...@chromium.org wrote: In response to a long-dormant thread ... Fisher's thesis seems to have surfaced on the web: (hopefully I did not just violate some form of copyright ...) -- Dirk ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Kernel Maru
That's it -- a real classic! Cheers, Alan From: Dirk Pranke dpra...@chromium.org To: Fundamentals of New Computing fonc@vpri.org; mo...@codetransform.com Sent: Monday, March 25, 2013 11:18 PM Subject: Re: [fonc] Kernel Maru In response to a long-dormant thread ... Fisher's thesis seems to have surfaced on the web: http://reports-archive.adm.cs.cmu.edu/anon/anon/usr/ftp/usr0/ftp/scan/CMU-CS-70-fisher.pdf -- Dirk On Tue, Apr 10, 2012 at 11:34 AM, Monty Zukowski mo...@codetransform.com wrote: If anyone finds an electronic copy of Fisher's thesis I'd love to know about it. My searches have been fruitless. Monty On Tue, Apr 10, 2012 at 10:04 AM, Alan Kay alan.n...@yahoo.com wrote: ... Dave Fisher's thesis A Control Definition Language CMU 1970 is a very clean approach to thinking about environments for LISP like languages. He separates the control path, from the environment path, etc. ... ___ 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
Re: [fonc] Kernel Maru
This is great! Dirk - how did you find it? Duncan. On Tue, Mar 26, 2013 at 6:09 AM, Alan Kay alan.n...@yahoo.com wrote: That's it -- a real classic! Cheers, Alan -- *From:* Dirk Pranke dpra...@chromium.org *To:* Fundamentals of New Computing fonc@vpri.org; mo...@codetransform.com *Sent:* Monday, March 25, 2013 11:18 PM *Subject:* Re: [fonc] Kernel Maru In response to a long-dormant thread ... Fisher's thesis seems to have surfaced on the web: http://reports-archive.adm.cs.cmu.edu/anon/anon/usr/ftp/usr0/ftp/scan/CMU-CS-70-fisher.pdf -- Dirk On Tue, Apr 10, 2012 at 11:34 AM, Monty Zukowski mo...@codetransform.comwrote: If anyone finds an electronic copy of Fisher's thesis I'd love to know about it. My searches have been fruitless. Monty On Tue, Apr 10, 2012 at 10:04 AM, Alan Kay alan.n...@yahoo.com wrote: ... Dave Fisher's thesis A Control Definition Language CMU 1970 is a very clean approach to thinking about environments for LISP like languages. He separates the control path, from the environment path, etc. ... ___ 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 -- Duncan. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Kernel Maru
I was browsing through this thread looking for a reference to something else and happened to see the reference to that paper and thought to Google it again :). -- Dirk On Tue, Mar 26, 2013 at 10:35 AM, Duncan Mak duncan...@gmail.com wrote: This is great! Dirk - how did you find it? Duncan. On Tue, Mar 26, 2013 at 6:09 AM, Alan Kay alan.n...@yahoo.com wrote: That's it -- a real classic! Cheers, Alan -- *From:* Dirk Pranke dpra...@chromium.org *To:* Fundamentals of New Computing fonc@vpri.org; mo...@codetransform.com *Sent:* Monday, March 25, 2013 11:18 PM *Subject:* Re: [fonc] Kernel Maru In response to a long-dormant thread ... Fisher's thesis seems to have surfaced on the web: http://reports-archive.adm.cs.cmu.edu/anon/anon/usr/ftp/usr0/ftp/scan/CMU-CS-70-fisher.pdf -- Dirk On Tue, Apr 10, 2012 at 11:34 AM, Monty Zukowski mo...@codetransform.com wrote: If anyone finds an electronic copy of Fisher's thesis I'd love to know about it. My searches have been fruitless. Monty On Tue, Apr 10, 2012 at 10:04 AM, Alan Kay alan.n...@yahoo.com wrote: ... Dave Fisher's thesis A Control Definition Language CMU 1970 is a very clean approach to thinking about environments for LISP like languages. He separates the control path, from the environment path, etc. ... ___ 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 -- Duncan. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Kernel Maru
The first ~100 pages are still especially good as food for thought Cheers, Alan From: Duncan Mak duncan...@gmail.com To: Alan Kay alan.n...@yahoo.com; Fundamentals of New Computing fonc@vpri.org Cc: mo...@codetransform.com mo...@codetransform.com Sent: Tuesday, March 26, 2013 10:35 AM Subject: Re: [fonc] Kernel Maru This is great! Dirk - how did you find it? Duncan. On Tue, Mar 26, 2013 at 6:09 AM, Alan Kay alan.n...@yahoo.com wrote: That's it -- a real classic! Cheers, Alan From: Dirk Pranke dpra...@chromium.org To: Fundamentals of New Computing fonc@vpri.org; mo...@codetransform.com Sent: Monday, March 25, 2013 11:18 PM Subject: Re: [fonc] Kernel Maru In response to a long-dormant thread ... Fisher's thesis seems to have surfaced on the web: http://reports-archive.adm.cs.cmu.edu/anon/anon/usr/ftp/usr0/ftp/scan/CMU-CS-70-fisher.pdf -- Dirk On Tue, Apr 10, 2012 at 11:34 AM, Monty Zukowski mo...@codetransform.com wrote: If anyone finds an electronic copy of Fisher's thesis I'd love to know about it. My searches have been fruitless. Monty On Tue, Apr 10, 2012 at 10:04 AM, Alan Kay alan.n...@yahoo.com wrote: ... Dave Fisher's thesis A Control Definition Language CMU 1970 is a very clean approach to thinking about environments for LISP like languages. He separates the control path, from the environment path, etc. ... ___ 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 -- Duncan. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Kernel Maru
Absolutely ditto. In order to understand Kernel and $vau, I tried reconstructing it using my favourite prototyping language (Lua). Far from complete, but enough to define 'define', 'if' etc.; for me pretty amazing that it works at all. Of course it's easier, since Lua already supports higher order functions, fast hash tables, garbage collection etc... but definitely worthwhile from a learning point of view, since the code can be short and concentrate mostly on the important stuff. For the curious: https://github.com/grrrwaaa/catsinboxes/blob/master/fexpr_vau.lua I think it might only be another weekend's work to add the missing parts and write a parser for a full Kernel-on-Lua(JIT). Graham On Apr 11, 2012, at 4:57 PM, Michael Fogus wrote: Then pick your favourite superfast-prototyping programming language and build McCarthy's evaluator in it. (This step is not optional if you want to understand properly.) Then throw some expressions containing higher-order functions and free variables at it, figure out why it behaves oddly, and fix it without adding any conceptual complexity. I couldn't agree with this approach more. In my own attempt at this activity (http://fogus.me/fun/lithp/) I learned more about the McCarthy model, its history, and limitations than any paper I'd read before or since. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Kernel Maru
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
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
Re: [fonc] Kernel Maru
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
Re: [fonc] Kernel Maru
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
Re: [fonc] Kernel Maru
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
Re: [fonc] Kernel Maru
If anyone finds an electronic copy of Fisher's thesis I'd love to know about it. My searches have been fruitless. The title is not the same, but maybe these are variants of the same paper? http://dl.acm.org/author_page.cfm?id=81100550987coll=DLdl=ACMtrk=0cfid=76786786cftoken=53955875 Also, I no longer have access to ACM digital library, so I can't post the PDFs. The thesis link is bibliographic only. The survey paper is available as PDF, so I grabbed it. If you'd like a copy, let me know. Eugene ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Kernel Maru
This one seems to be available as a technical report as well: http://infolab.stanford.edu/TR/CS-TR-65-20.html Monty On Wed, Apr 11, 2012 at 4:44 AM, Alan Kay alan.n...@yahoo.com wrote: One more that is fun (and one I learned a lot from when I was in grad school in 1966) is Niklaus Wirth's Euler paper, published in two parts in CACM Jan and Feb 1966. This is a generalization of Algol via some ideas of van Wijngaarten and winds up with a very Lispish kind of language by virtue of consolidating and merging specific features of Algol into a more general much smaller kernel. The fun of this paper is that Klaus presents a complete implementation that includes a simple byte-code interpreter. This paper missed getting read enough historically (I think) because one large part of it is a precedence parsing scheme invented by Wirth to allow a mechanical transition between a BNF-like grammar and a parser. This part was not very effective and it was very complicated. So just ignore this. You can use a Meta II type parser (or some modern PEG parser like OMeta) to easily parse Euler directly into byte-codes. Everything else is really clear, including the use of the Dijkstra display technique for quick access to the static nesting of contexts used by Algol (and later by Scheme). Cheers, Alan From: Monty Zukowski mo...@codetransform.com To: Fundamentals of New Computing fonc@vpri.org Sent: Tuesday, April 10, 2012 9:20 PM 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
Re: [fonc] Kernel Maru
The survey paper is just a survey. Dave's thesis is how to make all the control structure by extending a McCarthy like tiny kernel. Still gold today. Cheers, Alan From: Eugene Wallingford walli...@cs.uni.edu To: Fundamentals of New Computing fonc@vpri.org Sent: Wednesday, April 11, 2012 9:02 AM Subject: Re: [fonc] Kernel Maru If anyone finds an electronic copy of Fisher's thesis I'd love to know about it. My searches have been fruitless. The title is not the same, but maybe these are variants of the same paper? http://dl.acm.org/author_page.cfm?id=81100550987coll=DLdl=ACMtrk=0cfid=76786786cftoken=53955875 Also, I no longer have access to ACM digital library, so I can't post the PDFs. The thesis link is bibliographic only. The survey paper is available as PDF, so I grabbed it. If you'd like a copy, let me know. Eugene ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Kernel Maru
Yes, the work was done at Stanford (and Bill McKeeman did a lot of the systems programming for the implementation). The CACM article is a cleaned up version of this. Cheers, Alan From: Monty Zukowski mo...@codetransform.com To: Fundamentals of New Computing fonc@vpri.org Sent: Wednesday, April 11, 2012 9:06 AM Subject: Re: [fonc] Kernel Maru This one seems to be available as a technical report as well: http://infolab.stanford.edu/TR/CS-TR-65-20.html Monty On Wed, Apr 11, 2012 at 4:44 AM, Alan Kay alan.n...@yahoo.com wrote: One more that is fun (and one I learned a lot from when I was in grad school in 1966) is Niklaus Wirth's Euler paper, published in two parts in CACM Jan and Feb 1966. This is a generalization of Algol via some ideas of van Wijngaarten and winds up with a very Lispish kind of language by virtue of consolidating and merging specific features of Algol into a more general much smaller kernel. The fun of this paper is that Klaus presents a complete implementation that includes a simple byte-code interpreter. This paper missed getting read enough historically (I think) because one large part of it is a precedence parsing scheme invented by Wirth to allow a mechanical transition between a BNF-like grammar and a parser. This part was not very effective and it was very complicated. So just ignore this. You can use a Meta II type parser (or some modern PEG parser like OMeta) to easily parse Euler directly into byte-codes. Everything else is really clear, including the use of the Dijkstra display technique for quick access to the static nesting of contexts used by Algol (and later by Scheme). Cheers, Alan From: Monty Zukowski mo...@codetransform.com To: Fundamentals of New Computing fonc@vpri.org Sent: Tuesday, April 10, 2012 9:20 PM 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
Re: [fonc] Kernel Maru
This thread is a real treasure trove! Thanks for all the pointers Alan :) A nice feature of Smalltalk (which has been rarely used outside of a small group) is a collection of tools that can be used to create an entirely different language within it and then launch it without further needing Smalltalk. This was used 3 or 4 times at PARC to do radically different designs and implementations for the progression of Smalltalks Could you elaborate more here? How might this compare to some of the work happening with Racket these days? thanks shawn Cheers, Alan From: Florin Mateoc fmat...@yahoo.com To: Fundamentals of New Computing fonc@vpri.org Sent: Wednesday, April 11, 2012 7:20 AM Subject: Re: [fonc] Kernel Maru 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
Re: [fonc] Kernel Maru
Take a look at the use of the System Tracer in the Back to the Future paper. It is an example of such a tool (it is a bit like a garbage collector except that it is actually a new system finder -- it can find and write out just the objects in the new system to make a fresh image). Cheers, Alan From: Shawn Morel shawnmo...@me.com To: Alan Kay alan.n...@yahoo.com; Fundamentals of New Computing fonc@vpri.org Cc: Florin Mateoc fmat...@yahoo.com Sent: Wednesday, April 11, 2012 11:52 AM Subject: Re: [fonc] Kernel Maru This thread is a real treasure trove! Thanks for all the pointers Alan :) A nice feature of Smalltalk (which has been rarely used outside of a small group) is a collection of tools that can be used to create an entirely different language within it and then launch it without further needing Smalltalk. This was used 3 or 4 times at PARC to do radically different designs and implementations for the progression of Smalltalks Could you elaborate more here? How might this compare to some of the work happening with Racket these days? thanks shawn Cheers, Alan From: Florin Mateoc fmat...@yahoo.com To: Fundamentals of New Computing fonc@vpri.org Sent: Wednesday, April 11, 2012 7:20 AM Subject: Re: [fonc] Kernel Maru 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
Re: [fonc] Kernel Maru
Here's something else by David Fisher that I found online: http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA240565 *Title : *Languages Beyond Ada and Lisp *Descriptive Note : *Final technical rept. 22 Sep 1988-30 Jun 1991 *Corporate Author : *INCREMENTAL SYSTEMS CORP PITTSBURGH PA *Personal Author(s) : *Fisher, David A. ; Mundie, David A. *Pagination or Media Count : *505 *Abstract : *This report summarizes the goals, concepts, research development, and conclusions of the Languages Beyond Ada and Lisp effort. The effort was born from the frustrations with progress in software engineering and with language design in particular. The goal of the effort, informally called Prism, was to devise ways to extend programming languages to encompass more of the total environment, and to remove the myriad barriers to cooperation among the pieces of software environments. The Prism effort has generated a wide variety of new ideas and approaches to solving traditional problems along the whole spectrum of formal systems. The new methods and approaches taken together have come to be called informalism. Informalism involves automated reasoning systems that are capable of dealing with even exploiting incompleteness and inconsistency. Informalism offers a potential for interdisciplinary computational interoperability previously unattainable. It's quite long, and I've only started flipping through it, but there might be something interesting there. -- Duncan. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Kernel Maru
Hi Julian (Adding to Ian's comments) Doing as Ian suggests and trying out variants can be an extremely illuminating experience (for example, BBN Lisp (1.85) had three or four choices for what was meant by a lambda closure -- three of the options I remember were (a) do Algol -- this is essentially what Scheme wound up doing 15 years later, (b) make a private a-list for free variables, (c) lock the private a-list to the values of the free variables at the time of the closure). I suggest not trying to write your eval in the style that McCarthy used (it's too convoluted and intertwined). The first thing to do is to identify and isolate separate cases that have to be taken care of -- e.g. what does it mean to eval the function position of an expression (LISP keeps on evaling until a lambda is found ...). Write these separate cases as separately as possible. Dave Fisher's thesis A Control Definition Language CMU 1970 is a very clean approach to thinking about environments for LISP like languages. He separates the control path, from the environment path, etc. You have to think about whether special forms are a worthwhile idea (other ploys can be used to control when and if arguments are evaled). You will need to think about the tradeoffs between a pure applicative style vs. being able to set values imperatively. For example, you could use Strachey's device to write loops as clean single assignment structures which are actually tail recursions. Couple this with fluents (McCarthy's time management) and you get a very clean non-assignment language that can nonetheless traverse through time. Variants of this idea were used in Lucid (Ashcroft and Wadge). Even if you use a recursive language to write your eval in, you might also consider taking a second pass and writing the eval just in terms of loops -- this is also very illuminating. What one gets from doing these exercises is a visceral feel for great power with very little mechanics -- this is obtained via mathematical thinking and it is obscured almost completely by the standard approaches to characterizing programming languages (as things in themselves rather than a simple powerful kernel with decorations). Cheers, Alan From: Ian Piumarta piuma...@speakeasy.net To: Julian Leviston jul...@leviston.net Cc: Fundamentals of New Computing fonc@vpri.org Sent: Monday, April 9, 2012 8:58 PM Subject: Re: [fonc] Kernel Maru Dear Julian, On Apr 9, 2012, at 19:40 , Julian Leviston wrote: Also, simply, what are the semantic inadequacies of LISP that the Maru paper refers to (http://piumarta.com/freeco11/freeco11-piumarta-oecm.pdf)? I read the footnoted article (The Influence of the Designer on the Design—J. McCarthy and Lisp), but it didn't elucidate things very much for me. Here is a list that remains commented in my TeX file but which was never expanded with justifications and inserted into the final version. (The ACM insisted that a paper published online, for download only, be strictly limited to five pages -- go figure!) %% Difficulties and omissions arise %% involving function-valued arguments, application of function-valued %% non-atomic expressions, inconsistent evaluation rules for arguments, %% shadowing of local by global bindings, the disjoint value spaces for %% functions and symbolic expressions, etc. IIRC these all remain in the evaluator published in the first part of the LISP-1.5 Manual. I have to say that all of these papers and works are making me feel like a 3 year old making his first steps into understanding about the world. I guess I must be learning, because this is the feeling I've always had when I've been growing, yet I don't feel like I have any semblance of a grasp on any part of it, really... which bothers me a lot. My suggestion would be to forget everything that has been confusing you and begin again with the LISP-1.5 Manual (and maybe Recursive Functions of Symbolic Expressions and Their Computation by Machine). Then pick your favourite superfast-prototyping programming language and build McCarthy's evaluator in it. (This step is not optional if you want to understand properly.) Then throw some expressions containing higher-order functions and free variables at it, figure out why it behaves oddly, and fix it without adding any conceptual complexity. A weekend or two should be enough for all of this. At the end of it you will understand profoundly why most of the things that bothered you were bothering you, and you will never be bothered by them again. Anything that remains bothersome might be caused by trying to think of Common Lisp as a dynamically-evaluated language, rather than a compiled one. (FWIW: Subsequently fixing every significant asymmetry, semantic irregularity and immutable special case that you can find in your evaluator should lead you to something not entirely unlike the tiny evaluator
Re: [fonc] Kernel Maru
On Tue, Apr 10, 2012 at 2:34 PM, Monty Zukowski mo...@codetransform.comwrote: If anyone finds an electronic copy of Fisher's thesis I'd love to know about it. My searches have been fruitless. The title is not the same, but maybe these are variants of the same paper? http://dl.acm.org/author_page.cfm?id=81100550987coll=DLdl=ACMtrk=0cfid=76786786cftoken=53955875 Also, I no longer have access to ACM digital library, so I can't post the PDFs. -- Duncan. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Kernel Maru
Yes, it looks like this is it. $37 for a PDF. Thanks! CONTROL STRUCTURES FOR PROGRAMMING LANGUAGES by FISHER, DAVID ALLEN, Ph.D., Carnegie Mellon University, 1970, 215 pages; AAT 7021590 On Tue, Apr 10, 2012 at 11:54 AM, Duncan Mak duncan...@gmail.com wrote: On Tue, Apr 10, 2012 at 2:34 PM, Monty Zukowski mo...@codetransform.com wrote: If anyone finds an electronic copy of Fisher's thesis I'd love to know about it. My searches have been fruitless. The title is not the same, but maybe these are variants of the same paper? http://dl.acm.org/author_page.cfm?id=81100550987coll=DLdl=ACMtrk=0cfid=76786786cftoken=53955875 Also, I no longer have access to ACM digital library, so I can't post the PDFs. -- Duncan. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Kernel Maru
It doesn't look like any of the libraries near me hold it, but here you go: http://www.worldcat.org/title/control-structures-for-programming-languages/oclc/4335223referer=brief_results http://www.worldcat.org/title/control-structures-for-programming-languages/oclc/82223524referer=brief_results Looks like people the hunt for this PDF has been on since 2003 ;-) http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-November/070082.html -- Duncan. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Kernel Maru
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
Re: [fonc] Kernel Maru
I started on this yesterday when I received your email Ian, and I just wanted to say thank you (and Alan, too) very much for responding. I'm still interested in what your thoughts on Kernel are (and Arc, too, actually) sometime if you have a couple of moments to pen them... Julian On 11/04/2012, at 7:54 AM, Ian Piumarta 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
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
Re: [fonc] Kernel Maru
Dear Julian, On Apr 9, 2012, at 19:40 , Julian Leviston wrote: Also, simply, what are the semantic inadequacies of LISP that the Maru paper refers to (http://piumarta.com/freeco11/freeco11-piumarta-oecm.pdf)? I read the footnoted article (The Influence of the Designer on the Design—J. McCarthy and Lisp), but it didn't elucidate things very much for me. Here is a list that remains commented in my TeX file but which was never expanded with justifications and inserted into the final version. (The ACM insisted that a paper published online, for download only, be strictly limited to five pages -- go figure!) %% Difficulties and omissions arise %% involving function-valued arguments, application of function-valued %% non-atomic expressions, inconsistent evaluation rules for arguments, %% shadowing of local by global bindings, the disjoint value spaces for %% functions and symbolic expressions, etc. IIRC these all remain in the evaluator published in the first part of the LISP-1.5 Manual. I have to say that all of these papers and works are making me feel like a 3 year old making his first steps into understanding about the world. I guess I must be learning, because this is the feeling I've always had when I've been growing, yet I don't feel like I have any semblance of a grasp on any part of it, really... which bothers me a lot. My suggestion would be to forget everything that has been confusing you and begin again with the LISP-1.5 Manual (and maybe Recursive Functions of Symbolic Expressions and Their Computation by Machine). Then pick your favourite superfast-prototyping programming language and build McCarthy's evaluator in it. (This step is not optional if you want to understand properly.) Then throw some expressions containing higher-order functions and free variables at it, figure out why it behaves oddly, and fix it without adding any conceptual complexity. A weekend or two should be enough for all of this. At the end of it you will understand profoundly why most of the things that bothered you were bothering you, and you will never be bothered by them again. Anything that remains bothersome might be caused by trying to think of Common Lisp as a dynamically-evaluated language, rather than a compiled one. (FWIW: Subsequently fixing every significant asymmetry, semantic irregularity and immutable special case that you can find in your evaluator should lead you to something not entirely unlike the tiny evaluator at the heart of the original Maru.) Regards, Ian ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
