Re: inconsistencies with __return ejector

I recently had an idea for What To Do About __return -- only if we  
were to redesign E's syntax, as this isn't really compatible with the  
C-style syntax.

Instead of putting the 'protection' (against value leakage) in 'to',  
put it in SeqExpr.

Sequences throw away all but the last subexpression's value; we just  
need to define the syntax so it's easy to throw out the last value too.

For example, this 0.9-style E program

var i := 0
def get() {
   println("Retrieving value")
   return i
}
def inc() {
   println("Incrementing value")
   i += 1
}

would instead be written as something like (this is *not* an  
especially good syntax; it's just to demonstrate the concept)

var i := 0
def get() {
   « println("Retrieving value") »
   i
}
def put() {
   « println("Incrementing value")
     i += 1
   »
}

The idea is that «...» means "execute for side effect or bindings".

Two expressions in sequence (line break or ; ) *not* enclosed in  
«...» would be a syntax error.

A syntax like this would make "functional" code simpler to write, as  
neither 'return' nor a result guard (as in non-easy-return syntax) is  
needed.
to getSize() { size }
def square(x) { x ^ 2 }

There is no irregularity in method/function blocks vs. other blocks.

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>