TC-1 FAQ

Translating escapes in the scanner (or not)

Escapes in string can be translated at the scanning stage, or kept as is. That is, the string "n" can produce a token STRING with the semantic value n (translation) or \n (no translation). You are free to choose your favorite implementation, but keep in mind that if you translate, you’ll have to untranslate later (i.e. convert n back to \n).

We encourage you to do this translation, but the other solution is also correct, as long as the next steps of your compiler follow the same conventions as your input.

You must check for bad escapes whatever solution you choose (see Lexical Specifications).

What is the chunks rule?

In the given code, we specify that a program is either exps or chunks.

In the Tiger language, a chunk is a set of declarations which work as a group, and must be processed together during static analysis. These can be handled in various ways: for instance, we could have a visitor which would go through the AST and generate chunks from appropriate declarations. Another method is to directly parse the declaration chunks, which is what we chose to do in our implementation.

What values can be represented by an int?

The set of valid integer values is the set of signed 32-bit integers in two’s complement, that is the integer interval \([-2^{31}, 2^{31}-1]\).

What values can be represented by an integer literal?

Although an integer value can be any number in \([-2^{31}, 2^{31}-1]\), it is however not possible to represent the literal \(-2^{31} (= -2147483648)\) for technical reasons. It is however possible to create an integer value representing this number.

To put it in a nutshell, in the following declarations the first one is not valid whereas the second one is:

/* invalid, produces a lexing error */
var i := -2147483648
/* valid, is correctly parsed */
var i := -2147483647 - 1

Bison reports type clashes

Bison may report type clashes for some actions. For instance, if you have given a type to "string", but none to exp, then it will choke on:

exp: "string";

because, unless you used %define variant, it actually means

exp: "string" { $$ = $1; };

which is not type consistent. So write this instead:

exp: "string" {};

Where is ast::Exp?

Its real definition will be provided with TC-2, so meanwhile you have to provide a fake. We recommend for a forward declaration of ast::Exp in libparse.hh.

Finding prelude.tih

When run, the compiler needs the file prelude.tih that includes the signature of all the primitives. But the executable tc is typically run in two very different contexts:

installed

An installed binary will look for an installed prelude.tih, typically in /usr/local/share/tc/. The cpp macro PKGDATADIR is set to this directory. Its value depends on the use of configure’s option --prefix, defaulting to /usr/local.

compiled, not installed

When compiled, the binary will look for the installed prelude.tih, and of course will fail if it has never been installed. There are two means to address this issue:

The environment variable TC_PKGDATADIR

If set, it overrides the value of PKGDATADIR.

The option --library-prepend/-p

Using this option you may set the library file search path to visit the given directory before the built-in default value. For instance tc -p /tmp foo.tig will first look for prelude.tih in /tmp.

Must import be functional?

As mentionned before, the compiler needs the file prelude.tih, then you need handle import.