Tiger 2006

Akim has been helped by:

Assistants

Claire Calméjane, Fabrice Hesling, Marco Tessari, Tristan Lanfrey

Deliveries were:

Stage	Submission
TC-0	Wednesday, 2004-02-04 12:00
TC-1	Sunday, 2004-02-08 12:00
TC-2	Sunday, 2004-03-07 12:00
TC-3	Rush from 2004-03-19 19:00 to 2004-03-21 19:00
TC-4	Sunday, 2004-04-11 19:00
TC-5	Sunday, 2004-06-06 12:00
TC-6	Sunday, 2004-06-27 12:00
TC-7	Sunday, 2004-07-11 12:00
TC-89	Thursday, 2004-07-29 12:00

Criticisms about Tiger 2006 include:

The interface of symbol::Table should be provided

On the one hand side, we meant to have students implement it from scratch so we shouldn’t provide the header, and on the other hand, the rest of the (provided) code expects a well defined interface, so we should publish it! The result was confusion and loss of time.

The problem actually disappeared: Tiger 2007 no longer depends so heavily on scoped symbol tables.

Some examples are incorrectly rejected by the reference compiler

The Tiger reference manual does not exclude sick examples such as:

let
  type rec = {}
in
  rec {}
end

where the type rec escapes its scope since the type checker will assign the type rec to the let construct. Given the suggested implementation, which reclaims memory allocated by the declarations when closing the scope, the compiler dumps core.

The new implementation, tested with 2005b, copes with this gracefully: types are destroyed when the AST is. This does not cure the example, which should be invalid IMHO. The following example, from Arnaud Fabre, amplifies the problem.

let
  var box :=
    let
      type box = {val: string}
      var box := box {val = "42\n"}
    in
       box
    end
in
  print(box.val)
end

TC-5 is too hard a stage

This is a recurrent complaint. We tried to make it easier by moving more material into earlier stages (e.g., scopes are no longer dealt with by the TranslateVisitor: the Binder did it all).

Multiple inheritance is not demonstrated

There are several nice opportunities of factoring the AST using multiple inheritance. Tiger 2007 uses them (e.g., Escapable, Bindable etc.).

The coding style for types is inconsistent

The sources are ambivalent wrt to pointer and reference types. Sometimes type *var, sometimes type* var. Obviously the latter is the more “logical”: the space separates the type from the variable name. Unfortunately the declaration semantics in C/C++ introduces pitfalls: int* ip, i is equivalent to int* ip; int i;. That is why I, Akim, was using the type *var style, and resisted to expressing the coding style on this regard. The resulting mix of styles was becoming chronic: defining a rule was needed… In favor of type* var, with the provision that multiple variable declarations are forbidden.

More enthusiasm from the assistants

It has been suggested that assistants should show more motivation for the Tiger Project. It was suggested that they were not enough involved in the process. For Tiger 2007, there are no less than 10 Tiger assistants (as opposed to 4), and two of them are co-maintaining the reference compiler. Assistants will also be kept more informed of code changes than before.

More technical lectures

Some regret when programming techniques (e.g., object functions, #include <functional>) are not taught. My (Akim’s) personal opinion is that students should learn to learn by themselves. It was decided to more emphasize these goals. Also, oral examinations should be ahead the code submission, and that should ensure that students have understood what is expected from them.

Formal definition of Booleans

The Tiger language enjoys well defined semantics: a given program has a single defined behavior… except if the value of a & b or a | b is used. To fix this issue, in Tiger 2007 they return either 0 or 1.

Amongst other noteworthy changes, after five years of peaceful existence, the stages of the compiler were renamed from T1, T4 etc. to TC-1, TC-4… EPITA moved from “periods” (P1, P2…) to “trimesters” and they stole T1 and so forth from Tiger.