Refining of AST field types

Unfortunately AST does not know graph-, set-, and list-fields. This means, that although existing AST-modules of compilers may be read by , cannot find graph and set fields in the data definition. However, set and graph fields can be introduced with two tricks:

1.

The user declares the type of a scalar attribute to be of a flat sol functor application. This is an identifer consisting of the functor name and all parameters, concatenated by _, e.g.

Then understands that setfield has a type functor call to the consset functor and infers correctly that setfield may be used as predicate over Object and Object2. The disadvantage is that AST does not know anymore which type this field has; it assumes that consset_Object2 is a scalar attribute. Thus no AST functionality on this field is available.

2.

Set or graph fields may be specified in AST-modules (which only AST will read) as scalar attributes, and the -user has to give an additional refine specification for the field in another module (which only will read). If a field (or a tree module) has the AST property REFINE then assumes that this field (resp. all fields) provide finer types for already defined fields. looks up the already specified fields and changes their type to functor applications.

Assume an AST-module which contains the AST data specification, which will only be read by AST:

Then we can refine the type of setfield in another module, which will only be read by , to a functor call using the attribute property REFINE:

Or we may give the property to the entire module:

Note that set fields have to be bracketed by (). Thus understands a slightly extended AST language:

With this mechanism we can use module x for generation of AST code, and module y1 or module y2 for type refinement. AST will not recognize the REFINE property. and will emit errors if feed by y1 or y2.