[7] in java-interest
Re: Syntax of type casts
daemon@ATHENA.MIT.EDU (Arthur van Hoff)
Thu Apr 20 13:52:55 1995
Date: Thu, 20 Apr 1995 10:39:18 -0700
From: Arthur.Vanhoff@Eng.Sun.COM (Arthur van Hoff)
To: java-interest@java.Eng.Sun.COM
Hi Jeremy,
Here are some more notes on the language definition.
> > * 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.
What I meant to say is that a parse tree can be created without
knowledge of identifier scope and types. This helps a lot if
you want to build a development environment which supports syntax
directed editing, syntax coloring, etc.
However the exact type of each node in the parse tree can't be
determined until the scope and type of identifiers is established.
The current compiler makes the following passes over the parse tree:
(1) construct a parse tree for each method from the source
(2) check and assign types, fix the type of each parse tree node
(3) inline final methods and variables
(4) generate code
Note that it is usually impossible to do all passes for all
methods in a class in strict sequence. You usually end up loading a
class file or parsing a source file for another class that is
needed. The compiler incrementally gathers the information needed to
compile a class, once it has finished the first three passes
for a class it will do the code generation pass and generate
a class file.
> (e1)!e2 // cast
> (e1)(!e2) // cast
> (e1)+e2 // add
> (e1)(+e2) // cast
The problem with this is that (long)-4 will be considered as a
subtract, not a cast. I decided that this was not the right
thing to do since it is obviously a cast.
Another area that you will find confusion is the interpretation
of expression like a.b.c. The way it works is that if "a" is
defined as an identifier in the current scope it then it means
"field c of field b of a". If a is not defined as an identifier,
then it is assumed that a must be a class, in which case it
means "field c of static variable b in class a". If a is not
a class, then "a.b" must be a class in which case it means
"static variable c in class b in package a". This is also not
adequatly described in the language spec.
I argued for using '::' to seperate classes and packages names
instead of '.' but this proposal got nuked by our club of C++
haters. Anyway, just letting you know.
I want to emphasize again that we encourage you to build Java
compilers, but we want to make absolutely sure that all compilers
use the same language definition. We want to avoid creating new
Java dialects. In order to achieve this goal we will tighten the
language spec where needed (thanks for your feedback), and we will
be building an exhaustive test suite (this will take some time
to get done properly) for compiler verification. Ideas on how
to improve this process would be appreciated.
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
