ELKS 2000 standard consequences? 
Author Message
 ELKS 2000 standard consequences?

I'm Eiffel beginner and viewed ELKS 2000 draft standard. It seems that
they are going to suggest quite heavy changes to the fundamental
classes, STRING and ARRAY. I'd like to ask what are the consequences of
this kind of standard? Won't the existing libraries become incompatible
with ELKS 2000 compilers? What is the role of ELKS after all? Will the
compiler implementers follow this this standards?

-TS



Fri, 07 Feb 2003 03:00:00 GMT  
 ELKS 2000 standard consequences?

Quote:

> I'm Eiffel beginner and viewed ELKS 2000 draft standard. It seems that
> they are going to suggest quite heavy changes to the fundamental
> classes, STRING and ARRAY.

What do you consider to be the "heavy changes"? There are a few,
perhaps, but only where there was no simpler path towards
interoperability.

Quote:
> Won't the existing libraries become incompatible
> with ELKS 2000 compilers?

Pre-2000 Eiffel compilers have enormous incompatibilities. It's
extremely difficult to write interoperable code with pre-2000 compilers.
ELKS95 was never fully-supported by any vendor, although some came
closer than others.

At last, things are improving: two vendors already support the ELKS 2000
ARRAY class (the other two have not yet released an upgrade since ELKS
2000 was approved). After stagnating for many years, interoperability is
finally getting better.

Quote:
> What is the role of ELKS after all?

Interoperability.

Quote:
> Will the compiler implementers follow this this standards?

Yes, if customers tell their vendors that interoperability is more
important than diversity.

Regards,
Roger

Here is the ELKS 2000 ARRAY proposal. It was adopted by the NICE Board
in March 2000.

=====================
ELKS 2000 ARRAY class
=====================

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

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

Every part of the ARRAY 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
explored many underlying issues relating to the nature of kernel
classes in Eiffel and to the formulation of Eiffel library standards.
We have looked in detail at every feature of the class. More messages
have been exchanged about the ARRAY class in the past six months,
than about all NICE library issues in the previous eight years.

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
=======================

For the first time, an ELKS class has been fully-specified by means
of assertions. This yields some precise but lengthy postconditions
that use recursion to assert a condition over all elements of the
ARRAY.

Please note the following points:

  - Eiffel turns off assertion checking for features called within
    an assertion, so the recursive postconditions are not fully
    executable.

  - 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.

Three 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 three queries.
All commands are specified by their effect on the values of these
three queries. This approach is due to James McKim, and has enabled
us to fully-specify the ARRAY class.

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

Remove features `make_from_array' and `to_c'.

   We could not find a way to include these features in ELKS 2000 in
   a way that was meaningful, interoperable, and readily
   implementable by all vendors. 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 `is_empty', `subarray', `all_default', `same_items', and
`clear_all'.

   We considered these features to be very useful, and easy to
   implement in a way that is interoperable. Many of these features
   are already implemented outside of ELKS 1995 by one or more
   vendors. Some of these new features are particularly useful in the
   specification itself.

Refine the specifications of `is_equal', `resize', and `force'.

   There is significant divergence in the current implementations of
   these features. We have refined these specifications to make them
   rigorous. We have specified these features in a way that should
   make it as easy as possible for all vendors to implement them, and
   should cause as little disruption to existing code as possible -
   but unfortunately some disruption seems unavoidable.

Refine the specifications of `valid_index', `count', `put', `item',

   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.


features `entry' and `enter'.

   There appear to be no technical barriers to removing the frozen

   `enter' redundant. Consolidating these features yields a cleaner
   and simpler class interface.

It is not possible in this short presentation to effectively
summarise the discussions that led to these changes. If you want
to know why these changes were considered appropriate, please
browse the archive of the discussions at
http://www.*-*-*.com/

We took a consensus poll for every one of these changes. The majority
of changes gained near-unanimous or unanimous support.

Proposed ELKS 2000 ARRAY class
==============================

----------------------------------------------------------------------
indexing

   description: "Sequences of values, all of the same type or of a %
                %conforming one, accessible through integer indices %
                %in a contiguous interval"

class interface

   ARRAY [G]

creation

   make (min_index, max_index: INTEGER)
      -- Allocate array to hold values for indexes in
      -- `min_index' .. `max_index'.
      -- Set all values to default.
      -- (Make array empty if `maxindex' = `minindex' - 1).
      require
         valid_bounds: min_index <= max_index + 1
      ensure
         lower_set: lower = min_index
         upper_set: upper = max_index
         items_set: all_default

feature -- Basic specifiers

   item (i: INTEGER): G
      -- Item at index `i'.
      require
         valid_index: valid_index (i)

   lower: INTEGER
      -- Minimum index

   upper: INTEGER
      -- Maximum index

feature -- Access


      -- Item at index `i'.
      require
         valid_index: valid_index (i)
      ensure
         definition: Result = item (i)

feature -- Measurement

   count: INTEGER
      -- Number of available indices
      ensure
         consistent_with_bounds: Result = upper - lower + 1

feature -- Comparison

   is_equal (other: like Current): BOOLEAN
      -- Do both arrays have the same `lower', `upper', and items?
      -- (Redefined from GENERAL.)
      require -- from GENERAL
         other_not_void: other /= Void
      ensure -- from GENERAL
         consistent: standard_is_equal (other) implies Result
         same_type: Result implies same_type (other)
         symmetric: Result implies other.is_equal (Current)
      ensure then
         definition: Result = (same_type (other) and then
            (lower = other.lower) and then same_items (other))

feature -- Status report

   all_default: BOOLEAN
      -- Do all items have their type's default value?
      ensure
         definition: Result = (
            count = 0 or else (
             (item(upper) = Void or else
              item(upper) = item(upper).default)
              and subarray(lower, upper - 1).all_default
            ))

   is_empty: BOOLEAN
       -- Is array empty?
       ensure
          definition: Result = (count = 0)

   same_items (other: like Current): BOOLEAN
      -- Do both arrays have the same items?
      require
         other_not_void: other /= Void
      ensure
         definition: Result =
            ((count = other.count) and then
            (count = 0 or else
            (item (upper) = other.item (other.upper) and
              subarray (lower, upper-1).same_items
               (other.subarray (other.lower, other.upper - 1)))))

   valid_index (i: INTEGER): BOOLEAN
      -- Is `i' within bounds?
      ensure
         definition: Result = ((lower <= i) and (i <= upper))

feature -- Element change

   clear_all
      -- Set every item to its default value.
      ensure
         stable_upper: upper = old upper
         stable_lower: lower = old lower
         default_items: all_default

   force (v: like item; i: INTEGER)
      -- Make `v' the item at index `i', enlarging the
      -- array if necessary.
      ensure
         new_lower: lower = i.min (old lower)
         new_upper: upper = i.max (old upper)
         new_item: item (i) = v
         new_low_items:
            i < old lower implies
             subarray (i + 1, old lower - 1).all_default
         new_high_items:
            i > old upper implies
             subarray (old upper + 1, i - 1).all_default
         between_lower_and_i:
            subarray (old lower, ((i-1).max (old lower-1))
...

read more »



Fri, 07 Feb 2003 03:00:00 GMT  
 ELKS 2000 standard consequences?

Quote:

> > I'm Eiffel beginner and viewed ELKS 2000 draft standard. It seems
that
> > they are going to suggest quite heavy changes to the fundamental
> > classes, STRING and ARRAY.

> What do you consider to be the "heavy changes"? There are a few,
> perhaps, but only where there was no simpler path towards
> interoperability.

Maybe "heavy" was too strong word. When behavior of the basic classes is
changed (some methods removed and some others modified) it will cause a
lot of "heavy" work for many class library developer. But if this is the
only way to make Eiffel better and more compatible language then it must
be selected.

Quote:
> > Won't the existing libraries become incompatible
> > with ELKS 2000 compilers?

> Pre-2000 Eiffel compilers have enormous incompatibilities. It's
> extremely difficult to write interoperable code with pre-2000
compilers.
> ELKS95 was never fully-supported by any vendor, although some came
> closer than others.

> At last, things are improving: two vendors already support the ELKS
2000
> ARRAY class (the other two have not yet released an upgrade since ELKS
> 2000 was approved). After stagnating for many years, interoperability
is
> finally getting better.

What about concurrency? Will it be added to the ELKS standards in
future? Are the ELKS classes ready to meet the threads without further
modifications?

Timo



Sat, 08 Feb 2003 13:42:14 GMT  
 ELKS 2000 standard consequences?

Quote:

> What about concurrency? Will it be added to the ELKS standards in
> future?

The "SCOOP" design for Eiffel concurrency is a language mechanism (as
well as a library mechanism), so it would need to be a NICE language
standard rather than just a part of ELKS (the "Eiffel Library Kernel
Standard").

But SCOOP has not yet been implemented, so standardisation seems
premature.

Regards,
Roger
--

19 Eden Park Lancaster LA1 4SJ UK - Phone +44 1524 32428



Sat, 08 Feb 2003 03:00:00 GMT  
 ELKS 2000 standard consequences?

Quote:


>> What about concurrency? Will it be added to the ELKS standards in
>> future?
>The "SCOOP" design for Eiffel concurrency is a language mechanism (as
>well as a library mechanism), so it would need to be a NICE language
>standard rather than just a part of ELKS (the "Eiffel Library Kernel
>Standard").
>But SCOOP has not yet been implemented, so standardisation seems
>premature.

Sorry but SCOOP is dead and also as much braindead as ISE's so called
multithreading (because it is not multithreading, it is multiprocessing).
I think what we need is a simple THREAD and SEMAPHORE class, perhaps
with a synchronized language feature or - my preferred way - an aspect
language extension for synchronising.

But the eiffel community is evolving as fast as a turtle, so i think
we can expect this at least in the year 2020.

Bye

  Lothar
--
------------------------------------------------------------------
                Make Love, Not Programs



Sat, 08 Feb 2003 03:00:00 GMT  
 ELKS 2000 standard consequences?

Quote:
> I think what we need is a simple THREAD and SEMAPHORE class, perhaps
> with a synchronized language feature or - my preferred way - an aspect
> language extension for synchronising.

The ISE EiffelThread library provides these simple notion since 1997 and
even more.

Quote:
> But the eiffel community is evolving as fast as a turtle, so i think
> we can expect this at least in the year 2020.

It is already here, no need to wait.

Regards,
Manu



Sat, 08 Feb 2003 03:00:00 GMT  
 ELKS 2000 standard consequences?
Doh !


Quote:


> >> What about concurrency? Will it be added to the ELKS standards in
> >> future?

> >The "SCOOP" design for Eiffel concurrency is a language mechanism (as
> >well as a library mechanism), so it would need to be a NICE language
> >standard rather than just a part of ELKS (the "Eiffel Library Kernel
> >Standard").

> >But SCOOP has not yet been implemented, so standardisation seems
> >premature.

> Sorry but SCOOP is dead and also as much braindead as ISE's so called
> multithreading (because it is not multithreading, it is multiprocessing).
> I think what we need is a simple THREAD and SEMAPHORE class, perhaps
> with a synchronized language feature or - my preferred way - an aspect
> language extension for synchronising.

> But the eiffel community is evolving as fast as a turtle, so i think
> we can expect this at least in the year 2020.

> Bye

>   Lothar
> --
> ------------------------------------------------------------------
> Make Love, Not Programs




Sun, 09 Feb 2003 03:00:00 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. Request for comments: proposed ELKS 2000 ARRAY class

2. ELKS 2001 STRING class is now an official standard

3. Year 2000 standards

4. FORTRAN 2000 STANDARDS

5. Fw: Jforum: ICFP 2000 Programming Contest, August 26-29, 2000

6. QuickDDE, Word 2000 & Windows 2000

7. ICFP 2000 Programming Contest, August 26-29, 2000

8. ICFP 2000 Programming Contest, August 26-29, 2000

9. Extensive cobol year 2000 methodology by TOPIC-2000

10. Cobol year 2000 solutions by TOPIC 2000

11. FTP 2000 and TABLEAUX 2000 - Call for Participation

12. ICCI '2000 CFP: Papers Due March 1, 2000

 

 
Powered by phpBB® Forum Software