BinaryExpr.action Ints, all Ops

Transcription

1 BinaryExpr.action Ints, all Ops - a.isint() && b.isint() works for a few Ops, others? - The general concept is expression compatibility, which also computes a result type, so let s write code like that: OpSTO opsto = (OpSTO) symtab.lookup(opstring); if (!BinaryExpr.elaborate(result, a, opsto, b)) {... } return a.isint() && b.isint() boolean elaborate(exprsto result, STO a, OpSTO op, STO b) { if (op.compatible(a, b)) { // a, b in ParamList later result.puttype(op.resulttype(a, b)); return true; } return TypeValues.integerType Bodies of new operations merely contain code that they replaced better modularity and abstraction! (Still int/+, but now easily expandable to others)

2 Coercion and Overloading Overloading is having one name for two different operators: int x; float y; x = x + x; /* + for ints */ y = y + y; /* + for reals */ Coercion (or casting) converts a value from one type to another: y = x + y; /* val retrieved from x coerced to float so can be added to y */ y = ((float) x) + y; // this is equivalent float t1 = (float) x; // compiler produces hidden var y = t1 + y; Similarities outweigh the differences with regard to convenience versus confusion

3 Explained by Subtyping Review: A type is A set of values A set of operations on those values Rules for their combination Type S is a subtype of T if an S always behaves like a T, but sometimes T could behave unlike an S Cats are animals, but not all animals are cats All ints are like reals, but not all reals are like ints Think of this as an is-a relationship Statically, in a programming language, type S is a subtype of T if: S contains only values of T S supports all operations of T (but perhaps more) Example The ints contain only reals (1, 2,...), The ints support all real operations (+, *,...) Ints support extra operations like DIV, MOD

4 Automatic Coercion & Overloading Subtype behavior is what allows safe automatic operator overloading int x; float y; x = x + x; // + for ints +: int x int --> int y = y + y; // + for reals +: float x float --> float y = y + x; // + for reals, x is coerced to float first 1. Pick operation with smallest inclusive type 2. Coerce value to type of operation

5 E + E with Coercion & Overloading Expr ::= Expr:e1 Op:op Expr:e2 {: RESULT = BinaryExpr.action(e1, op, e2); :} Operator first operand second operand result type * numeric numeric smallest numeric type including both operands

6 How is Our Old Code Affected? // Only code in type class changes: clients are stable! boolean elaborate(exprsto result, STO a, OpSTO op, STO b) { if (op.compatible(a, b)) { // a, b in ParamList later result.puttype(op.resulttype(a, b)); return true; } boolean PlusMinusMulOpType::compatible(Type a, Type b) { return (a.isint() && b.isint()); } a.isnumeric() && b.isnumeric() Type PlusMinusMulOpType::resultType(Type a, Type b) { return TypeValues.integerType; // doesn t hold for divide! } smallestinclusivetype(a, b)

7 How Handle Other Grammar Rules? P ::= D ';'S D ::= D ';'D D ::= ID ':'T T ::= integer real boolean E ::= ID INTLIT REALLIT BOOLLIT E ::= E '+'E E ::= E '<'E S ::= S ';'S S ::= ID ':='E S ::= IF E THEN S

8 What You Can Do Now (Phase I) Add remaining Type class operations Extend ExprSTO s to query type properties, also := boolean VarSTO::assignable(STO other) { return this.m_type.assignable(other.type()); } Can treat assignment like binary operator: In CUP file or action(): opsto = symtab.lookup( := ); In check: op.compatible(a, b); // no resulttype, though Test, Test, Test syntax-directed Program to the specification and interface to aid clarity, robustness, and reuse

9 Modular Error Handling boolean elaborate(exprsto result, STO a, OpSTO op, STO b) { if (opsto.iscompatible(a, b)) result.settype(opsto.resulttype(a, b)); return true; else { opsto.reporterror(a, b); // Error also dependent on operator result.settype(errortype.typeonerror(typevalues.integertype)); return false; } } Avoid cascading messages; guessing type is hard Keep error-handling from pervading compiler Introduce ErrorType, subclass of Type? Natural extension, but how should it behave?

10 Conceptualizing Errors Compiler has to behave well outside the specification Extend normal specs to include error behavior Operator first operand second operand result type * numeric numeric smallest numeric type including both operands non-numeric numeric Error Type numeric non-numeric non-numeric non-numeric

11 ErrorType is Stealth Internal Type class ErrorType extends Type { // error message already printed, play nice boolean iserror() { return true; } boolean isint() { return true; } boolean isreal() { return false; } // dicey boolean isbool() { return true; }... String tostring() { return "ERROR"; } // should never print! } Oberon example: VAR x, y : INTEGER; VAR b : BOOLEAN; BEGIN x := (x + b) + y; x := (x + b) + y + b END. This method is is inferior. Instead, have ErrorType return false to to everything except iserror(). With this approach, ErrorType causes every check to to fail, in in a cascade. To surpress cascading errors, then, modify the error printer to to not print error types. (You might want to to have a debug mode that does print them.)

12 Syntax-Directed Testing PROGRAM ArithTest VAR x, y : INTEGER; r, s : REAL; b, c : BOOLEAN; BEGIN (* assignments here only to make program syntactically correct *) x := x + y; (* no error, expression is type INTEGER *) r := r + s; (* no error, expression is type REAL *) r := x + r; (* no error, expression is type REAL *) r := r + x; (* no error, expression is type REAL *) r := x + b; (* error, numeric expected, got BOOLEAN *) r := b + x; (* error, numeric expected, got BOOLEAN *) r := r + b; (* error, numeric expected, got BOOLEAN *) r := b + r; (* error, numeric expected, got BOOLEAN *) (* might report two errors *) x := b + c (* error, numeric expected, got BOOLEAN *) END.