ELKS 2001 STRING class is now an official standard 
Author Message
 ELKS 2001 STRING class is now an official standard

The Eiffel Library Kernel Standard STRING class, 2001 Vintage, has now
been adopted as an official NICE Standard, identified as "NICE-4".

This standard has been unanimously approved by polls in each of the
following groups:

   - The libraries group that worked to produce it
   - The NICE Board
   - The members of NICE

This standard, together with some explanatory notes, is appended to this
message.

All NICE library standards can be downloaded from:

    http://www.*-*-*.com/

Thanks to all those who worked hard over the past two years to make this
latest NICE standard possible. We look forward to its implementation in
the coming releases of Eiffel compilers, and to the day when a piece of
Eiffel code can run under any Eiffel compiler without change.

Regards,
Roger Browne
(NICE Secretary)

===

NICE-4 - THE EIFFEL LIBRARY KERNEL STANDARD, 2001 VINTAGE
=========================================================

Adopted by the NICE Board in August 2001.
Ratified by the members of NICE in August 2001.

The class text at the end of this document replaces
the existing STRING class in the ELKS 2000 specification
to yield the Eiffel Library Kernel Standard, 2001 Vintage
(ELKS 2001).

The explanatory notes at the front of this document are not
part of the official standard.

The design process
==================

Although this proposal builds on earlier work, this version is the
result of intensive discussions over the last two years on the
eiffel-nice-libraries email list.

Every part of the STRING class has been considered in detail, with
respect to the following goals:

1. To maximise interoperability between the different implementations
   of Eiffel.

2. To minimise the impact on existing code.

3. To minimise the work required by vendors to support the updated
   standard.

It was most definitely not a goal to achieve the best possible design.
We all knew better ways to do things, if we were starting with a
blank slate. But we realised that a significant improvement in
interoperability now would be much better than a "perfect" design
that may never be implemented.

The discussions have been both extensive and intensive. We have
looked in detail at every feature of the class. This is by far the
largest of the ELKS classes, and current implementations have many
incompatibilities. This has contributed to the length of time taken
to produce this proposal.

Participants in the discussions included library authors, end users,
and representatives of all Eiffel vendors. We are all very e{*filter*}d
by the possibility to achieve a truly interoperable kernel library
for Eiffel.

About the specification
=======================

We have aimed to fully-specify the ELKS 2001 STRING class. In most
cases the specification is by means of Eiffel assertions, although
we used free-form text and BNF productions in a few places where a
specification using assertions would have been cumbersome or
impractical.

The feature postconditions are precise but sometimes lengthy,
as they use recursion to assert a condition over all elements of
the STRING.

Please note the following points:

  - A vendor is not required to include these assertions in
    the delivery of a conforming kernel library.

  - The complex postconditions may be rather daunting to the novice,
    and we anticipate that versions of the standard will be circulated
    in other formats too.

Two of the features are grouped together under the tag "Basic
specifiers", and have no postconditions. All other queries are
specified (directly or indirectly) in terms of these two queries.
All commands are specified by their effect on the values of these
two queries. This approach is due to James McKim, and was pioneered
successfully in the ELKS 2000 ARRAY specification.

Changes from ELKS 1995 to ELKS 2000
===================================

Three of the areas of change are wide-ranging, and deserve special
mention:

   String creation has been cleaned up to provide separate features
   that implement the differing semantics provided by the current
   non-interoperable creation features.

   Empty strings and substrings are now handled consistently
   throughout the class.

   All features behave consistently and meaningfully in proper
   descendants of class STRING.

Summary of all changes
----------------------

Add creation features `make_empty' and `make_filled'. Refine the
specification of `make'.

   The new creation features provide for migration of existing code
   that uses non-standard implementations of `make' having "count"
   semantics.

   We expect these new creation features to be generally useful
   for other code too.

   The specification of `make' remains consistent with the "capacity"
   semantics described in ETL and OOSC.

   Inconsistency in implementations of `make' has been a major
   hindrance to interoperability in the past. We anticipate that
   ELKS 2001 STRING will enable interoperability to be achieved.

Remove feature `remake' and export `make' to {ANY}.

   Feature `remake' was not interoperable.

   Vendors may retain their existing implementations outside of the
   ELKS standard.

   Feature `make' may now be used for creation and for reinitialization.

Remove feature `resize'.

   Feature `resize' was not interoperable. In some implementations it
   changed `count' and in others it changed `capacity'.

   The functionality provided by `resize' can be provided by other
   ELKS features, although perhaps not so conveniently.

   Vendors may retain their existing incompatible implementations of
   `resize' outside of the ELKS standard.

Rename feature `fill' to `fill_with'.

   Feature `fill' was not interoperable, as it changed `count' in
   some implementations but not others. It was decided to introduce
   a new rigorously-specified feature `fill_with' that does not
   change `count'.

Rename feature `insert' to `insert_string'. Refine the specifications
of features `insert_string' and `insert_character'.

   Feature `insert' was inserting a STRING in some implementations
   and a CHARACTER in others.

   The rigorously-specified features `insert_character' and
   `insert_string' now provide a sound basis for interoperability.

Remove features `left_adjust', `right_adjust', `append_boolean',
`append_real', `append_double', `append_integer'.

   These features are only partially interoperable in current
   implementations. It was considered more practical to remove the
   features from the standard than to achieve convergence.

   The functionality offered by these features can easily be provided
   outside the kernel.

   Features removed from the standard may still be supported by a
   conforming implementation, and could be re-introduced into a
   future version of the standard if the interoperability problems
   can be overcome.

Add features `has' and infix "+".

   We considered these features to be very useful. They are already
   implemented outside of ELKS by all vendors. These features are
   also particularly useful in the specification itself.

Add feature `has_substring'.

   We considered this feature to be very useful. It is already
   implemented outside of ELKS by some vendors. This feature is
   also particularly useful in the specification itself.

Refine the specifications of `substring', `substring_index'

   These features did not handle empty strings in some implementations.
   In some cases the feature preconditions made it impossible to work
   with empty strings; in other cases incorrect results were generated.

   These features now handle empty strings consistently and seamlessly.
   Without that change it would have been difficult to specify this
   class rigorously, as these features are used in the ELKS 2001
   STRING assertions.

   Consistent handling of empty strings has also been provided
   throughout the rest of the STRING class.

Refine the specifications of `occurrences', `count', `valid_index',

   `hash_code', `out', `remove', `append_string', `append_character',
   `to_integer', `to_boolean', `to_real', `to_double', `index_of',
   infix "<=", infix ">", infix ">=", `is_lower', `is_upper',
   `from_c', `wipe_out', `make_from_string' and the class invariant.

   These specifications were refined to make them rigorous. Sometimes
   the specification matches what is already implemented by all
   vendors. Other times, minor changes will be needed by one or
   more vendors. However, we do not expect significant disruption
   to existing code.

Add features `is_integer', `is_boolean', `is_real', `is_double'.

   These features were added to enable us to rigorously specify
   the preconditions of `to_integer', `to_boolean', `to_real' and
   `to_double'. We also consider them to be generally-useful features.

Add features `as_lower', `as_upper'.

   These new queries were added to enable us to rigorously specify
   the postconditions of the commands `to_lower' and `to_upper'.

Add features `string' and `same_string'.

   These new features work with the character sequence of a STRING or
   STRING-like object. Because they refer only to the character
   sequence, even in proper descendants, they enabled us to write
   specifications for features such as `make_from_string' that are
   rigorous in STRING and in any descendant.

Replace features `head' and `tail' by `keep_head', `keep_tail',
`remove_head', `remove_tail' and `remove_substring'.

   The revised feature names are considered to be more clear and
   consistent.

   The feature names `head' and `tail' were considered to suggest
   queries, not commands.

Rename feature `put_substring' to `replace_substring'.

   Neither of these features is supported by all current
   implementations. `replace_substring' was considered to be the
   better name.

Refine the specification of infix "<".

   The new specification of infix "<" makes it clear that comparison
   is to be
...

read more »



Wed, 18 Feb 2004 03:06:07 GMT  
 ELKS 2001 STRING class is now an official standard
Kudos to the NICE team, who have clearly put a lot of effort into
this improved STRING class.

But oddly enough, this is the bit that interested me the most:


Quote:

>--   The correctness of this specification is based on the following
>--   assumptions:
>--
>--   1. No feature of STRING calls a command on any of its arguments.
>--
>--   2. No query of STRING changes the value of any basic specifier.
>--
>--   3. No feature of STRING shares internal structures in any way
>--       that could lead to behaviour not deducible from this
>--       specification.
>--
>--   4. The phrase "new STRING" in a header comment means a
>--       newly-created STRING to which there is no reference other than
>--       from `Result'.
>--
>--   5. The phrase "new object" in a header comment means a
>--       newly-created object of type "like Current" to which
>--       there is no reference other than from `Result'.

This seems like a wonderful shopping list of conditions which can't
currently be specified in Eiffel, but would be very useful in practice,
both for programmers and for compilers (especially to perform
optimizations).  They all have to do with asserting that "nothing
else changes", which is a sticky issue.

I think all of these could be ensured by a compiler, especially if
the language had a few side-effect specification keywords.  This
happens to be something I have been thinking about lately, though
my thoughts are not yet fit for public exposure.  :-)

--
--
Patrick Doyle



Fri, 20 Feb 2004 22:12:26 GMT  
 ELKS 2001 STRING class is now an official standard
Of course, the subject was meant to be "Side-effect specification".
Darn this new "natural" keyboard.

--
--
Patrick Doyle



Fri, 20 Feb 2004 22:22:54 GMT  
 ELKS 2001 STRING class is now an official standard

Quote:

> Kudos to the NICE team, who have clearly put a lot of effort into
> this improved STRING class.

> But oddly enough, this is the bit that interested me the most:


> >--   The correctness of this specification is based on the following
> >--   assumptions:
> >--
> >--   1. No feature of STRING calls a command on any of its arguments.
> >--
[... and so on]

> This seems like a wonderful shopping list of conditions which can't
> currently be specified in Eiffel, but would be very useful in practice,
> both for programmers and for compilers (especially to perform
> optimizations).  They all have to do with asserting that "nothing
> else changes", which is a sticky issue.

> I think all of these could be ensured by a compiler, especially if
> the language had a few side-effect specification keywords.  This
> happens to be something I have been thinking about lately, though
> my thoughts are not yet fit for public exposure.  :-)

Yep. Other things that the NICE team as struggled with include
assertions that need to iterate over the contents of a collection;
like when converting a number to a string, how do you ensure that the
resulting string contains only digit characters? It can be done, but
with the control structures in assertions being so limited, it gets
ug-lee.

Another recent problem has to do with genericity. If a generic
container returns a new version of itself (perhaps as a different type
of container) how does an assertion guarantee that the things
contained conform to the original type? Hmm, muddy sentence. Consider
then:

class FOO[G]
   ... -- all kinds of classy stuff
feature
   as_array : ARRAY[G] -- return the contents of Current
                       -- as a new array of G

How does "as_array" ensure the return type of ARRAY? What if FOO is
empty when "as_array" is called? What if it only contains descendents
of G? We agreed to go with just comments on that one.

DbC is a great tool, but as with any tool its important to know its
limitations.

Greg



Mon, 23 Feb 2004 01:16:42 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. Verilog 2001 (1364-2001 IEEE Standard) Question

2. APL-L Digest - 24 Sep 2001 to 25 Sep 2001 (#2001-223)

3. APL-L Digest - 14 Jun 2001 to 15 Jun 2001 (#2001-136)

4. APL-L Digest - 22 Mar 2001 to 23 Mar 2001 (#2001-63)

5. APL-L Digest - 13 Feb 2001 to 14 Feb 2001 (#2001-34)

6. WFLP 2001 deadline extension to May 22, 2001

7. APChDL-2001/SLDL-2001 call for papers

8. APChDL-2001/SLDL-2001 call for papers

9. WFLP 2001 deadline extension to May 22, 2001

10. ELKS 2000 standard consequences?

11. Final comment on draft (probably soon to be official) COBOL Standard

 

 
Powered by phpBB® Forum Software