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

Where did you download the document ?
The one I found at http://www.inf.ethz.ch/personal/meyer/#Progress 
(LANGUAGE.pdf) has 1650 pages, and includes some items you didn't find 
in yours (list of keywords, specification of ELKS classes, etc.). There 
is no 8.23.2, but a 23.2 instead, and it doesn't mention restrictions 
for multidot calls.
Annex F lists the differences from the previous standard.

Valéry.

Richard A. O'Keefe a écrit :

>I have an apology to make.  I have defamed the ECMA Eiffel draft.
>
>When you download EIFFEL-STANDARD.pdf file from the ETL3 site,
>what you get is indeed 762 pages.  But those 762 pages are not
>just the current draft, but several drafts.  The current draft
>is just 138 pages.
>
>138 pages really isn't that bad, and I finally managed to slog
>my way through all of them last night.  That's when I noticed
>"hey, I've seen this section before"...
>
>However, these 138 pages include NO actual class definitions, and by
>that I mean none whatsoever.  We are not told in this draft what
>features are available from ANY, what features are available from
>BOOLEAN (except for the three non-strict operators "and then" "or else"
>and "implies"), what features are available from CHARACTER, CHARACTER_8,
>or CHARACTER_32, &c &c &c.
>
>Anyone who has read it might be tempted to ask "but doesn't the
>Normative Reference to the "Eiffel Library Kernel Standard,
>2001 vintage" answer this?  Why does the ECMA standard need to
>spell things out when it has been done already?
>
>It's a good question with a remarkably simple, and remarkably
>unpleasant, answer.
>
>    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.
>The first non-comment token of an ECMA Eiffel class must be
>notes, deferred, expanded, frozen, or class.
>You *cannot* appeal to to an earlier specification when you have
>ensured that everything it says must be rejected at line 1!
>The ELKS classes have, in ECMA Eiffel, no meaning whatever.
>And that is why ECMA Eiffel needs to respecify them.
>
>But it gets worse.  The change from 'indexing' to 'notes' is so
>trivial that a tiny AWK or Perl script could fix it.  (It's such
>a trivial change that one is left wondering what the point of
>such a breach with the past might possibly be.)  That's not enough.
>
>Look at
>
>    infix "<"(other: STRING): BOOLEAN
>       ...
>
>This is now illegal, and the fix is not so simple.
>Formerly, a feature could have a name of the form 'infix "op"' or
>'prefix "op"'.  These constructions are no longer allowed.
>Instead there is a new form, 'alias "op"'.  Since you can tell
>whether the feature is unary or binary by counting the arguments,
>fair enough, we don't really need two different keywords.  So it
>looks as though a simple fix would be
>
>    alias "<"(other: STRING): BOOLEAN
>       ...
>
>and again a simple AWK or Perl script could fix it.  But no.
>'alias' cannot stand on its own.  In ECMA Eiffel, every feature
>must have a name that begins with a letter, whether it also has
>an operator form or not.  So what you *must* have is
>
>    less alias "<"(other: STRING): BOOLEAN
>
>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.
>
>Another example of why the appeal to ELKS won't work.
>As far as I can tell, ELKS 2001 is ELKS 1995 + revised ARRAY + revised STRING.
>ECMA Eiffel makes *essential* use in several places of a feature
>'default_create' in class ANY.  But there is no such feature in
>ELKS 1995 ANY, and if there is a later version of ELKS ANY, I have been
>unable to find it.  ECMA Eiffel needs its own specification of ANY.
>
>I have a short list of changes which adversely affect backwards
>compatibility.  This list is NOT about additions as such.  There
>are additions, such as agents and tuples, which I am very happy with,
>and which need not have any adverse effect on backwards compatibility.
>These are changes that break things.
>
>1.  'indexing' has been replaced by 'notes'.
>
>2.  'infix "op"' and 'prefix "op"' have been replaced by 'alias "op"'.
>
>3.  Features to be used as operators must ALSO have a plain identifer
>    name as well as an operator alias.  When you use the operator,
>    this plain identifier must (also) be available.
>
>4.  '!!' creation syntax is not just superseded by 'create' syntax,
>    it is completely gone.  While accepting 'create' as superior,
>    I don't see why the old syntax had to go.
>
>    However, '!' is used in two new (related) ways as part of an attempt
>    to eliminate void calls at compile time.
>
>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?).
>
>6.  Assignment attempt '?=' is completely gone.  There is no trace of it.
>    The nearest equivalent of
>	x ?= e
>    is
>        if {t: T} e then x := t else x := Void end
>    where T is the declared type of x and t is a new identifier.
>    In some ways, Object tests are superior to assignment attempts.
>    However, they do require you to write out the type in full again
>    and invent a new identifier, so in some ways, assignment attempt
>    is superior.  In any case, I don't see why it should be completely
>    removed just because there is now an alternative.
>
>7.  It used to be a property of Eiffel (in my view a regrettable one)
>    that no declarations could occur inside a feature body.  Now they
>    can.  For example,
>	declare
>	   v1 : constant T1 := e1;
>	   ...
>	   vn : constant Tn := en;
>        begin
>           -- statements
>        end
>    in Ada has a close equivalent in ECMA Eiffel's
>        if {v1 : T1} e1 and then
>           ... and then
>           {vn : Tn} en
>        then
>           -- statements
>        end
>    where I am assuming the types are such that the tests all come out				 
>    true.  This will have consequences for "find declaration" commands
>    in Eiffel-aware editors.
>
>8.  Array literal syntax is completely gone.  We've had many arguments
>    in this mailing list about what << ... >> should do.  ECMA Eiffel
>    cuts the Gordian knot.  There is no such syntax.  However, ECMA
>    Eiffel has replaced the Gordian knot with the serpents of Laocoon:
>    some tuple expressions are also array expressions, so
>	[1,2,3,4]
>    *might* indicate a TUPLE[INTEGER,INTEGER,INTEGER,INTEGER] or it
>    *might* indicate an ARRAY[INTEGER].  More accurately, such an
>    expression belongs to some type which simultaneously conforms to
>    both.
>
>9.  The identifier in an anchored type must be a feature name or Current.
>    (It is valid to use an anchored type AT of the form "like anchor"
>    in a class C if and only if it satisfies the following conditions:
>        1 anchor is either current or the final name of a query of C
>        2 anchor is not a cyclic anchor
>        3 the deanchored form UT of AT is valid in C.)
>    Since formal arguments are not queries,
>        standard_equal(some: GENERAL; other: like some): BOOLEAN
>    and
>        stripped(other: GENERAL): like other
>    (both from ELKS 1995's GENERAL class) are now illegal.
>
>10. Suppose a is a feature of Current, b is a feature in the class of
>    a's type, and c is a feature in the class of b's type.  Then
>	a.b.c
>    is a Call.  But if a is a formal argument or a local variable of
>    some method, a.b.c is NOT a Call.  I suspect this is a mistake,
>    but it _is_ what 8.23.2 currently says.
>
>11. A call of the form (e).unqualified_call, such as
>	(n + 1).to_real_64
>    is now illegal.
>    Instead special target brackets (|...|) must be used, e.g.,
>	(| n + 1 |).to_real_64
>
>    I cannot think what problem (||) might be intended to fix;	
>    perhaps the SmartEiffel team can tell us how it might help them.
>    Existing code such as (once "eE").has(last_character) is now
>    illegal.  What benefit could repay that loss?
>
>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.
>
>The list is short (and surely incomplete).
>
>The consequences are great.
>
>  
>