On Apr 11, 2012 2:53 PM, "Shawn Morel" <[email protected]> wrote: > > 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
Racket's GUI is not very portable or well-designed. (I can't remember the oddities. Use it and compare approaches to Squeak and Newspeak.) Smalltalk's GUI is platform independent but that can be seen as a drawback emanating from the use of bitblt as the basic graphics abstraction morphs depend on. Although in theory morphs should be highlevel enough... > > > 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
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
