Re: ECMA standard or forking the language?

Richard A. O'Keefe wrote:

>Concerning the "fork" issue, my perspective from my recent close reading
>of the ECMA draft is that it is not the SmartEiffel team who are forking.
>ECMA is the fork.
>  
>
Well, we warned you long ago.
http://wwsympa.loria.fr/wwsympa/arc/smarteiffel/2003-07/msg00029.html
http://wwsympa.loria.fr/wwsympa/arc/smarteiffel/2004-09/msg00137.html

>What I mean by that is that ECMA Eiffel is not just different from
>SmartEiffel, but it is radically incompatible with ETL2 and OOSC2.
>Let's see, I have ETL2, OOSC2, and a software engineering book based
>on Eiffel.  Very very little of the stuff I learned from these books
>is legal in ECMA Eiffel.
>  
>
Alas :-(

>And it didn't have to be that way.
>
>There is lots of good new stuff.  While I find the conversion machinery
>in ETL3/ECMA/ISE distasteful and very much against the software engineering
>spirit that was supposed to characterise Eiffel, it doesn't actually break
>anything.  Agents and tuples are a great idea, and with the exception of
>one new keyword, which is fairly easy to deal with, don't break anything.
>The new sized types {CHARACTER,INTEGER,REAL}_<size> don't _have_ to break
>anything, and with ECMA's rule that integer literals are still of type
>INTEGER, _don't_ break anything.  Object test is nice,
>
... Sure but it introduced variables you declare on the flow. We
designed a notation that fixes the problems of ?=. At that time AFAIR
they did *not* want to remove that notation, invented every argument
against ours, they did not see the problem and so on ... and finally
produced that "thing".

But *we* did not remove ?=

> and doesn't break
>anything.  Types as values -- {CHARACTER} is, amongst other things, an
>expression of type TYPE[CHARACTER] -- has many potential uses, or would,
>if the ECMA standard told us about any features of TYPE, and as far as I
>can see, don't break anything.
>
>But eliminating !! creation syntax, ?= assignment attempt, << >> array
>literals, and (x + y).f plain-parenthesised targets in calls, amongst
>other things, DO break lots of code, without sufficient reason.
>  
>
Note that we re-introduced << >> but with a cleaner semantics. Still, it
does produce an ARRAY ;-)

>That's a fork.
>  
>
Indeed :-(

>It is really depressing that 20 years after Eiffel saw the light of day
>we still do not have a standard set of container classes.  The only
>container class in _any_ official Eiffel standard is ARRAY.  Never mind
>the C++ Standard Template Library, Eiffel still can't match Java!  Yes,
>I am aware of the GOBO library, and I have it, and what a wonderful
>service to the Eiffel community it is.  But it isn't _standard_ and it
>keeps on needing to be re-ported.  Why can't NICE or ECMA simply adopt
>the GOBO library and say "vendors may of course provide as many other
>libraries as they want"?  Would the 15 or so maintainers of GOBO really
>object to this, or fail to co-operate?  Surely not.
>  
>
Note that Eric Bezault belongs to the ECMA process. Maybe such
large-scale changes do not bother him.

Best regards,

Cyril