Bruno Medeiros wrote:
> Derek Parnell wrote:
>> On Fri, 9 Dec 2005 12:52:54 -0800, Kris wrote:
>>
>>> It may be that D documentation does not explicitly state this behaviour, but it perhaps should? 
>>
>>
>> Yes, that would clear things up nicely.
>>
>> I guess that a statement such as
>>     b + c + d;
>>
>> could evaluate to
>>
>>     b.opAdd(c).opAdd(d)
>>
>> or
>>
>>     d.opAdd(c).opAdd(b)
>>
> Doubtful. It is not clear in the spec, but I bet in D the operator evaluation order is well-defined, and is the same as C/C++. Thus "b + c + d" evaluates to:
>   ((b + c) + d)
> and then to the corresponding opAdd's. And the function call operator sequences evaluate left to right too.
> What is not well defined, both in C/C++ and in D are the expression *components* order of evaluation. Stuff like (straight from the docs):
>   i = ++i;
>   c = a + (a = b);
>   func(++i, ++i);
> which is an ambiguity that you *can not even* resolve with parenthesis.

Exactly.  In fact, most of this behavior is undefined in C++ for this very reason.  For example, it is illegal to modify a scalar value more than once in an expression.  One such example of undefined behavior in C++ is this:

i = a[++i];


Sean

Manfred Nowak wrote:
> Kris wrote:
> 
> [...]
>> To address your example, these two expressions are not
>> equivalent ~ they're barely even related:
>>
>> 1)  classRef.method1().method2().method3();
>>
>> 2)  classRef.method1(), classRef.method2(), classRef.method3();
>>
>> Does that help? 
> 
> No. I see your arguments as beeing totally contradictory.
> 
> The evaluation order under 1) is undefined per defintition, whereas the order of evaluation under 2) is defined by left to right evaluation and in addition returning the type of the rightmost assignexpression.
> 
> If you cannot recognize the contradiction to your own argument given in the part cited with [...] it is useless to post any further.

I don't think Kris meant to imply that the comma operator was being used in method 2.  I think he was using that syntax because it was what you used in the post he replied to.


Sean

Bruno Medeiros wrote:
> Doubtful. It is not clear in the spec, but I bet in D the operator evaluation order is well-defined, and is the same as C/C++. 
In fact, check the D expressions spec( http://www.digitalmars.com/d/expression.html ) and a C/C++ operator precedence table ( http://www.difranco.net/cop2220/op-prec.htm ) . You can note that the D grammar has the operators occuring in the exact inverse order as the precedence table, i.e., the grammar is built to support the same precedence semantics as C/C++ .
Walter should state this explicitly on the spec, though.

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."

Manfred Nowak wrote:
> Kris wrote:
> 
> [...]
> 
>>An implementation might then execute each method in
>>random order, but what's the point?
> 
> [...]
> 
> Other way round: what's the point to not define the order?
> 
> Because the compiler might see optimizations and adaptions to the underlying hardware which now everyone is unable to imagine.
> 
> Future is always unpredictable ;-)
If the order is not defined, then each implementation would be able to choose a different order, which would yield different program results. That is no optimization, and such ambiguous code would be useless.

> 
> Therefore Walters decision to not define the order is correct in the general case. If you want it defined split the expression by using parentheses or temporal variables.
> 
You are under some wrong assumptions. See my post replying to Derek.


-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."

Sean Kelly wrote:

[..]
> I don't think Kris meant to imply that the comma operator was being used in method 2.  I think he was using that syntax because it was what you used in the post he replied to.

Maybe, but he uses the word "expression" together with a `;' at the
end of that "expressions". I did not use either and when I want to
insert a peace of code into plain text I use  "`" and "'" to express
that. Agreed, that I forgot on this by writing

| Stdout.opCall(CR), Stdout.opCall("hello"), ...

instead of

  `Stdout.opCall(CR)', `Stdout.opCall("hello")', ...

which I intended to be an enumeration of a set of calls in natural language.

And agreed also, that we will babelize all discussions if we use notations that are ambiguous.

-manfred

In article <dnd99m$1j9d$1@digitaldaemon.com>, Bruno Medeiros says...

[...]

>If the order is not defined, then each implementation would be able to choose a different order, which would yield different program results. That is no optimization, and such ambiguous code would be useless.


Ambiguous code, as described above, is illegal code. If order of evaluation makes a difference, that the compiler can flag it as an error.


from docs:

"Unless otherwise specified, the implementation is free to evaluate the
components of an expression in any order. It is an error to depend on order of
evaluation when it is not specified.
[...]
If the compiler can determine that the result of an expression is illegally
dependent on the order of evaluation, it can issue an error (but is not required
to). The ability to detect these kinds of errors is a quality of implementation
issue."


as to the evaluation of the "wisper syntax" how about the following

struct A
{
int opCall(int);
}

struct B
{
B opCall(A);
B opCall(int){return this;}
}

A a;
B b;

int i;

// is this
b.(a)(i);

//this
int t1 = a.opCall(i)
b.opCall(t1);

//or this
B t2 = b.opCall(a);
t2.opCall(i);

Bruno Medeiros wrote:

[...]
> the grammar is built to support the same precedence semantics as C/C++ .
[...]

Then what? What has precedence to do with evaluation order and associativeness?

But this deviations should be entered into the "C to D" and "C++ to D" guides.

-manfred

BCS wrote:
> In article <dnd99m$1j9d$1@digitaldaemon.com>, Bruno Medeiros says...
> 
> [...]
> 
> 
>>If the order is not defined, then each implementation would be able to choose a different order, which would yield different program results. That is no optimization, and such ambiguous code would be useless.
> 
> 
> 
> Ambiguous code, as described above, is illegal code. If order of evaluation
> makes a difference, that the compiler can flag it as an error.
> 
> 
> from docs:
> 
> "Unless otherwise specified, the implementation is free to evaluate the
> components of an expression in any order. It is an error to depend on order of
> evaluation when it is not specified.
> [...]
> If the compiler can determine that the result of an expression is illegally
> dependent on the order of evaluation, it can issue an error (but is not required
> to). The ability to detect these kinds of errors is a quality of implementation
> issue."
> 
> 
> as to the evaluation of the "wisper syntax" how about the following
> 
> struct A
> {
> int opCall(int);
> }
> 
> struct B
> {
> B opCall(A);
> B opCall(int){return this;}
> }
> 
> A a;
> B b;
> 
> int i;
> 
> // is this
> b.(a)(i);
> 
> //this
> int t1 = a.opCall(i)
> b.opCall(t1);
> 
> //or this
> B t2 = b.opCall(a);
> t2.opCall(i);
> 
> 

That's complete nonsense.  I don't see what you're getting at.

`b.(a)' is not a valid expression according to the docs (http://digitalmars.com/d/expression.html).

A dot operator must be followed by an /Identifier/ in all the expression rules stated on that page.  If these rules were written such that an /Expression/ would follow the dot operator, then your case would make *some* sense.

If you have any argument, then please point me to the docs where it says this expression is legal.

BCS wrote:

[...]
> as to the evaluation of the "wisper syntax" how about the following
[...]

Wohoo! Second strike. You are really clever!

Your idea reminds me on how the macro processor "m4" evaluates the arguments given to its macros.

-manfred

James Dunne wrote:

[...]
> If you have any argument, then please point me to the docs where it says this expression is legal.

You are right in that there is a typo. Simply suppose that it should
be read
  `b(a)(i);'
-manfred