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 <[email protected]>
>To: Alan Kay <[email protected]>; Fundamentals of New Computing
><[email protected]>
>Cc: Florin Mateoc <[email protected]>
>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 <[email protected]>
>> To: Fundamentals of New Computing <[email protected]>
>> 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 <[email protected]>
>> To: Fundamentals of New Computing <[email protected]>
>> 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 <[email protected]> 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
>> > [email protected]
>> > http://vpri.org/mailman/listinfo/fonc
>> _______________________________________________
>> fonc mailing list
>> [email protected]
>> http://vpri.org/mailman/listinfo/fonc
>>
>>
>>
>> _______________________________________________
>> fonc mailing list
>> [email protected]
>> http://vpri.org/mailman/listinfo/fonc
>>
>>
>> _______________________________________________
>> fonc mailing list
>> [email protected]
>> http://vpri.org/mailman/listinfo/fonc
>
>
>
>
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
