Difference between revisions of "Minor-ECMA-problems"
(Restored page content)
 
(39 intermediate revisions by 3 users not shown)
Line 1: Line 1:
−
==Definition: Coupled name==
+
[[Category:ECMA]]
 +
=Precursor=
  
−
====Motivation====
+
The current definition of the Precursor semantics in the ECMA standard (8.10.11)
−
There are several situations in which the ECMA standard uses unfoled forms as a vehicle to describe semantics. When this unfoled forms need names, like in Precursor, inline agents and not isolated features. These names have an influence on the semantics of the system. An example:
+
  
−
{|border="0" cellpadding="2" cellspacing="0" align="center"
+
=Agent types=
−
|-valign="top" -halign="center"
+
==Motivation==
−
|<code>[eiffel, N]
+
The classes ROUTINE, PROCEDURE, FUNCTION and the new class PREDICATE do not nicely fit in to the Eiffel language. Reasons:
−
class
+
* They do not reflect the fact, that an agent can refer an attribute. An attribute is not a ROUTINE.
−
  B
+
* They do contradict the uniform access principle.  
−
feature
+
* They are difficult to define. It is difficult to understand, why it is so difficult to define an agent type when it is so easy in functional languages!
−
  f
+
** Specially the first generic Parameter of ROUTINE is difficult to understand and, if I am not wrong, never used.
−
      do  
+
* The standard conformance rules simply do not work nice for agent types. They introduce a type hole that can only be detected at runtime, and even then, only if precondition assertions are enabled. Other than cat calls this typing problem doesn't give the language more power.
−
        (agent do g := g + 1; print (g) end).call ([])
+
−
      end
+
−
  g: INTEGER
+
−
end
+
−
</code>
+
−
|
+
−
<code>[eiffel, N]
+
−
class
+
−
  D
+
−
inherit
+
−
  B
+
−
      rename f as f1, g as g1, select f1, g1 end
+
−
  B
+
−
      rename f as f2, g as g2 end
+
−
end
+
−
</code>
+
−
|}
+
  
−
It feels natural to unfold class B first and then inherit C from its unfolded form before C is unfolded:
+
==An other mechanism:==
  
−
{|border="0" cellpadding="2" cellspacing="0" align="center"
+
I will give an example of an other mechanism:
−
|-valign="top" -halign="center"
+
−
|<code>[eiffel, N]
+
−
class
+
−
  B
+
−
feature
+
−
  f
+
−
      do
+
−
        (agent fict_name).call ([])
+
−
      end
+
−
  g: INTEGER
+
  
−
  fict_name
+
Instead of writing
−
      do
+
 
−
        g := g + 1; print (g)
+
<code>[N, eiffel]
−
      end
+
f: FUNCTION [ANY, TUPLE [STRING], INTEGER]
−
end
+
 
</code>
 
</code>
−
|
+
 
−
<code>[eiffel, N]
+
we could write
−
class
+
<code>[N, eiffel]
−
  D
+
f (STRING): INTEGER
−
inherit
+
−
  B
+
−
      rename f as f1, g as g1, select f1, g1 end
+
−
  B
+
−
      rename f as f2, g as g2 end
+
−
end
+
 
</code>
 
</code>
−
|}
 
  
−
This system is not valid anymore. The call-equivalent of the inline-agent (here named fict_name) has a call to g which has several
+
Calling this f would be easy:
−
potential versions in D. The same problem can occur with calls to Precursor. The programmer cannot do anything about it since he has no knowledge of the fictous name of the call-equivalent.
+
  
 +
i: INTEGER
 +
...
 +
i := f ("hello")
  
 +
We could also write:
  
−
A feature name can be coupled to the name of an other feature.
+
i: INTEGER
 +
...
 +
i := agent f ("hello")
  
−
==New Behaviour of renaming==
 
−
The unfolded form of a renaming is the renaming itself plus the unfolded forms of the renamings of all the coupled names.
 
  
−
=Precursor=
 
  
−
The current definition of the Precursor semantics in the ECMA standard (8.10.11)
+
 
 +
 
 +
 
 +
Instead of writing:
 +
 
 +
f: FUNCTION [ANY, TUPLE [STRING], ANY]
 +
 
 +
we would write:
 +
 
 +
f (STRING): ANY
 +
 
 +
==Stuff that is not correctly formulated==
 +
Definition 8.5.1 should be changed to something with the following semantics:
 +
 
 +
====8.5.1 Definition: Inherited, immediate; origin; redeclared; replicated introduce====
 +
 
 +
Any feature f of a class C is of one of the following four kinds:
 +
 
 +
# If C obtains f from one of its parents, f is an inherited feature of C. In this case any declaration of f in C (adapting the original properties of f for C) is a redeclaration.
 +
# If a declaration appearing in C applies to a feature that is not inherited, the feature is said to be immediate in C. Then C is the origin (short for “class of origin”) of f, and is said to introduce f.
 +
 
 +
 
 +
====8.9.5 Validity: Precondition Export rule====
 +
A Precondition of a feature r of a class S is valid if and only if every feature f appearing in every
 +
Assertion_clause of its unfolded form u satisfies the following two conditions for every class C to
 +
which r is available:
 +
1 Iff appears as feature of a call in u or any of its subexpressions, f is available to C.

Latest revision as of 11:12, 30 May 2007

Precursor

The current definition of the Precursor semantics in the ECMA standard (8.10.11)

Agent types

Motivation

The classes ROUTINE, PROCEDURE, FUNCTION and the new class PREDICATE do not nicely fit in to the Eiffel language. Reasons:

  • They do not reflect the fact, that an agent can refer an attribute. An attribute is not a ROUTINE.
  • They do contradict the uniform access principle.
  • They are difficult to define. It is difficult to understand, why it is so difficult to define an agent type when it is so easy in functional languages!
    • Specially the first generic Parameter of ROUTINE is difficult to understand and, if I am not wrong, never used.
  • The standard conformance rules simply do not work nice for agent types. They introduce a type hole that can only be detected at runtime, and even then, only if precondition assertions are enabled. Other than cat calls this typing problem doesn't give the language more power.

An other mechanism:

I will give an example of an other mechanism:

Instead of writing 

f: FUNCTION [ANY, TUPLE [STRING], INTEGER]

we could write 

f (STRING): INTEGER

Calling this f would be easy:

i: INTEGER ... i := f ("hello")

We could also write:

i: INTEGER ... i := agent f ("hello")




Instead of writing:

f: FUNCTION [ANY, TUPLE [STRING], ANY]

we would write:

f (STRING): ANY

Stuff that is not correctly formulated

Definition 8.5.1 should be changed to something with the following semantics:

8.5.1 Definition: Inherited, immediate; origin; redeclared; replicated introduce

Any feature f of a class C is of one of the following four kinds:

  1. If C obtains f from one of its parents, f is an inherited feature of C. In this case any declaration of f in C (adapting the original properties of f for C) is a redeclaration.
  2. If a declaration appearing in C applies to a feature that is not inherited, the feature is said to be immediate in C. Then C is the origin (short for “class of origin”) of f, and is said to introduce f.


8.9.5 Validity: Precondition Export rule

A Precondition of a feature r of a class S is valid if and only if every feature f appearing in every Assertion_clause of its unfolded form u satisfies the following two conditions for every class C to which r is available: 1 Iff appears as feature of a call in u or any of its subexpressions, f is available to C.

Retrieved from "https://dev.eiffel.com/index.php?title=Minor-ECMA-problems&oldid=8600"