Re: Partial retraction (was: Re: catcalls/convert)

I think there is currently an overreaction to this standard.

On Fri, 2005-04-29 at 13:41 +1200, Richard A. O'Keefe wrote:
> I have an apology to make.  I have defamed the ECMA Eiffel draft.
> 
> (...)
>     The changes to Eiffel in the ECMA draft make
>     EACH AND EVERY CLASS IN ELKS 2001 SYNTACTICALLY ILLEGAL.
>
> Take, for example, the ELKS 2001 STRING class.  It starts out
> 
>     indexing
>       description: "Sequences of characters, accessible through %
>                    %integer indices in a contigous range starting %
>                    %from one."
>     class STRING
>     
> But there is no 'indexing' keyword in ECMA Eiffel.

You are right. Strictly following this standard breaks about every
Eiffel class lying around.

However, these kind of standards are not made to be strictly followed.
"What's the point of that?", you might wonder, "aren't standards made to
be followed"?

Actually, most standards prescribe what a system must do when receiving
valid input (where "valid" is also defined by the standard), and perhaps
specifying some inputs that should be rejected, but normally the
behaviour for invalid input is unspecified. The specification is very
much like a contract, it has a preconditions, and properties which are
satisfied when that precondition is true.

It is true that a big all-covering standard promotes coding without
caring for interoperability and still achieving it (That is the way that
the Java Specification was designed). But in any practical case, you
will see that compilers implement the standard, and a few nice extra
features.

Be sure that any ECMA compatible Eiffel compiler, opensource or
privative, friendly with ECMA or not, will support some extra stuff.
Let me place my bet that one of the extensions will be allowing
"indexing", even if it supports the new "notes" keyword.

It's good practice for standards to eliminate all ambiguous and
potentially dangerous stuff, to an extent. For a counterexample, you
have the HTML4.01 spec, which allows a lot of "old but compatible"
features, and several ways of parsing to allow for a somewhat broken
input. It's a huge spec, and very hard to implement. Luckily, the W3C
recognized the mistake soon and the XHTML1.0 spec came, which is a lot
more stricter; web browsers are allowed to accept somewhat broken XHTML,
if they manage to parse it, but the spec was not made overcomplicated to
include all possible forms of breakage.

So let me place another bet on having << >> for a long time, in *any*
Eiffel compiler, even when it's not in the ECMA standard.

I'm not saying that the ECMA standard is good. A standard should not
lead the innovation; it should be conservative and try to get written
down the things that people is already doing, perhaps settling things
when people are doing something already but in different ways. I don't
like the ECMA standard in that sense, it has too much new stuff.

However, I don't think it's that a great risk for Eiffel, it will at
least provide some common ground to write portable Eiffel software.

> ...
> Unfortunately, there is no way to choose an identifier for this purpose
> without understanding a great deal of Eiffel syntax and semantics,
> because the identifier here must be distinct from all other feature
> names in the class.  Even a fixed table of mappings won't do, because
> it won't help with "free" operator names.  Suddenly, converting to
> ECMA Eiffel got a lot harder.

What compiler writers should do is allow both syntaxes (perhaps issuing
a warning for the old form)


> 5.  There are lots of new keywords.  It is hard to tell just how many,
>     because no part of the draft lists them all.  (You'd expect a list
>     in section 8.32, but there isn't one.)  Certainly 'use', 'only',
>     'windows' are used as keywords (is there a message here?).

:)

> 12. There is a whole lot of stuff that is apparently designed to make
>     it possible to ensure at compile time that the target of a call is
>     not Void.  I like the idea.  BUT amongst other things, there is an
>     "attachment mark" '?' or '!' that goes in a type.  8.11.1
> 	Class_type = [Attachment_mark] Class_name [Actual_generics]
> 	Attachment_mark = "?" | "!"
>     There appears to be no way of distinguishing between !like Current
>     and ?like Current and I can't tell which of these like Current is to be.
>     A type is 'detachable' (that is, variables of that type may be Void)
>     if and only if it has a "?" mark.  A missing mark is equivalent to
>     "!", meaniing 'attached' (variables of that type may NOT be Void).
>     This is a radical change.  Currently,
> 	
>        eat(some: FOOD) is ...
> 
>     allows some to be Void.  But in ECMA Eiffel, it doesn't.  You would
>     have to write
> 
>         eat(some: ?FOOD) is ...
> 
>     instead.  I must stress this:  *every* use of a non-expanded type
>     in ECMA Eiffel means something different from what it used to mean.

This is the only change I saw in your list that would be really
difficult to implement, while accepting the old syntax at the same time.
I hope it dies in the draft!

> The consequences are great.

IMHO, they won't be that great. All languages evolve, standards just
keep some sync on all subspecies, but they will never harm too much
backwards compatibility or possibility of extensions. You can see this
looking at other standards and the reall effect they've had.

Cheers,
	Daniel