[news.eclipse.technology.imp] Re: IMP support for multplei ASTs

["Robert M. Fuhrer" <rfuhrer@xxxxxxxxxxxxxx>]

Mattias Felt wrote:
> Hi,
>
> The IDE that we are working on supports a proprietary DSL (partly influenced 
> by languages like Pascal and Ada).
>
> The required semantic analysis needed is in the first stage is type checking 
> and scope analsysis (the language support inheritance and nested methods 
> etc), but in a near future we want
> to add warnings for unused (unrefernced) variables etc.  The analsysis is 
> needed to make it possible to do the correct color highlighting, symbol 
> linking etc in the UI, but we can antecipate
> that the users wants more direct feedback by the editor to avoid round-trips 
> to the build system.

Ok, that's fairly standard/sensible stuff.

For name binding and type-checking, it depends on the particulars of
the language as to whether the requisite analysis is completely local
or not. If it's entirely local, then you may be able to perform the
analysis on the AST, augmented/decorated with some simple data
structures. This is the case for the trivial demo language "LEG" we
supply with IMP. If it's not (as it is with Java and C/C++), then you
may want/need something a little more sophisticated.

One option is to produce an "object file" that provides a dictionary
of declared entities in a suitable form at the front of the "object
file", so that clients need not rifle through the whole file when
searching for that info.

Another option is to produce a more global database of declared
entities and references. For this, we'd advocate using the PDB.

As for editor highlighting and the like, the normal scenario is to
use the AST for information that drives views that are directly
associated with an open editor buffer. Other, more global, views
would again appeal to a global database, such as can be created
and persisted using the PDB.

Finally, if you need to perform a whole-program analysis, such as
global data-flow or type analysis, again, the PDB and its data
structures and operators should prove useful.

> So as I understand from your description the scenario is:  each 
> CompilationUnit has its corresponding AST, each AST is then condensed into a 
> "Symbol table" that is stored using the PDB API
> [The AST is after this obsolete and can be released / deleted ? ].  The 
> semantic analysis is then performed [ in the background] against the PDB 
> API.

Yes, that's right.

> ( It has been some years since I took a Compiler Construction Course, 
> noticed that the Dragon book still is used  :-) , but I recall something of 
> a Concret Syntax Tree (CST) involved in
> semantic analysis, but perhaps that is just another terminology)

Actually, the term "concrete syntax" usually refers to a syntax tree
that retains *all* of the original source info, including whitespace,
comments, tokens for "binary" syntactic entities (e.g. modifiers that
are either present or not), and so on. The purpose of the abstraction
in an abstract syntax tree is partly to remove some of this in order
to provide a simpler API for analyses to use.

> I just took a quick look, but could not find much documentation or sample 
> code about PDB, but perhaps I can find this on the home of "Rascal"?

You're right that there's not much documentation yet. I'll ping Jurgen,
who's leading the PDB development, to see what we can put in place.

--
Cheers,
  -- Bob

--------------------------------
Robert M. Fuhrer
Research Staff Member
Programming Technologies Dept.
IBM T.J. Watson Research Center

IDE Meta-tooling Platform Project Lead (http://www.eclipse.org/imp)
X10: Productive High-Performance Parallel Programming (http://x10.sf.net)