Semantics - Revision history

Dkearns: s/LibertyEiffel/Liberty Eiffel/

2016-06-14T17:12:22Z

s/LibertyEiffel/Liberty Eiffel/

← Older revision		Revision as of 19:12, 14 June 2016
Line 3:		Line 3:
	''Note:'' this page is still being written. Take the information with a grain of salt.		''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 ~~LibertyEiffel~~ tools: '''code specialization'''. ~~LibertyEiffel~~ 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.	+	Semantic analysis is strongly linked with the most important aspect of the Liberty Eiffel tools: '''code specialization'''. Liberty Eiffel 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:		All the specialization phases are one pass over the whole code specialized by earlier phases. The usual algorithm is the following:

Hzwakenberg at 21:05, 7 September 2014

2014-09-07T21:05:41Z

← Older revision		Revision as of 23:05, 7 September 2014
Line 3:		Line 3:
	''Note:'' this page is still being written. Take the information with a grain of salt.		''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.	+	Semantic analysis is strongly linked with the most important aspect of the LibertyEiffel tools: '''code specialization'''. LibertyEiffel 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:		All the specialization phases are one pass over the whole code specialized by earlier phases. The usual algorithm is the following:

Cadrian at 11:58, 24 April 2013

2013-04-24T11:58:10Z

← Older revision		Revision as of 13:58, 24 April 2013
Line 15:		Line 15:
	* specialize_in		* specialize_in
	* specialize_thru		* specialize_thru
		+	* specialize_and_check
−	* specialize_2
	* collect		* collect
	* simplify		* simplify
Line 47:		Line 47:
	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.		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~~ ===	+	=== specialize_and_check ===

−	When a type uses other types, those must have been collected first.	+	When a type uses other types, those must have been collected first. In this phase, all the types used by the target type have been collected.

	Most semantics checks happen here. Code transformation may also happen (see e.g. [[issue:78]]).		Most semantics checks happen here. Code transformation may also happen (see e.g. [[issue:78]]).

Cadrian at 11:44, 24 April 2013

2013-04-24T11:44:56Z

← Older revision		Revision as of 13:44, 24 April 2013
Line 58:		Line 58:

	At the end of this phase, a [[tool_class:TYPE\|<tt>TYPE</tt>]] is considered completely built.		At the end of this phase, a [[tool_class:TYPE\|<tt>TYPE</tt>]] is considered completely built.
		+
		+	During this phase, new types may be created, which will also be specialized.
		+
		+	When no new type is created, the system is deemed whole.

	=== simplify ===		=== simplify ===

Cadrian: /* adapt */ typo

2013-04-24T11:40:27Z

adapt: typo

← Older revision		Revision as of 13:40, 24 April 2013
Line 65:		Line 65:
	=== adapt ===		=== adapt ===

−	This phase ~~transorms~~ the code from the 2.x SmartEiffel core classes to the old 1.x SmartEiffel classes which are used by the generation back-end.	+	This phase transforms the code from the 2.x SmartEiffel core classes to the old 1.x SmartEiffel classes which are used by the generation back-end.

Cadrian at 11:40, 24 April 2013

2013-04-24T11:40:11Z

← Older revision		Revision as of 13:40, 24 April 2013
Line 49:		Line 49:
	=== 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~~	+	When a type uses other types, those must have been collected first.

−	Most semantics checks happen here. Code transformation may also happen (see e.g. [[issue:78]])	+	Most semantics checks happen here. Code transformation may also happen (see e.g. [[issue:78]]).

	=== collect ===		=== collect ===
		+
		+	Feature collect is the phase where a type collects all its known features. To do so, it is helped by the [[tool_class:FEATURE_ACCUMULATOR\|<tt>FEATURE_ACCUMULATOR</tt>]].

	At the end of this phase, a [[tool_class:TYPE\|<tt>TYPE</tt>]] is considered completely built.		At the end of this phase, a [[tool_class:TYPE\|<tt>TYPE</tt>]] is considered completely built.
		+
		+	=== simplify ===
		+
		+	This phase, only run in boost mode, tries to simplify the code: inlining, etc.
		+
		+	=== adapt ===
		+
		+	This phase transorms the code from the 2.x SmartEiffel core classes to the old 1.x SmartEiffel classes which are used by the generation back-end.

Cadrian at 07:16, 24 April 2013

2013-04-24T07:16:15Z

← Older revision		Revision as of 09:16, 24 April 2013
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 ===

Cadrian: 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…"

2013-04-24T07:11:06Z

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…"

New page

== 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)
* [[tool_class:FEATURE_ACCUMULATOR|<tt>FEATURE_ACCUMULATOR</tt>]]
* [[tool_class:ANONYMOUS_FEATURE_MIXER|<tt>ANONYMOUS_FEATURE_MIXER</tt>]]

== Specialization phases ==

=== specialize_in ===

* Type building

The code to specialize comes directly from the parser. This code is used every time a new [[tool_class:TYPE|<tt>TYPE</tt>]] 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 [[library_class:ANY|<tt>ANY</tt>]] is specialized in every type, either directly of indirectly (barring redefines, of course).

At the end of this phase, a [[tool_class:TYPE|<tt>TYPE</tt>]] 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 ===

=== collect ===

At the end of this phase, a [[tool_class:TYPE|<tt>TYPE</tt>]] is considered completely built.