work in progress | other ELKS items

ELKS 2000 initial proposal



This work is a proposal for the new standard ELKS for two classes: ARRAY and STRING.

It is not intended to be the whole new standard, but only part of it. Indeed, because ELKS hasn't evolved at all since 1995,  we  decided to invest a reasonnable but limited amount of time and work to see whether it was possible to make things go ahead a bit.

If, after discussions and possibly modifications, this proposal for ARRAY and STRING is officially accepted in a reasonnable amount of time and published by NICE as part of the new standard (which would be the first evolution since 1995...), we will continue working on other classes and topics for the new standard. Otherwise, we will, as most people so far who have been trying to improve ELKS, consider we have wasted our time and efforts and give up.

This work is mostly considered as a (major) cleanup of ELKS'95 for ARRAY and STRING, not as an extension to it. Once good basis are agreed on, extensions may be discussed more easily.

(This preamble was written by Dominique Colnet and Olivier Zendra, from the SmallEiffel team. As far as we know, these views are shared by Emmanuel Stapf, from ISE. However, since he could not take part in writing this, neither him or ISE are committed by this.)

In Progress for the new standard

STRING (Note: this list may be incomplete. initial_string.html is the actual reference. )
  1. Introduced capacity.
  2. make is not frozen anymore.
  3. Removed remake and resize.
  4. Renamed empty into is_empty.
  5. Reviewed most of the assertions to use valid_index instead of the explicite use of the comparison of index to 1 and count.
  6. Renamed from_c into make_from_external
  7. Added a new creation procedure make_from_external and to_external
  8. Introduced a new set of routines to do some string search based on character/string search from with/without a start/last index which can do the search from the beginning or from the end:
  9. Changed the post-conditions of left_adjust and right_adjust which were completely wrong.
  10. Removed put_substring and replace it by subcopy a multipurpose string routine manipulation with a clear comment.
  11. Changed insert and insert_character into insert_string and insert. Clarified the purpose of those two features. Added add as a synonym of insert.
  12. Introduced adjust_capacity which replaces resize with a more explicit meaning.
  13. Introduced first and last to get the first and the last character of a STRING.
  14. New STRING class invariant: capacity >= count.
  15. Added post-conditions to the append_* features.
  16. Added extend and add_last as a synonym of append_character and append as a synonym of append_string.
  17. Added is_boolean, is_integer, is_real and is_double features.
  18. Added same_as which does a case insensitive comparison between two strings.
  19. Added add_first and precede.
  20. Added infix + to append two strings.



ARRAY (Note: this list may be incomplete. initial_array.html is the actual reference. )

  1. Removed entry and enter.
  2. item, put and @ are not frozen anymore.
  3. Changed the assertions of make.
  4. Added a precondition to make_from_array.
  5. Added capacity and the class invariant capacity >= count.
  6. Changed the definition of resize.
  7. Use of equal as comparison operator for the new search algorithms (has, index_of, reverse_index_of)
  8. Removed ambiguity on is_equal and copy
  9. Renamed to_c into to_external.
  10. Added is_empty, occurrences, first and last.
  11. Added add, add_first and add_last.
  12. Added remove, remove_first and remove_last.


Off standard for the time being


Very important language/libraries issues were also discussed about the semantics of STRING.  In a nutshell, there are two problems:

  1. The current semantics of an instruction such as

  2. foo := "FOO";
    is not very clear and various compilers have different implementation for this. Some create a new object, other consider this instruction as a call to a once function (like for the declaration foo: STRING is "FOO";). This at least must be clarified.
  3. STRINGs are mutable. Adding immutable (constant) strings would be a significant improvement, both in terms of performance (potential optimizations) and expressiveness (and safety).
After discussing this, it seem that the correct implementation in the long term would be the following:
  1. Mutable STRINGs and immutable CONSTANT_STRING (or another name).
  2. "FOO" is the notation for a CONSTANT_STRING.
  3. It must be possible to compare two CONSTANT_STRINGs with '='  with the same semantics as is_equal.


Aside the high-level, flexible, ARRAY class, it seems important to provide a standard  low-level,  C-like, array for optimal performances, like the NATIVE_ARRAY[E] class provided with SmallEiffel.

Back to the top

People Behind

Dominque Colnet (

Emmanuel Stapf (

Olivier Zendra (

Back to the top

Last Update: 20 August 1999.