Re: Parenthesized Target Notation (was: Partial retraction)

Ian Elliott <[email protected]> has got in ahead of me
and listed a number of other cases where a semicolon is required.
	Example 1)
	    do
	       x := y;
	       (p + q).r
	
	The use of barred parentheses (| ... |), under the new ECMA
	syntax, would render the semicolon above optional.  The
	introduction of these new parentheses does appear aimed at
	establishing the following semicolon rule:

	    A semicolon is optional
	
Unfortunately, barred parentheses are NOT sufficient to make that rule valid.
Ian Elliot has other examples:
	Example 3)
	    ensure
	       b;
	       -m > n
	
	Example 4)
	    ensure
	       tag_only:;
	       b

	The semicolon necessity in examples 3) and 4) could be removed
	if the ECMA standard demanded that an assertion clause always
	has a tag - like the required note_name for a note_entry in the
	new notes (was indexing) construct.

However, while the ECMA draft plugs one leak, it goes out of its way
to introduce a new one!

    {T}[expr]
	is a call to {TYPE[T]}.adapted(expr)
	which converts expr to type T, if that's possible.

    {T}
        is a Manifest_constant of type TYPE[T]

Now consider this example.

    invariant
        x = {T}
        [y] = z

Does this mean
	(x = {T}) and then			-- with semicolon
	([y] = z)
or does it mean
	(x = ({T}[y])) = z			-- without it

Come to think of it, there's another way that we may need a semicolon in
ECMA Eiffel:

    invariant
	b
	[c] = d

Does this mean
	(b) and then				-- with semicolon
	([c] = d)
or does it mean
	(b[c]) = d				-- without it

This uses the new "bracket alias" feature.

Do we need barred square brackets for tuples to make the semicolon
optionality rule true?  It really does seem unhelpful to break
backwards compatibility in order to fix the semicolon optionality
rule and ALSO introduce new ways to break the semicolon optionality rule!

We now have at least four things that square brackets may mean in ECMA
Eiffel:  - a tuple, an array, a bracket alias, an explicit conversion.
This does not seem to me to make Eiffel easier to read.

The use of bracket aliases in explicit conversion looks unhappily like
exploiting a syntactic quirk just because it is there.  I believe it would
be more in keeping with the spirit of Eiffel to spell out what's going on,
just as it was deemed more in keeping with the spirit of Eiffel to write
'create {T}' than '!{T}!'.  So

    convert {T} (expr)

for explicit conversions would be, well, an *explicit* conversion.