Re: Parenthesized Target Notation (was: Partial retraction)

In response to something of mine,
Eric Bezault <[email protected]> wrote:
	Then, the only thing I could read here is some comparison of a
	language description (ECMA Eiffel) with a compiler
	implementation (SE).

Not so.  No such comparison has been made by me in this thread.

I assert that ECMA Eiffel does not merely make additions to Eiffel,
but also removes and changes enough to count as a fork in the language.

That assertion does not in any way depend on or refer to SmartEiffel.
It's a comparison of one language description (ECMA Eiffel) with two
others (ETL2 and OOSC2).

For the record, I was very happy with SmallEiffel, but SmartEiffel 2
is _also_ a big change from ETL2.  Some of the things in SmartEiffel are
additions (tuples, agents, sized integers) and some are changes (the
change in meaning of array syntax).  I have elsewhere argued that the
addition of sized integers to SmartEiffel did *not* necessitate changing
the meaning of an array expression like <<1,2>> _in an incompatible way_.

Eirc Bezault's response to my comments is thus based on a misreading of
them, as if I was in some fashion defending SmartEiffel.  Not so.  I want
a professional quality ECMA Eiffel standard so that I can brandish it at
the SmartEiffel team and say "THIS is what I want".

Unfortunately, the present state of the ECMA standard is such that I
*don't* want it, and I'm left in the unhappy situation that SmartEiffel,
with all its changes, is closer to the ETL2 I knew and loved than ECMA Eiffel.
want

	So far the aim of Gobo
	was not to support a language specification.

My claim is not that Gobo should support a language specification,
but that the language specification should support Gobo.
Not that it should include Gobo (although that might not be a bad
idea; currently there is nothing in the standard even saying what
is in INTEGER_GENERAL), but that it should not go out of its way
to increase the difficulty of adapting the Gobo library to the new
language.

	You complained that ECMA Eiffel was not backward compatible. As far
	as Gobo is concerned, it is not a real problem. Indeed, as someone
	already pointed out there is no doubt that ISE and VE will do their
	best to offer compiler options to try to remain as backward compatible
	as possible (at least during a long period of time) while providing
	language extensions.

I have pointed out before that
(a) this relies on the good will of Eiffel compiler vendors,
    but if we could rely on the good will of Eiffel compiler vendors to
    provide us with compatible interfaces, we would never have needed
    an ECMA standard in the first place.
(b) this relies on the assumption that nobody ever wants to have a
    source file which is *partly* old and *partly* new, and yet anyone
    who has maintained C code through the K&C -> C89 transition or who
    has maintained Fortran code through the Fortran 77 -> Fortran 90 ->
    Fortran 95 transition knows that in practice, you usually have to
    convert a large system a little at a time.  So you need
	- programs where some files conform to the old practice
	  and some conform to the new
	- single files where some parts use old features and some use new
    not because you aren't converting to the new specification, but    
    because you ARE.

	On the other hand the problem with SE ...
	is that it gratuitously introduce backward incompatibilies
	between versions (even between minor releases).

And that is my problem with the ECMA Eiffel specification:
*gratuitous* backward incompatibilities.

I would still value Eric Bezault's comments in reponse to my substantive
points about ECMA Eiffel, freed of the misapprehension that my comments
are somehow a defence of SmartEiffel.