Transparancy

[Stephen Colebourne]

On 7 July 2010 19:26, Brian Goetz <brian.goetz at oracle.com> wrote:
>> - this is still scoped to the lambda
>
> Yes, that's true.  In fact, a better way to think about these lambda
> expressions is that they are really "SAM expressions".  They are often more
> compact than CICE (since the target type can be inferred) but lambdas do not
> (at this time) stand alone.

Fine. My concern is conceptual integrity.

Simplified SAMs has conceptual integrity, but requires local 'return'
(not 'yield') and a syntax that actually looks like a simplified SAM.
That means parameters in round brackets and no arrow symbol. ie. the
strawman syntax was good. Its also vital for there to be a hook,
something that the eye can easily see that is used to indicate where
the 'return' will return to. Both CICE and FCM explored this area,
with FCM treating 'this' lexically simply because this is a new
language feature and it is what is most useful (SAM class lambdas are
not especially useful and are a confusing distraction.

A second conceptual integrity is "full closures", where 'return' is
used for long-returns, 'this' is lexical, there might be no
local-returns, and the syntax looks nothing whatsoever like a SAM. The
BGGA proposals explored this area. While I see some manouvering to
allow for this (or maybe just control abstraction) in the future, the
latest proposal is insufficient to be useful for this in the future.
Just scoping 'this' locally completely breaks any form of control
abstraction, and the use of the latest syntax blocks a likely syntax
for control abstraction.

Your reply appears to indicate that the team's thinking is the former
approach - simpler SAMs. If so, then this should be made crystal
clear, and all design should focus on that space. Essentially I'm
saying that the team should mostly ignore the control abstraction case
- that should be thought of as a completely different language feature
(implementable via another closure type, or macros, or only in a
limited way via some other way such as a 'throws return' combined
keyword). The only concern is not to use a syntax that would confuse
in the future.

Unfortunately, the current document follows much of simplified SAMs
but inserts the weird 'yield' for no logical reason (given the
arguments above) and uses a syntax that isn't appropriate for
simplified SAMs. Once the team gets back to a core CICE-like worldview
of simpler SAMs as a solid starting point, its then much easier to
take a single opinion on the pros and cons of SAM classes and lexical
'this', and a sensible syntax tends to just drop out.

> It is indeed *more* like CICE (and therefore an inner class), it is really
> something in between.  The quibbling over the semantics of return are a
> reflection of trying to force lambdas to either be exactly like inner
> classes or something completely new.  The reality is that they are somewhere
> in the middle.
Unfortunately, I struggled to understand this part. Here's the
question - In what way are they "something in the middle". Why are
they /not/ just simplified SAMs? What else are you trying to achieve?
(Its OK to have something else - like lexical 'this' ;-)

> Using "return" now complicates our ability to provide
> nonlocal control flow in the future.
No it doesn't, as you've got non-lexical 'this'. And a new keyword
'yield' that is only usable in some scopes. Please stop trying to
allow for the control flow feature in this way and focus on making the
best simpler SAM solution! We can deal with control flow if and well
it is felt to be a real issue (I suspect it will never come up).

Stephen