this should not refer to the lambda

[Alex Blewitt]

On 21 Feb 2010, at 23:49, Neal Gafter wrote:

> On Sun, Feb 21, 2010 at 3:25 PM, Alex Blewitt <alex.blewitt at gmail.com> wrote:
>>> I don't know what you mean by "break the language model".
>> 
>> I don't know any construct in Java - or for that matter, other languages - where the
>> RHS of an assignment expression can refer to the lHS of the assignment expression,
>> as  you proposed in http://mail.openjdk.java.net/pipermail/lambda-dev/2010-February/000833.html
> 
> I didn't propose anything for the assignment expression.  I proposed
> something about the initialization in a variable declaration.

The argument still stands for initialisation in the Java language. There are no other variable initialisation types where the RHS can refer to the LHS. So instead of the 'simple assignment', it would be 'local variable declaration statements', and 'definite assignment', which states that a variable must have a value before it is referenced. It would be a challenge (though not impossible) to weave in the requirements for allowing this to be violated for initialisation of lambdas.

http://java.sun.com/docs/books/jls/second_edition/html/defAssign.doc.html#25979

I'm more familiar with ML (and Prolog) than Haskell and Lisp, but clearly they allow functions to be defined recursively. The difference is that the function definition is not strictly assignment; this example is from Wikipedia:

http://en.wikipedia.org/wiki/ML_(programming_language)

fun fac 0 = 1
  | fac n = n * fac (n-1)


Although this uses = in the syntax, it's not really assignment (you can't assign 'fac' twice, obviously). The Haskell version appears to be equivalent:

http://en.wikipedia.org/wiki/Haskell_(programming_language)

-- using recursion
factorial 0 = 1
factorial n = n * factorial (n - 1)

Here, 'factorial' is not actually being assigned twice. The fact that it's possible to write both these statements in a different language does not necessarily imply that the assignment (or initialisation) operators in Java should be able to handle the syntax of this.

> For examples see Haskell, or lisp's letrec, to pick two obvious
> candidates.  Just because you don't know about it doesn't mean it's a
> bad idea.

That's true, but I do know about it in other languages; if not necessarily the ones you provided.

>> As I understand it (and I may be wrong; please correct me if so), the 'transparency' argument requires:
> 
> Transparency is a litmus test.  It suggests, not requires.

A litmus test results in a binary result. It detects the acidic or alkaline conditions. It does not suggest or require that the solution be acidic or alkaline.

http://en.wikipedia.org/wiki/Litmus_test

> That's not the case.  The advantages of transparency accrue (or the
> disadvantages accrue) for each element that satisfies it (or fails to
> satisfy it).

For some, the advantages and disadvantages are reversed.

Alex