[IAEP] Turtles All The Way Down

[mokurai at earthtreasury.org]

On Fri, May 20, 2011 2:28 pm, C. Scott Ananian wrote:
> 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.

Seymour Papert also proposed creating an environment in which learning
math would be as easy as learning ordinary language. Smalltalk has a
number of kinds of number and shape objects, but I have not seen much else
in the way of mathematical objects. I am trying to go through various
subjects to extract the ideas that preschoolers can absorb, and create
materials to encourage them to explore those ideas.

Caleb Gattegno and Ken Iverson did a fair amount on algebra, using
Cuisenaire rods and APL respectively.

Don Cohen has done Calculus by and for Young People

I have made a start on symmetry groups, using variations on children's
block toys.

Elementary set theory using Venn diagrams was done long ago.

But there is so much more.

>> 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:

I would like to be able to create a set of blocks implementing the
symmetry group of a simple shape such as an equilateral triangle. This
case is generated by a 120 degree rotation and a reflection, giving six
elements in all.

Similarly I would like to be able to do modular addition, subtraction,
multiplication, and division in finite fields, and the and and or
functions or union and intersection on lattices.

Does your system accommodate this?

> 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 at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep


-- 
Edward Mokurai
(默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر
ج) Cherlin
Silent Thunder is my name, and Children are my nation.
The Cosmos is my dwelling place, the Truth my destination.
http://wiki.sugarlabs.org/go/Replacing_Textbooks