Difference between revisions of "Semantics"
(Created page with "== Overview == ''Note:'' this page is still being written. Take the information with a grain of salt. Semantic analysis is strongly linked with the most important aspect of the…") |
|||
Line 48: | Line 48: | ||
=== specialize_2 === |
=== specialize_2 === |
||
+ | |||
+ | When a type uses other types, those must have been collected first. This phase ensures that all the features of the type |
||
+ | |||
+ | Most semantics checks happen here. Code transformation may also happen (see e.g. [[issue:78]]) |
||
=== collect === |
=== collect === |
Revision as of 08:16, 24 April 2013
Overview
Note: this page is still being written. Take the information with a grain of salt.
Semantic analysis is strongly linked with the most important aspect of the SmartEiffel tools: code specialization. SmartEiffel does not use a syntax tree; but a semantics tree. Each node of that tree is a reflection of the syntax tree in the light of a particular type (think generic classes, inheritance). The original tree is provided by the parser.
All the specialization phases are one pass over the whole code specialized by earlier phases. The usual algorithm is the following:
- try to specialize every attribute
- if any changed, twin Current and assign the specialized attributes
- return either Current (if nothing changed) or the twin (i.e. specialized)
Most specialization phases can run simultaneously for different types. Some phases (viz. collect) may even call again earlier phases. The only barrier is at the end of collect: at that time, all the types are ready to use (i.e. the whole system is known).
The specialization phases are:
- specialize_in
- specialize_thru
- specialize_2
- collect
- simplify
- adapt
Also of note:
- resolve_in (not available before, including, specialize_2)
- FEATURE_ACCUMULATOR
- ANONYMOUS_FEATURE_MIXER
Specialization phases
specialize_in
- Type building
The code to specialize comes directly from the parser. This code is used every time a new TYPE must be created: all the code coming from parents is specialized when the type of the target (i.e. Current) is the type being created.
For instance, the code coming from ANY is specialized in every type, either directly of indirectly (barring redefines, of course).
At the end of this phase, a TYPE is partially defined; only the features coming from its parents are specialized.
- Feature collect
At the end of feature collect (see below), the signatures of the features that are not inherited are specialized in the context of their target type.
specialize_thru
- Feature collect
At the end of feature collect (see below), the signatures of the inherited features are specialized in the context of their target type, using their parent type.
specialize_2
When a type uses other types, those must have been collected first. This phase ensures that all the features of the type
Most semantics checks happen here. Code transformation may also happen (see e.g. issue:78)
collect
At the end of this phase, a TYPE is considered completely built.