Should type-information be transferred to the Interpreter? How?

[Per Fredelius]

So far I've made the Interpreter object independent (sharing no
objects) except for the abstract tree, with the interpreter. The
further I go the more I begin to think that this might not be the
thing to do? Are you supposed to share the environment in between type
checking and interpretation?

[Per Fredelius]

I guess the way to go in case environment is shared is to figure out
some way to either (1) "bind" the abstract tree to the environment
scopes or (2) figure out how to derive the position in the scopes when
going through the abstract tree in the interpreter. Meaning that the
interpreter does not create scopes but rather picks them up as the
type checker left them.

[Per Fredelius]

I'm talking java here. Maybe not that many working in java...

[Arnar Birgisson]

In general you shouldn't need the type information during
interpretation. The environments might be similar, but the type
checking environment maps variables to types, while during
interpretation the environment will map them to values.

Assuming you use some sort of an object to represent values, there
will probably be some type information there, saying wether the value
is a boolean, an int or a double. However, since you know the program
you are interpreting did type-check, you can allow yourself to skip
some checks (e.g. in the case of Java you can safely cast a generic
value object to a type specific subclass).

cheers,
Arnar

[Aarne Ranta]

Hello,

One may need type information in an interpreter and certainly in a compiler that has type-specific arithmetic and loading operations. (Hint: as Arnar says, this is not needed in Lab3.)

The smoothest way to provide it is to let the type checker annotate the trees with types. This was described in Lecture 9, under heading "Type annotations":

    Exp annotExp (Env env, Exp exp) =
      typ := inferExp env exp
      return typed<typ>(exp)

For this, one more constructor is needed in the abstract syntax. It can be added directly to the abstract syntax module. But it can also be defined in BNFC with

  internal ExpTyped ::= Type "(" Exp ")" ;

In BNFC, "internal" means that  the rule is not used in parsing. But notice that the syntax chosen here is the same as in type casts in C++, and it can be seen when the annotated tree is printed, e.g. in an error message.

To make the type checker save the information, the types must be changed slightly, so that

  checkC, inferC

for any category C also return a new tree of type C - a tree to which the annotations have been added.

When doing this, the interpretation/code generation environment only needs to have the values/addresses, and no type checking is needed at interpretation/code generation time.

Regards

  Aarne.

[klondike]

El 28/02/11 09:56, Aarne Ranta escribió:

> Hello,
>
> One may need type information in an interpreter and certainly in a
> compiler that has type-specific arithmetic and loading operations.
> (Hint: as Arnar says, this is not needed in Lab3.)

Speak for your self, Haskell has type specific arithmetic So if you want
different types for Int and double you have to care about that.
Obviously this may not be the case of Java, not sure though.

[Aarne Ranta]

I see what you mean. In lab3 you do need different value constructors, see "Central types" in Lecture 8.

But when interpreting an arithmetic op, let's say plus, you can pattern match on the values of the operands (because it is call by value ;-)

    case (val1,val2) of

                (Vint x, Vint y) -> Vint $ x + y

                (Vdouble x, Vdouble y) -> Vdouble $ x + y

and you don't need type information of expressions.

Regards

  Aarne.

[Arnar Birgisson]

As Aarne wrote later, you need to construct the values in the
interpreter with their particular type, but this information does not
have to come from the type checker (which would complicate things
somewhat). The choice of constructors is simply taken when you
interpret literal expressions. E.g.

evalExpr env (EInt x) = (env, VInt x)

(assuming evalExpr has the type Env -> Expr -> (Env, Value) and EInt
is the name of the Expr rule in your grammar for integer literals.)

cheers,
Arnar

[Per Fredelius]

When using the internal pragma in java mode bnfc doesn't generate a
visitor method for VisitSkel for that construct. This causes an error
when building. There should probably be a place holder method. Bug?

> > On Sun, Feb 27, 2011 at 23:15, Per Fredelius <per.fredel...@gmail.com>

[Per Fredelius]

Oh, I see now that this "error" seems to be eclipse specific. Eclipse
seems to want to force all visitor methods to be implemented, java
does not.
Huh. It seems a bit unsafe to not force all abstract methods to be
implemented...

[Daniel Wogelberg]

Hi,
when are the exams expected to be graded? It seems to take long time..
 
> Date: Mon, 28 Mar 2011 11:53:27 -0700
> Subject: Re: Should type-information be transferred to the Interpreter? How?
> From: per.fr...@gmail.com
> To: proglang-c...@googlegroups.com

[Arnar Birgisson]

Hi Daniel,

Everything has been handed in with the student administration, so any day now.

cheers,
Arnar