test case good/core019.jl
Rasmus Knutsson
with the explanatory comment:
// this is a little tricky
// on the right hand side, i refers to the outer i
int i = i + 7;
I tested similar cases in Java, C and C# when I was working on the
type checker, since I could not find any judgement on the matter in
the Javalette spec, and it seems to me that in these languages a
statement
type var = expr;
is executed in the following order:
1. declaration of var as type
2. evaluation of expr
3. assignment of the value of expr to var
For example, when receiving the code (where x is previously
undeclared)
int x = x + 1;
the Java compiler will complain about an uninitialized variable, not
an undeclared one.
I also compiled and ran the file in C, getting the output
1
78
77
4532620
76
4532627
76
4
76
Obviously i here refers to the uninitialized inner variable.
Is Javalette different from other C derivatives in this respect, and
in that case why?
Björn von Sydow
yes, Javalette differs from C and Java in its treatment of local variables, so I understand that you wonder.
There are at least three different issues involved. C and Java make different decisions on two of them, and Javalette has a combination which is not identical with either of these.
1. The first question to consider has to do with initialization of local variables. Here one can think of (at least) three approaches:
- C's choice: It is not compulsary for the programmer to initialize local vars and no default values are assigned. If variables are used before they have been assigned a value, the result is unpredictable; whatever bit patterns that happen to reside in the memory cells are used as values. We see the effect when you run the function in C.
We just don't think that this is a good language design choice.
- Java's choice: The programmer *must* initialize local vars. This seems to be a better design, but then the compiler must check that all variables are really initialized (a language rule should be checked by the compiler). Java compilers do so, using a conservative approximation, but we thought it would be a bit too much to require this of you.
- Javalette's choice: Uninitialized variables get default values. This is a simple and reasonable rule that is easy to implement.
2. The next question is whether it is allowed to redeclare a variable in an inner scope, where a variable with the same name already is declared in an outer scope. C permits this, while Java does not. For Javalette, we have chosen to follow C's path; we don't claim strong arguments for this, but a decision has to be made.
3. The third question is whether a statement of the form
int x = expr;
is just syntactic sugar for
int x;
x = expr;
or is a separate statement form.
Java and C take the first approach, while Javalette takes the second. In this latter view, the declaration is not complete until we have evaluated the initial value in the right hand side and assigned it to the variable. Thus the occurrence of i in the right hand side must refer to a variable already declared in an outer scope, since the new, or current, variable declaration is not yet in effect. Again, the arguments for one or the either are not strong, but if one does allow nested scopes, one must make the choice (Java doesn't have to); core019 forces you to think of the consequences. A somewhat surprising choice has been made, perhaps, but if you presumed the other choice, you only have to make a very small change to your implementation.
I agree that this choice is not obvious from the project description. There may be other such unclear points; that's why we have the general rule that the programs in dictionary good act as part of language specification (see the last paragraph in the introduction to section 1 (just before 1.1) of the project specification).
Best regards
Björn
Rasmus Knutsson
very easy for me to change my implementation, I just wanted to check
that we were at the same page first.