[5] in java-interest
Re: Syntax of type casts
daemon@ATHENA.MIT.EDU (Jeremy Fitzhardinge)
Thu Apr 20 12:56:10 1995
From: jeremy@sour.sw.oz.au (Jeremy Fitzhardinge)
To: java-interest@java.Eng.Sun.COM
Date: Thu, 20 Apr 1995 18:00:48 +1000 (EST)
> I ran into the same problem. The compiler contains the following comment:
>
> * The parsing algorithm does NOT use any type information. Changes
> * in the type system do not affect the structure of the parse tree.
> * This restriction does introduce an ambiguity an expression of the
> * form: (e1) e2 is assumed to be a cast if e2 does not start with
> * an operator. That means that (a) - b is interpreted as subtract
> * b from a and not cast negative b to type a. However, if a is a
> * simple type (byte, int, ...) then it is assumed to be a cast.
This is a little contradictory, since it does use type information,
but only when it has its own keyword. I try to treat compound and
simple types consistently throughout. Your heuristic makes the
effective syntax of casts more complex. At the moment I make a
distinction between unary operators which could be binary and pure
unary ones, and change the behaviour based on that. That is:
(e1)!e2 // cast
(e1)(!e2) // cast
(e1)+e2 // add
(e1)(+e2) // cast
so the parse doesn't depend on what "e1" is at all.
What is the "correct" behaviour? All compilers should parse in a
consistent way, and that should be accurately specified. I'm
hesitant to copy your compiler implementation unless you say that
is the defined behaviour of the language.
> Anyway, a single pass compiler should be sufficient.
Do you mean, single pass parser?
A related query:
At the moment I treat "String" and "Object" as keywords to identify
the types, since this makes the compiler slightly more efficient
because the lexer can identify the strings faster than looking them
up in the symbol table. However, this prevents them from being
redefined. For example, this code would be invalid:
class X {
void foo() {
int Object;
}
};
or even:
private class String {
}
Is that valid code which should be allowed (but discouraged)?
Thanks,
J
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
