Re: Parenthesized Target Notation (was: Partial retraction)

Richard A. O'Keefe wrote:
> But it takes a lot of stuff away, to the point where none of the files
> in the Gobo 3.3 release could be compiled by a compiler that enforced
> ECMA Eiffel rules.

Many people asked me to make public my point of view on this matter.
Speaking about Gobo 3.3, it still works with the latest versions of
ISE and VE (possibly with very minor changes). It does not with SE.
Then, the only thing I could read here is some comparison of a
language description (ECMA Eiffel) with a compiler
implementation (SE). For me SE is not a language. It is the
implementation of an unspecified language. So far the aim of Gobo
was not to support a language specification. Gobo does not support
ETL2. Why should it do that if in the end the resulting libraries
don't compile with the existing Eiffel compilers. So what is Gobo about
is to try to provide libraries that compile and work with all supported
Eiffel compilers. And this is not only about dealing with various
language dialects and kernel library variants implemented in each
Eiffel compilers but also taking into account bugs that may remain.
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. And since Gobo is not about supporting ETL2 or
ECMA Eiffel but existing Eiffel compilers, as long as it is possible
to write code that compile and works with all these Eiffel compilers
there is no real problem. On the other hand the problem with SE
(apart from the fact that the language that it implements -- now
that it claims that it is not ETL2 nor ECMA Eiffel -- is not
documented) is that it gratuitously introduce backward incompatibilies
between versions (even between minor releases). Here I speak about
the compiler, not the language. This has caused (and probably still
causes) a lot of troubles not only to people who try to develop
portable Eiffel libraries such as Gobo, ePosix and Paul Crismer's
projects, but also to SmartEiffel users. So, determining who forks
and who does not is of little interest to Gobo. What counts is that
compilers provide backward compatibility. And so far SE failed in
this area. This as forced Gobo developers to put a lot of effort
to support SE 2.1 (in CVS version only), and I heard that it is
not finished because new incompatibilities have been introduced
in SE 2.2 such as the removal of the -case_insensitive option
or the removal of `clone' in ANY (which was not even marked as
'obsolete' in SE 2.1). So what worries me now is not the
ECMA Eiffel language (even though I don't agree with everything
in this specification, but that's another story) but rather
the fact that I will have to spend yet again some time and effort
to support the SE 2.2 compiler.

-- 
Eric Bezault
mailto:[email protected]
http://www.gobosoft.com