View source for Current implementation of multi constraint formals

← Current implementation of multi constraint formals
You do not have permission to edit this page, for the following reasons:
The action you have requested is limited to users in one of the groups: Autoconfirmed users, emailconfirmed, editors.
You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.
You can view and copy the source of this page:
[[Category:Compiler]]
{{Warning|'''Warning''': Article under development}}

==Introduction==
The first implementation of multi constraints is done and this article describes its current implementation status.

Let's take this example
<e>
MULTI[G -> {H, COMPARABLE rename is_equal as is_equal_cmp end},
      H -> {NUMERIC rename default_create as default_create_num end, G}]
</e>
A type satisfying the constraint of ''G'' has the following properties:
* It conforms to whatever ''H'' is and therefore
** to <e>NUMERIC</e> and 
** by recursion to itself (''G'')
* It conforms to its second constraint which is <e>COMPARABLE</e>.


A type satisfying the constraint of ''H'' has the following properties:
* It conforms to <e>NUMERIC</e>.
* It conforms to ''G'' and therefore
** by recursion to itself (''H'') and
** to <e>COMPARABLE</e>.

As ''G'' and ''H'' both have to conform to each other the only possibility to satisfy this is that ''G'' and ''H'' must be the same in the generic derivation. It does not make much sense to program something like that but it is part of the current implementation.

=== Feature calls ===

Let's have a look at the following feature written in class ''MULTI'':
<e>
feature
    g: G

    f: BOOLEAN
            -- Sample feature
        do
            create g -- 1
            Result := g.is_equal(g) -- 2
        end
</e>
The following rules have to hold for each call on a multi constraint formal:
* Every feature which is called has exactly one class which is used as the static type for the call.

This is a major difference to the ECMA standard which allows a call to features which are available through different classes as long as it is the same feature. A definition of what the ''same feature'' means can be found [[Replication|here]].

In order to achieve that goal if a feature occurs with the same name in  different classes one uses a rename clause and renames that feature. If there are name clashes between features and one does not want to call that feature a renaming is '''not''' needed.

As we perform calls to <e>default_create</e> (line 1 of <e>f</e>) and <e>is_equal</e> (line 2 of <e>f</e>, which are both features from <e>ANY</e> and each occurs as the same feature once in <e>COMPARABLE</e> and once in <e>NUMERIC</e>. We do this despite the fact that it is actually the same feature. The reason for this can be found in the new semantics of the dynamic binding described in the [http://www.ecma-international.org/publications/standards/Ecma-367.htm standard]. You may also want to have a look at the following [[Multiple_constraints|article]] which discusses the issue.

=== Renaming on formals ===

The current implementation rejects a rename clause which is applied to a formal. The following code is therefore currently rejected as H is a formal and we don't allow a renaming on it.
<e>
class MULTI[G -> {H rename is_equal as is_equal_prime end, ANY}, H -> ANY]
</e>

The rules implemented are chosen so that they are the most restrictive. This is to ensure that written code is likely to compile in the future where the rules might be more relaxed.

==Implementation details==

The central classes to the current implementation are:
* <e>TYPE_SET_A</e>
* <e>EXTENDED_TYPE_A</e>
* <e>RENAMING_A</e>
* <e>CONSTRAINING_TYPE_AS</e>
* and some changes to <e>CLASS_C</e>

The main tasks which have to be performed are:
* Type checking in particular type conformance.
* Feature lookup

Both tasks are provided by <e>TYPE_SET_A</e>.
===TYPE_SET_A===
====Conformance====
The feature <e>conform_to</e> inherited from <e>TYPE_A</e> can be used to check whether a type set conforms to another type which is possibly a type set as well. 

* A type set conforms to another type if at least one type in the type 
set conforms to the type.
* Another type conforms to a type set if it conforms to all types in the type set.
* A type set ''ts1'' conforms to a type set ''ts2'' if for each type ''t'' in ''ts2'' there is at least one type in ''ts1'' which conforms to ''t''.

If every type is regarded as a type set with one element one can simply  always use the last rule.

====Feature lookup====
There are various features which provide this functionality. Their differences are mostly in the amount of information they provide. Of course the computation gets more expensive if the feature returns more information.
Currently the API is pretty much targeted to what the compiler needs.
There's a bunch of features of the family ''e_feature_state_*''/''feature_i_state_*'' which are used when most likely only one feature occurs.
As soon as you need more information the features of the family ''info_about_feature_*'' can help you to get all information about a certain feature for a given type set.

====Associated class====
This feature is no longer available and therefore exported to NONE. This is simply because there is no single associated class but many.
You can use the feature ''associated_classes'' instead and get a list of all associated classes.
However, the features applicable to the type set is not the same set as the features provided by each element of the ''associated_classes''. This is because one loses the renaming (class <e>RENAMING_A</e>) which is stored inside the <e>TYPE_SET_A</e> in each <e>EXTENDED_TYPE_A</e> instance. This is why there are some places in the code where going from a <e>CLASS_C</e> instance to one of type <e>LIST [CLASS_C]</e> is not enough.

===EXTENDED_TYPE_A===

===RENAMING_A===
This is the class which provides features to handle the renaming which is applied to the features of the constraint type.

It's current implementation is based on a hash table and therefore only one way is efficient.

You can find out whether a specific feature is renamed by calling <e>is_feature_renamed</e>. There's also a predefined feature <e>renamed</e> which takes an integer argument and returns another one. The integer returned is either
* unchanged, if the feature is not renamed
* some other positive integer if the feature is renamed under the renaming
* -1 if the feature was renamed into something else (therefore it is not accessible)

However, this is only relative to the renaming and is not in the context of a specific class. It means that if the feature ''f'' does not occur in  the class you don't get an error (-1), as <e>RENAMING_A</e> does not consult a context class for its operations.

===CLASS_C===

A major change here affects the feature <e>constraint (i: INTEGER): TYPE_A</e>.
It is used to get the constraint of the formal at position ''i''. A new precondition has been added which states that it is only ok to call that feature if the formal has only one constraint. This is also the reason why currently it is not allowed to apply a renaming to a single constraint.
For the multi constraint case the feature <e>constraints (i: INTEGER): TYPE_SET_A</e> should be used instead. It returns a TYPE_SET_A instance which can possibly contain other formals.
Templates used on this page:
Return to Current implementation of multi constraint formals.
Retrieved from "https://dev.eiffel.com/Current_implementation_of_multi_constraint_formals"
View source for Current implementation of multi constraint formals

Navigation

Development

Wiki

Search

Tools
