Current state of the art of point and qsort: 

point = (x y) { 
   Hash("x" = x, "y" = y) 
}
array = ({point 10 20} {point 30 40} {point 50 60})
say { {array:2}:"y" }

qsort = (L) {
   if {L == ()} { return () }
   pivot = {L:0}
   { qsort { filter {arg < pivot} {L:1:} } } + (pivot) + \
      { qsort { filter {arg >= pivot} {L:1:} } }
}

TimBL on the path search problem: 
http://lists.w3.org/Archives/Public/www-rdf-interest/2002Mar/0048OB

On the scoping, it seems as though lexical scoping is indeed the way to go and
allowing dynamic scoping too is probably pointless. Adding conditionals to
variables still seems like a good idea, noting that: 

   While the vast majority of prototype-based systems are based around
   interpreted and dynamically typed programming languages, it is important to
   point out that statically typed systems based around prototypes are
   technically feasible. The Omega programming language discussed in
   Prototype-Based Programming [1] is an example of such a system.
   - http://en.wikipedia.org/wiki/Prototype-based_programming

Of course, just what constitutes a type is a bit hard to say at the moment, and
how to refer to a type's name even harder. Clearly if the prototype links
correctly then that's enough, so I guess that's not too bad. One can use
block["proto"] for that link and hence block["proto"]["variables"] to do the
lookup there.

I'm still not sure about the cloning syntax. I don't like "new" as a keyword in
programming languages, but it seems to be quite standard. Python got this very
right with its calling, but that just can't be done in Pluvo with the prototype
model.

Now that scoping is pretty much impelemented, I'm wondering about let, and also
how let would work with the scoping. It'd be a low-level operation bypassing
env.bind, which is a bit of a shame. But nothing's going to really mess about
with ["variables"] anyway, so it shouldn't be a problem.

Setting a particular block to be the plant-base, to continue that metaphor,
will be kinda tricky--or at least a low level operation. It'll have to set
state that the interpreter can know about, probably in the interpreter itself
unless there's a special key for it in the codeblocks. Pretty necessary for the
prototypes though, and it could even have a nice funny name like "method"...

It'd be nice to introspect a codeblock to see which variables it's going to use
and then only set those in the closure variable bindings.

Person = (name) { 
   init = (name) { ... }
}

But then, funnily enough, the closed scoping created by method would actually
limit the ability to write to instance attributes. Though having said that, as
always, if a variable exists already in a higher scope then it'll be reset
there, so that's no problem. The methoding only applies to new variables within
a method.

Person = (name) { 
   # By being passed on the constructor, name is automatically an 
   # instance attribute

   method details () { 
      # Anything *set* in here, won't be visible externally
      say "Name: $name"
   }
}

john = { new Person "John Cowan" }
john.details
# Prints "Name: John Cowan"

method could even pass the current block, a la Python, so you could easily set
things by doing... hmm. obj.attr = something won't work unless . fernagles it
somewhat--which I suppose it easily can.

Documentation should be well integrated: 
http://www.erights.org/elang/tools/updoc.html

Let syntax in: 
http://ajaxian.com/downloads/presentations/eich-ajax-experience-2006/#slide31

Destructuring objects is very cool, too. Woah, datetime datatypes--cool! The
let syntax overused is a little annoying. Funny about the dispatch thing for
operator extensions.

* * *

Document tests: 

<!-- 
setup = "example"
-->
<pre>
say { 5 + 3 }
=> 8

say { 5 + 1 }
say { 5 + 2 }
say { 5 + 3 }
=> 6
=> 7
=> 8
</pre>

-- 
Sean B. Palmer, inamidst.com