[6] in java-interest
Re: Syntax of type casts
daemon@ATHENA.MIT.EDU (Arthur van Hoff)
Thu Apr 20 13:01:48 1995
Date: Thu, 20 Apr 1995 09:42:07 -0700
From: Arthur.Vanhoff@Eng.Sun.COM (Arthur van Hoff)
To: java-interest@java.Eng.Sun.COM
Hi Jeremy,
> > 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.
I'll raise this issue in the next language meeting. Until then you
should assume that javac is the definitive answer.
> 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)?
Object and String are not keywords and can be used as identifiers.
The above code should be perfectly legal. Note that there is
no ambiguity in redefining class String because class String is
really called java.lang.String.
Have fun,
Arthur van Hoff (avh@eng.sun.com)
http://java.sun.com/people/avh/
Sun Microsystems Inc, M/S UPAL02-301,
100 Hamilton Avenue, Palo Alto CA 94301, USA
Tel: +1 415 473 7242, Fax: +1 415 473 7104
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
