View source for Single-level call rule and generics

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:ECMA]]
[[Category:Catcall]]
== Problem ==

The single-level call rule says that every call has to be valid for all possible dynamic types of an entity. So for a formal generic <e>G</e> this means that the call has to be valid for all possible descendants of the constraint (or at least for every generic derivation that occurs in a system).

Let's look at an example using <e>NUMERIC</e>:

<e>
class X [G -> NUMERIC]

feature

  f (g1, g2: G): G
    do
      Result := g1 + g2
    end

end
</e>

Here, the call to <e>+</e> has to be valid for all possible descendants of <e>NUMERIC</e>. Since the signature of the feature is <e>like Current</e>, the call is never valid. This has to be the case as otherwise, the following code would produce a catcall:

<e>
x: X [NUMERIC]
x.f (1, 1.0)
</e>

The problem is that the formal generic <e>G</e> is always assumed to be of any type which satisfies the constraint, so normally the formal generic is polymorphic.

As the above example show, the use of features on formal generic parameters which are covariantly redefined is severely limited. But as the purpose of <e>NUMERIC</e> is exactly to allow creation of generic algorithms over numeric types, this has to be addressed (Note that <e>COMPARABLE</e> is also a problem).

== Possible solutions ==

=== Monomorphic formal generics ===

The first idea is to be able to mark a formal generic as monomorphic:
<e>
class X [monomorphic G -> NUMERIC] feature

  f (g1, g2: G): G
    do
      Result := g1 + g2
    end

end
</e>

The class can then only be generically derived with monomorphic types, i.e. using [[interval types]] <e>X [INTEGER..INTEGER]</e> or <e>X [REAL..REAL]</e>.

   [Comment by BM 5 Nov 2007: this does not seem desirable as there is nothing
   wrong with the class, only with the feature.]

For the check we can now assume that <e>G</e> will be monomorphic. This helps a little bit further: For every feature argument which is <e>like Current</e> we can assume that the exact type will be given. But this works only for covariant features which have <e>like Current</e> arguments which are never redefined into something else. Take the following classes for an example:

<e>
class A
feature
  f (a: like Current) do end
end

class B
inherit A
end

class C
inherit A redefine f
feature
  f (a: D) do end
end

class D
inherit C
end
</e>

Now assume the following generic class:

<e>
class X [monomorphic G -> A]
feature
  f
    local
      g1, g2: G
    do
      g1.f (g2)
    end
end
</e>

The call to <e>g1.f</e> is not valid since <e>G</e> could be of type <e>C</e>, and then the argument has to be of type <e>D</e>. So now, not even the <e>like Current</e> feature is callable with monomorphic generics. Basically it is the same as the declaration without ''monomorphic'' for the generic.

So this solution works only for the case of <e>like Current</e> features never change the signature. Only then it can be guaranteed for a monomorphic generic formal, that the signature will match the formal generic exactly. Other covariant features have still to be valid for all possible descendants.

For the case of <e>NUMERIC</e> and <e>COMPARABLE</e> the use of monomorphic formal arguments would work as they define only <e>like Current</e> features which are normally kept that way in subclasses. A more general mechanism would be nice but at the moment it is unclear how such a mechanism should look like.

=== Remodeling library ===

Another way to solve the problem of <e>NUMERIC</e> and <e>COMPARABLE</e> would be to change the library. As these classes have mostly <e>like Current</e> arguments and result types, they can be modeled via generics in the first place.

For example:

<e>
class NUMERIC [G -> NUMERIC [G]]
feature
  infix "+" (other: G): G
end

class COMPARABLE [G -> COMPARABLE [G]]
feature
  less_than (other: G): BOOLEAN
end
</e>

With this approach, the use of the general class <e>NUMERIC</e> and <e>COMPARABLE</e> will become more complicated, but since they appear in libraries most of the time it could be done.

Return to Single-level call rule and generics.

Retrieved from "https://dev.eiffel.com/Single-level_call_rule_and_generics"

View source for Single-level call rule and generics

Navigation

Development

Wiki

Search

Tools