Difference between revisions of "ECMA"

From Liberty Eiffel Wiki
Jump to navigation Jump to search
m
 
(22 intermediate revisions by 4 users not shown)
Line 1: Line 1:
In [http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-367.pdf ECMA-367] the ECMA committee TC39-TG4 defines an Eiffel standard. Liberty is not committed to fully implement this standard, but there will be much more of the improvements as in SmartEiffel. Liberty will implement those parts of ECMA that match the effective, efficient and simple design of previous versions of Eiffel. The parts requiring an extensive run-time model will not be currently implemented; those that needlessly complicates the language to comply to widespread programming conventions will be evaluated case-by-case
+
In [http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-367.pdf ECMA-367] the ECMA committee TC39-TG4 defines an Eiffel standard. Liberty is not committed to fully implement this standard, but it already supports more of the ECMA-improvements than its predecessor did at the time. Liberty will implement those parts of ECMA that match the effective, efficient and simple design of previous versions of Eiffel. The parts requiring an extensive run-time model will not be currently implemented; those that needlessly complicate the language to comply to widespread programming conventions will be evaluated case-by-case.
   
==These ECMA features are already implemented:==
+
==Liberty Eiffel offers these ECMA features already:==
  +
* '''attribute''' keyword may be used to define an attribute including self-initialization with contracts checking.
* Non-conforming inheritance (although the notation is different)
 
   
==These ECMA features are already implemented with small deviations:==
+
With small deviations:
* Non-conforming inheritance ('''insert''' instead of '''inherit {NONE}''') see [[Typing policy]]
+
* Non-conforming inheritance (but using '''insert''' instead of '''inherit {NONE}'''); see [[Typing policy]]
  +
* [https://github.com/LibertyEiffel/Liberty/issues/78 Assigners] with the following deviations:
  +
** VFAC (ECMA §8.5.22) is not enforced (let the standard rules of the replacing procedure call play instead)
  +
** assigners are inherited with proper renames (ECMA does not explicitly specify the rules either way)
  +
* [[task:12666|Cosmetic syntax changes]]:
  +
** '''is''' is now optional
  +
** '''alias''' is implemented, including '''alias "[]"'''
  +
** '''note''' replaces '''indexing''' and can be placed at the start and end of a class, and at the start of a feature
  +
** '''create''' replaces '''creation'''
  +
* [[task:12661|generic creation]]
  +
  +
==These ISE features are also implemented:==
  +
  +
[[task:13103|These features]] are not (yet) in the ECMA standard:
  +
* the newer '''alias "()"'''
  +
* its companion implicit tuples
  +
* '''if-then-else''' expressions
   
 
==These features are planned:==
 
==These features are planned:==
* [https://github.com/LibertyEiffel/Liberty/issues/81 generic inheritance]
+
* [[task:12662|generic inheritance]]
  +
* [[task:12660|conversions]] - maybe with a slightly stricter interpretation
* [https://github.com/LibertyEiffel/Liberty/issues/80 generic creation]
 
  +
* [[task:12653|named TUPLE elements]]
* [https://github.com/LibertyEiffel/Liberty/issues/79 Conversions] - maybe with a slightly stricter interpretation
 
  +
* [[task:12664|void-safety]] (Liberty implementation will probably differ from ECMA)
* [https://github.com/LibertyEiffel/Liberty/issues/61 named TUPLE elements]
 
  +
* '''attached''' vs '''detached'''
* [https://github.com/LibertyEiffel/Liberty/issues/78 attribute setters]
 
  +
* '''across'''
* [https://github.com/LibertyEiffel/Liberty/issues/83 void-safety] (Liberty implementation will probably differ from ECMA)
 
* [https://github.com/LibertyEiffel/Liberty/issues/90 small syntax changes] - the old syntax will be kept for compatibility for quite some time.
 
   
 
==These ECMA features are not planned in Liberty:==
 
==These ECMA features are not planned in Liberty:==
Line 20: Line 35:
   
 
==These features are not in ECMA but implemented in Liberty:==
 
==These features are not in ECMA but implemented in Liberty:==
* inline agents are closures ([https://github.com/LibertyEiffel/Liberty/issues/55 planned])
+
* [[task:12671|inline agents are closures]]
  +
* explicit agent conformance rules (see [http://www.jot.fm/issues/issue_2004_04/article7/ this JOT paper])
   
 
==Not yet decided:==
 
==Not yet decided:==
  +
* <code><nowiki>TYPE[G]</nowiki></code> and explicit conversion
* Bracket indexing
 
  +
* postcondition of is_equal: same_type: Result implies same_type(other)
  +
** this essentially forbids any equal objects with different types and is inconsistent to the current implementation in Liberty. It has some nice background (e. g. symmetry is not easy to guarantee without that), but we also do not want to brake existing code
   
 
See also [[Compatibility]].
 
See also [[Compatibility]].

Latest revision as of 19:54, 22 July 2022

In ECMA-367 the ECMA committee TC39-TG4 defines an Eiffel standard. Liberty is not committed to fully implement this standard, but it already supports more of the ECMA-improvements than its predecessor did at the time. Liberty will implement those parts of ECMA that match the effective, efficient and simple design of previous versions of Eiffel. The parts requiring an extensive run-time model will not be currently implemented; those that needlessly complicate the language to comply to widespread programming conventions will be evaluated case-by-case.

Liberty Eiffel offers these ECMA features already:

  • attribute keyword may be used to define an attribute including self-initialization with contracts checking.

With small deviations:

  • Non-conforming inheritance (but using insert instead of inherit {NONE}); see Typing policy
  • Assigners with the following deviations:
    • VFAC (ECMA §8.5.22) is not enforced (let the standard rules of the replacing procedure call play instead)
    • assigners are inherited with proper renames (ECMA does not explicitly specify the rules either way)
  • Cosmetic syntax changes:
    • is is now optional
    • alias is implemented, including alias "[]"
    • note replaces indexing and can be placed at the start and end of a class, and at the start of a feature
    • create replaces creation
  • generic creation

These ISE features are also implemented:

These features are not (yet) in the ECMA standard:

  • the newer alias "()"
  • its companion implicit tuples
  • if-then-else expressions

These features are planned:

These ECMA features are not planned in Liberty:

  • No-variant agent arguments.

These features are not in ECMA but implemented in Liberty:

Not yet decided:

  • TYPE[G] and explicit conversion
  • postcondition of is_equal: same_type: Result implies same_type(other)
    • this essentially forbids any equal objects with different types and is inconsistent to the current implementation in Liberty. It has some nice background (e. g. symmetry is not easy to guarantee without that), but we also do not want to brake existing code

See also Compatibility.