On Fri, May 20, 2011 at 11:09 AM, Alan Kay <alan.n...@yahoo.com> wrote: > This is nice! > > Smalltalk actually got started by thinking about a way to make a child's > Logo-like language with objects and pattern matching that could express its > own operating system and environment. > > It is very tricky to retain/maintain readability (so the first Smalltalk was > also an extensible language not just semantically but syntactically). > > With a tile language, this is really worth thinking about, since using tiles > suggests ways to extend both the form and the meaning of the tiles.
My current thinking is that macros are *graphical*, not *source* transformations. You can create your own tiles for the language which render into hygenic macros. They are represented in source as simple message dispatch. For example, choosing a particularly ugly bit of JavaScript syntax: var ForBlockMacro = imports.macros.ForBlockMacro; var foo = function() { var i; ForBlockMacro(function() { i=0; }, function() { return i < 5; }, function() { i+=1; }, function() { /* body */ }); } This is the "underlying" syntax for the macro. But the ForBlockMacro function (which is a first class object in JavaScript) can have an asTile() method which returns a more attractive visual representation in the tile editor; in fact, the representation could elide all the 'function' and 'return' nastiness of the raw syntax and display (traditionally) as: for ( i=0 ; i < 5 ; i+=1 ) { /* body */ } My current plan is to finess the "multiple views" issue (discussed in 3.4 of http://labs.oracle.com/self/papers/programming-as-experience.html) by representing objects as 3d polyhedra. The "front" view might be the nice cleaned up tile macro, but you should be able to "rotate" the tile to see the low level source, and then rotate it again to see the object corresponding to the actual widget displaying the source, etc. So, "one object, many views". I've built the current system on a very flexible operator precedence grammar, so there's no reason I *couldn't* allow the user to flexibly extend the base grammar. But that increases the conceptual effort necessary to understand the system -- I have to understand the expanded language before I can understand the code I'm looking at. The macro system I describe above has the nice property that you don't *have* to understand the macro or the grammar of the new if statement. It's enough to look at the desugared version: ForBlockMacro(function() { i=0; }, function() { return i < 5; }, function() { i+=1; }, function() { /* body */ }); and the implementation of ForBlockMacro: ForBlockMacro = function(initBlock, condBlock, incrBlock, bodyBlock) { initBlock(); while (condBlock()) { bodyBlock(); incrBlock(); } }; ForBlockMacro.asTile() = ....; This seems (to me) a preferable way of understanding what the new tile does. But I'm open to other ideas on this front. (And yes, JavaScript's syntax isn't lovely. But I'm interested in what I can do with what I've got.) --scott -- ( http://cscott.net ) _______________________________________________ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep