1

I am reading Modern Compiler Implementation In ML, and trying to do the compiler project (the tiger language).

In chapter 5, semantic analysis, it uses functional data structure for constructing symbol stable. So insert table key value will return a new table, instead of modify the existing table, and the old table is preserved when the function returns. So when type checking is done, the symbol table is still empty.

My question is, does it mean the symbol table is purely used for type checking? Because I've read this SO post, which says symbol table is also going to be used in code generation (I haven't gone that far yet).

If symbol table should be used after semantic analysis, should I use imperative data structure?

Any concrete example would be appreciated. :)

Community
  • 1
  • 1
齐天大圣
  • 1,169
  • 5
  • 15
  • 36

1 Answers1

2

No. You might want it for code generation, error/feedback reporting, and for linking.

Type checking just verifies the program isn't obviously insane. At the completion of checking, you may now want to generate intermediate code. The Java expression

  a+b

may be type checked, but when going to generate code it matters what the types of a and b are. You get different code depending on whether a and b are respectively numbers or strings or even different.

For reporting, it may be that during code generation and optimization, the compiler has an opinion about why it cannot make a certain desired result. In that case, it may wish to communicate the opinion to the user in his terms; often in terms of some named entity which contributes to the opinion. To do that, you need to retain ties from the intermediate representation back to the names in the symbol table.

Finally, you may have system of seperate compilation. If that is the case, the linkages between seperately compiled elements is usually done by use of names exported from the program by the compiler, to the linker. You can hardly link a call to "foo" if foo is defined in another compilation unit, unless the compiler and linker agree to name the linkage, well, "foo".

So no, you shouldn't throw the symbol table away.

Ira Baxter
  • 93,541
  • 22
  • 172
  • 341
  • I am really confused. When type checker returns from a scope, isn't that scope removed from the symbol table? When type checking is done, how can symbol table still hold informations about inner scopes? The book's exercise for semantic analysis is write a type checker `trans_prog: ast -> unit` which means the function returns nothing, and the book talks about functional symbol table at the beginning of the chapter, which i used since i use OCaml – 齐天大圣 Mar 13 '16 at 20:41
  • If you insist on following a really old style to symbol table construction in which scopes are perfectly nested, you'll get a story about how the compiler can push a new symbol table on a stack when it "enters" a lexically scoped region, and pop (destroy) it when leaving that region. If you agree with my arguments, you don't want to destroy it it any case. ... – Ira Baxter Mar 13 '16 at 21:05
  • ... If you look at modern languages (esp. those with various namespaces), you'll discover the mapping of scopes to code doesn't necessarily nest nicely with respect to the nesting syntax of the language. Now you need to have symbol table whose scopes come in and out of visibility depending on what part of the source text is being processed and all sorts of funny language rules (you should see C++!), and they aren't obviously (fully) lexically scoped. So you don't want to do push new/pop old symbol table anyway. – Ira Baxter Mar 13 '16 at 21:07
  • Better that you use a symobl map to associate names to types in certain context, and that rule for looking up a scope simply depends on the part of the program being processed. Scope still means, "what symbols are visible at a point (nee surrounding region)"; it may mean sets of symbol maps interrogated in complicated orders. – Ira Baxter Mar 13 '16 at 21:08