Re: Eiffel syntax and the ';'

There are many programming languages where semicolons are
not always needed.

    Fortran 90 and later:
	Semicolons are needed between statements on the same line.
	They are not used at the end of a line.

    BCPL and AWK:
	Semicolons are optional if the end of a line coincides
	with the end of a statement.  (The rules are slightly different
	between the two, but work pretty well.)

    Haskell and Clean:
	Semicolons and curly braces are optional if you indent properly.

In all those languages and others like them
	x.f
	(x+x).f
*CANNOT* possibly be read as x.f(x+x).f.

EIFFEL IS DIFFERENT!  Eiffel is the only language I have come across
where (1) semicolons are sometimes optional
 AND  (2) the newline has NO special significance.

(1) is not the problem.  (2) is.  As far as Eiffel is concerned,
there is *NO* relevant difference between
	x.f
	(x+x).f
and
	x.f    (x+x).f

It is this which creates the ambiguity in Eiffel syntax, and it is a
real ambiguity, to the point where the ECMA standard (ECMA-367, at
http://www.ecma-international.org/publications/standards/Ecma-367.htm)
no longer allows (x+x).f, requiring it to be written as (|x+x|).f

alan lamer <[email protected]> wrote:
	Well, beyond the fact the first interpretation was of
	course intended, the second interpretation is always
	false since Eiffel doesn't allow function polymophism.
	So as long as 
	   class X
	      [...]
	   feature
	       f is do .... end
	       f (x: Y) is do .... end
	      [...]
	   end
	is forbidden, there can't be any ambiguity.
	
*Semantically*, no.  However, ECMA Eiffel is described as a 
"design" language, amongst other things, so a syntax checker is supposed
to be able to make sense of a text *without* having access to the
definition of the class x is declared with.

	Again, as long as overloading is not allowed in Eiffel
	for function prototypes (such as in C++), the code i
	wrote was definitively not a mistake since there is no
	ambiguity.

Just because there is no ambiguity doesn't mean there is no mistake.
What if there is *no* f feature for x, or the unique f feature for x
has two or more arguments?

	And according to the response of Berend de Boer, i
	will consider this as a compiler bug.
	
This particular issue has been beaten to death in this mailing list.
This is *not* a compiler bug, it is a defect in Eiffel syntax, and
it is *recognised* as a defect in Eiffel There; the ECMA standard
makes the x.f; (x+x).f reading syntactically illegal (and therefore
unavailable; the x.f(x+x).f reading is *required*).