[E-Lang] Distress (was: the return of `return')

[Mark S. Miller]

E's answers seem to be like Algol 68's:

At 12:10 PM Wednesday 6/20/01, Bill Frantz wrote:
>Algol 68 supplied an answer to what control structures return:
>
>if (only) returned the value of the block or EMPTY (of type VOID) when the
>block was not executed.

I didn't understand this sentence.

>if-else returned the value of the block which was executed.

Same as E.

>select/case returned the value of the case block executed.  

Same as E.

>(No, it didn't
>have C's error-prone fall-thru case syntax.)

Same as E.

>while/for/do returned EMPTY.  (Norm Hardy, Charlie Landau, and I thought it
>might be interesting to have them return an array of values, one element
>for each value produced by the repeated evaluation of the block.)

E has "while" and "for", but no "do".  If "while" or "for" exits by 
completion, then it evaluates to null.  If it exits with "break()", then it 
also evaluates to null.  If it exits with "break(expr)", then the expr is 
evaluated and the loop evaluates to the value of this expression.

If you want a collection of answers, it's easy enough to accumulate them 
yourself.

>functions/blocks returned the value of their last statement.

For blocks, same as E.

For functions and method bodies, same as E modulo the coercion by E's 
return-value-guard.  I take it that's the only controversy on the table here.


                                     Distress


I'm distressed that much of the conversation so far is still treating E as a 
new blank-slate language.  That's how we lost openCOLA as an E user.  The 
changes which lost openCOLA were genuine improvements, but if I had it to do 
over again I'd give up these improvements and keep openCOLA.

We currently have 5 or 6 companies using or planning to use E.  For such 
changes to be worth doing it must either be reasonably upwards compatible 
for actual programs (perhaps via automated conversion), be fixing something 
that's unacceptably broken, or be addressing some other compelling need.  I 
don't know for sure that none of these proposals satisfy these enabling 
conditions, but I find it striking that no one thought to address things in 
these terms.

(Btw, the upcoming change to Hydro falls under "fixing something that's 
unacceptably broken".)

Note that I am not saying above "strict upward compatibility for possible 
programs".  At some point we will be saying that, or a reasonable 
approximation, but not until sometime after we're feature complete for 1.0.

My take: Our syntax is good enough, but we're dying on our missing features: 
reviving the comm system, switching to a modified Hydro, persistence, 
installation, compiler, auditors, user-defined PassByCopy, confinement, 
first-class abstraction of vats, asynch abstractions of I/O devices, 
debugging, distributed debugging, ENative, resource controls, CapIDL & EROS 
integration, Una, etc...

I believe every single one of these issues is higher priority that further 
futzing around with the syntax.


        Cheers,
        --MarkM