Re: Parenthesized Target Notation (was: Partial retraction)

Le mardi 3 Mai 2005 09:32, Ian Elliott a écrit :
> Richard A. O'Keefe wrote:
> > Concerning
> >
> > 	>	  require
> > 	>	  h
> > 	>	  (a + b).g
> >
> > =?ISO-8859-1?Q?Val=E9ry_Croizier?= <[email protected]> wrote:
> > 	The ambiguity remains because 'h' could be either a parameterless
> > 	feature or a feature that takes one argument.
> >
> > Yes, avoiding the ambiguity means not shutting your eyes to everything
> > you know.
> >
> > There are other places in the new syntax where there are, um,
> > awkwardnesses. Now that there are both 'bracket aliases' _and_ tuples, I
> > invite you to consider the possible confusions.
> >
> > 	Sure, it was a bit late to change one's mind ...
> >
> > Exactly so.
>
> Concerning semicolons: a semicolon in Eiffel is used to separate or
> terminate elements within certain lists. For example, a semicolon is used
> to separate or terminate instructions in a compound, index clauses in an
> indexing, assertion clauses in an assertion and declaration groups in a
> declaration list. A semicolon is often optional. An example that does
> illustrate a necessary, i.e. not optional, semicolon is:
>
> 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
>
> For current Eiffels the rule is:
>
>     A semicolon is optional, except where it is not optional
>
> This is not as silly as it sounds since it can be expanded to:
>
>     if you remove a semicolon and the result is code that would be parsed
> to produce a different list of elements then the semicolon is not optional
> and, conversely, if you remove a semicolon and the result is not a
> different list of elements then the semicolon is optional
>
> So a parser can decide whether a semicolon is optional or necessary.
>
> The semicolon is a slippery customer: the following semicolon looks
> necessary but is in fact optional:
>
> Example 2)
>     do
>        create x;
>        (p + q).r
>
> More importantly there are additional instances of necessary semicolons:
>
> Example 3)
>     ensure
>        b;
>        -m > n
>
> And:
>
> Example 4)
>     ensure
>        tag_only:;
>        b
>
> In the last example removing the semicolon results in a parse that
> identifies just one element rather than the original two.
>
> For current Eiffels, here is an analogous example in indexing:
>
> Example 5)
>     indexing
>        tag_only:;
>        01, May, 2005
>
> 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, I do not know of a list of necessary semicolon
> instances that claims to be complete, perhaps there are more instances to
> be uncovered.
>
>   - Ian Elliott

yes and also the notation (|..|) does not solve the problem that it is figured 
to solve!

here is the imaginary construct that prove it:

stage 1: i declare a feature f that return a boolean so i use it in a require

	require 
		f

stage 2: i change f to be f(INTEGER):INTEGER and add the (arg+3).is_positive 
in the same require but i forget to use the notation (|...|) because i  use 
it very rarely and have difficulties to change (or i am seek and tired)

	require 
		f
		(arg+3).is_positive

Yes there are many IFs in that demonstration but ... the risk does not 
desappear

however i would like to say here that i would prefer an eiffel language that 
sounds well (and etl2 was ok to me) but only one language with perhaps a 
small account of very near variants.

please all you that have some power on that please do your best to make eiffel 
a good choice for the industry of software. industry can accept compromises. 
can researchers and universities accept compromises too?

regards

jb