[E-Lang] Distress (was: the return of `return')
Mark S. Miller
Wed, 20 Jun 2001 12:50:27 -0700
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
>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.
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
(Btw, the upcoming change to Hydro falls under "fixing something that's
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.