[IAEP] Turtles All The Way Down

[C. Scott Ananian]

On Fri, May 20, 2011 at 11:09 AM, Alan Kay <alan.nemo at 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 )