Re: inconsistencies with __return ejector

On Sun, 2008-03-23 at 12:11 -0700, Mark Miller wrote:
> On Sun, Mar 23, 2008 at 8:23 AM, Toby Murray
> <[email protected]> wrote:
> >  I'm writing to bring up the issue of the __return ejector and some
> >  potential inconsistencies that surround it.
> >
> >  The essential potential problem is that most new programmers to E will
> >  treat "return" as a statement and thus expect to be able to use it
> >  pervasively.

> It has been discussed before, rather endlessly if I recall. For each
> construct that one might think would bind __return, we need to decide
> whether it does or not. No matter what we decide, programmers will
> often expect the other and get tripped up.

I can't see why programmers would ever expect not to be able to use
return, especially if they come from an imperative (e.g.  OO)
programming background, as so many of us do. I understand that "return"
is not used in  match blocks because "match"  is at a lower level of
abstraction to ordinary method definitions. That said, I often find
myself using "match" in E code. Perhaps a higher-level construct could
be defined that expands to "match" but enables the use of "return"
within it, in  order to maintain consistency. Given that "when" is also
expanded, I can't see why "return" can't be defined here too.

Also, given the "programmers need to make explicit what each block
evaluates to and, thus, leaks to its caller" idea, it appears that
putting return in place for all such blocks is not only the most
consistent thing to do, but also the safest.

Are there other arguments against doing so, other than "it breaks levels
of abstraction" (e.g. for "match") as above?

> You have identified the two most problematic: match clauses and when.
> 
> * On match clauses, I also often trip up in the way you describe, even
> though I defined the behavior.

This seems telling. What was the rationale behind the current behaviour?

>  Also, the problem's worse than you
> describe. 

This looks like quite a nasty potential pitfall.

> 
> * when clauses used to operate the way this page editor expected.
> Again, either way will violate expectations, because expectations cut
> both ways.

Yes. Given that you can't make everyone happy, then it might be best to
go with a less subjective measure, rather than "expectations".
"Consistency" is perhaps a good objective test to apply here. People may
be unhappy but if the behaviour is consistent, then it's easier to
justify.


>  However, the block on the right side of a when is thought
> of more like a control structure block than like a normal object.

Indeed -- particularly when using the "easy-when" syntax. 

All this said, the strongest argument in favour of pervasive "return" is
still the "potential for authority leakage" one.

I remember something in your thesis about using "->" and "<-" as markers
to a programmer in order to help them reason about the affects of
concurrency on their code. I see "return" as a similar thing, but for
access control rather than concurrency control.


> 
> In order to enable control structures to be written in the language
> (the Smalltalk-like "lambda-args" sugar), control-structure-like
> blocks cannot implicitly rebind __return. We wish to take "when" out
> of the E language grammer, making "when" no longer be a keyword, and
> to redefine it using lambda-args. This would help ensure that other
> eventual control abstractions can be written in the language as well.
> 

Sorry. I failed to understand any of that. Is this a solution to the
problem, or will it just make it worse by introducing other block types
for which the "return" debate will resurface?

Cheers

Toby