First draft of translation document

[Neal Gafter]

On Tue, May 18, 2010 at 6:02 PM, Rémi Forax <forax at univ-mlv.fr> wrote:
>> Language features are not to be defined by the features of the VM.
>
> Agree in general, but not in this specific case.
> The frame object or any equivalent data structure should be managed by the
> VM,
> it's a stack allocated data structure. There is no need of an object header
> or a vtable
> for such data structure.

These frame objects are not stack allocated.  They must be managed by
the GC.  Thus, an object header is required.

>> This is not proposing a pass-by-reference language feature.  It is
>> describing a way to compile code that references ordinary mutable
>> variables.  Mutable variables are definitely part of and in the spirit of
>> Java.
>
> Threse aren't that ordinary because you have to create a new keyword or if
> you prefer a new semantics
> for those kind of variables.

Neither is needed.  While project lambda may elect to have a new
keyword for other reasons, it is not necessary.  Neither are new
semantics required.

> final locals variables aren't translated to fields but final fields. Final
> fields haven't the same semantics
> than ordinary fields hence the keyword "final".
> I agree that final local variable aren't currently described in the spec and
> should but that doesn't solve the problem
> of the semantics of shared local variables.

Agreed: final locals should follow the semantics of final fields, and
mutable locals should follow the semantics of mutable fields.