search

djrieger / mjplusplus

A compiler for the MiniJava language
http://djrieger.github.io/mjplusplus/doc/doxygen/html/
6 stars 1 forks source link

Add missing AST classes for Binary/UnaryExpression #15

Closed djrieger closed 9 years ago

BigPeet commented 9 years ago

FYI:

Those methods will have to call the correct subclass.

BigPeet commented 9 years ago

Added classes for BinaryExpressions. I called them after the used operator (LessThan, Eq, NotEq,...) and also created classes for operators that aren't actually BinaryExpressions because that's how it was done before (it was possible to have a binary expression with the operator "{", for example).

EDIT: We could just drop every "invalid" BinaryExpression-class and assign invalid binary operators, like "^=" the class "Invalid". That would save us time when adding more functionality to BinaryExpressions (like evaluate or something), since we can ignore them. But I wasn't sure that it won't break the PrettyPrint, if I did that.

They can easily be created via a static method in BinaryExpressions.

ratefuchs commented 9 years ago

We don't generate binary expressions for invalid operators (the parser throws an error in that case) hence it cannot break PrettyPrint. Therefore, I think we should completely drop them (and we don't need a replacement).

BigPeet commented 9 years ago

Ok, I dropped them. If no one disagrees with the general design, I will do something similar for UnaryExpressions now.

BigPeet commented 9 years ago

Uhm, quick question:

In a simple implementation we would have Neg (-) and Not (!) as UnaryExpressions, that consist of the operator and a child-Expression. But currently a UnaryExpression can have any number of - and/or ! in front of them (any "--" will get caught by Parser, but "!-!-!!!!-x;" will get parsed as UnaryExpression).

Simply parsed as "!-!-!!!!-x;" would lead to a Not with a Neg child with a Neg child...etc.

What should we do about this? Would be cool if we could solve this at Wednesday.

Nidan commented 9 years ago

I'd prefer the current implementation, since it condenses any number of unary operators into a single vector. If we are going to split them we could abuse the fact that both operators require distinct types (!: bool -> bool, -: int -> int) and just count them, since once we find one the other one must not appear (semantic error). However there's one problem: We'll report this error as syntax error, which is too early. In any case we should condense runs of the same operator into a single object (including a count). (This leads to an easy optimization, since !!a == a and - -a == a are both true for any a.)