Re: ASTs and Type Check Analysis

On Aug 23, 6:11 pm, Hans-Peter Diettrich <DrDiettri...@aol.com> wrote:


In the simple example I provided, I know my end result (without
optimizations) would result in the following:


PUSHI 2
PUSHI 3
PUSHI 6
IMUL
IADD
PRINTI


Had the code been optimized by the compiler at compile time, the
resulting code would have been:


PUSHI 20
PRINTI


But I'm not at the "optimization" stage just yet; that is still to
come.


The goal presently is to understand how I should handle type
assignments to nodes within the AST tree.


As you see in my example, I had several nodes that were
CASTIntegerLiteral, but I question if that is the right approach or
not. In my opinion, the parser which is creating the AST tree should
not be responsible for determining the number type of Integer, Real,
or Long. A simple CASTNumberLiteral node seems more appropriate to me
and allow the type analysis check phase when traversing the tree
determine whether its Integer, Real, or Long right?


If my thought process is correct, then when my type check visitor
traverses the nodes of the tree, certain AST nodes need to be
decorated with type information, such as Integer, Real, or Long. When
examining expressions such as binary ones, both sides to the operation
need to be examined to make sure they both conform to the same type,
and if not handle that appropriately.


For example, "PRINT 2.5*3" would throw an exception with type mismatch
because 3 would be evaluated to integer where-as 2.5 would be viewed
as a real. A different method could be that it would turn the
statement into "PRINT 2.5*3.0" so that both sides are viewed as real
values for the computation to happen correctly.


In this case during the binary expression type check, the right side
of the operation would become the child of another another AST node
that handles converting the result into a given type by an internal
function call. So the tree would resemble the following:


CASTFunctionCall
    +- CASTSimpleName
            +- Name: PRINT
    +- CASTExprList
            +- List Size: 1
            +- CASTBinaryExpr
                    +- Operation: '*'
                    +- CASTNumberInteger
                            +- Number: 2.5
                    +- CASTFunctionCall
                            +- CASTSimpleName
                                    +- Name: INT2REAL
                            +- CASTExprList
                                    +- List Size: 1
                                    +- CASTNumberLiteral
                                            +- Number: 3


I suppose what I see is that I could use a class object called
CASTType with derived classes for Integer, Long, Real, and String.
Each derived class would contain information about the size of the
type for storage purposes and/or reference pointer for strings in the
constant pool.


So each CASTNumberLiteral and CASTBinaryExpr objects would be assigned
a CASTType object during the type check phase. Each CASTFunctionCall
I also believe would get assigned a type as well in keeping with the
assembly example above.


Am I on the right track?


> The efforts may depend on the actual brand of BASIC you're targeting.
> When a variable can hold any type at any time, depending on the last
> assignment, or depending on the last declaration passed in control
> flow, a type analysis IMO will be quite fruitless.
>
> Otherwise, when the type of a variable is known at compile time, you
> have the usual choice of up-/downcasting to the next applicable type in
> expression evaluation. That's easy when numerical and textual (string)
> data cannot be mixed. Otherwise you'll have to specify what the result
> of e.g. 1+"1" shall be - it might be "11", 2, or some even more weird
> result. That's one of the common pitfalls also in Java :-(

Return to the comp.compilers page.
Search the comp.compilers archives again.