Chris Sauls wrote:
[...]
> Any expression, B, containing any operand whose value is taken from the result of another expression, A, must be evaluated /after/ the expression, A.  QED.

Why is everyone basing her/his tries of proof on non existing restrictions?

Here you claim, that the values of expressions must be known at compile time, which is clearly wrong.

The compiler needs only knowledge upon the types of the expressions to generate code for the values given at runtime.

This is true for every subexpression also.

Once the types are known the compiler is free to evaluate all parts of the expression in any order, even at random

If there is an ambiguity in the type a subexpression can have, the compiler is not forced to detect that ambiguity and report on it. The compiler is allowed to choose out of the ambiguous candidates at random.

That means that in the example given by BCS the code fragnment

  A a2= a+b+c;
  C c2= a+b+c;

may or may not result in reporting compilation errors, which in addition may change between consecutive runs.


> Any compiler that doesn't do
> this... really isn't useful at all.

For what are lists of statements useful then? Do you claim, that D doesn't  need the `;' to string statements?

-manfred

Manfred Nowak wrote:
> Chris Sauls wrote:
> [...]
>> Any expression, B, containing any operand whose value is taken
>> from the result of another expression, A, must be evaluated
>> /after/ the expression, A.  QED.
> 
> Why is everyone basing her/his tries of proof on non existing restrictions?

See my comment about postfix expressions.  I would be surprised if D were different than C++ insofar as this is concerned.


Sean

Manfred Nowak wrote:
> Chris Sauls wrote:
> [...]
> 
>>Any expression, B, containing any operand whose value is taken
>>from the result of another expression, A, must be evaluated
>>/after/ the expression, A.  QED.
> 
> 
> Why is everyone basing her/his tries of proof on non existing restrictions?
> 
> Here you claim, that the values of expressions must be known at compile time, which is clearly wrong.
> 
> The compiler needs only knowledge upon the types of the expressions to generate code for the values given at runtime.
> 
> This is true for every subexpression also.
> 
> Once the types are known the compiler is free to evaluate all parts of the expression in any order, even at random
> 
> If there is an ambiguity in the type a subexpression can have, the compiler is not forced to detect that ambiguity and report on it. The compiler is allowed to choose out of the ambiguous candidates at random.
> 
> That means that in the example given by BCS the code fragnment
> 
>   A a2= a+b+c;
>   C c2= a+b+c;
> 
> may or may not result in reporting compilation errors, which in addition may change between consecutive runs.

But how is a+b+c; simillar to a.b().c();
In no way. I agree that a+b+c can be (a+b)+c or a+(b+c)
but a.b().c() can only be (a.b()).c() and nothing else.

Manfred Nowak wrote:
> Chris Sauls wrote:
> [...]
> 
>>Any expression, B, containing any operand whose value is taken
>>from the result of another expression, A, must be evaluated
>>/after/ the expression, A.  QED.
> 
> 
> Why is everyone basing her/his tries of proof on non existing restrictions?
> 
> Here you claim, that the values of expressions must be known at compile time, which is clearly wrong.

I don't claim any such thing.  In fact I'm claiming the /opposite/, which is that the value in this case is impossible to predict perfectly at compile time, which is why the order of operations is in fact fixed.  "A" must be evaluated first, because it is an operand of "B" -- so if they are evaluated in any other order, a runtime error is inescapable, because "B" has a void operand (illegal in the mass majority of expressions).  I really, truly, just don't see how it could be any other way.

> The compiler needs only knowledge upon the types of the expressions to generate code for the values given at runtime.
> 
> This is true for every subexpression also.

Exactly.

> Once the types are known the compiler is free to evaluate all parts of the expression in any order, even at random

Sure, insofar as their later runtime evaluation is not dependant on the evaluation of any other expressions.  In order for any expression to evaluate ("execute") it must be /complete/, and in this special case we are discussing, that completeness relies on the previous execution of another expression.  Again, any compiler that doesn't enforce this, is going to generate useless code.

> If there is an ambiguity in the type a subexpression can have, the compiler is not forced to detect that ambiguity and report on it. The compiler is allowed to choose out of the ambiguous candidates at random.
> 
> That means that in the example given by BCS the code fragnment
> 
>   A a2= a+b+c;
>   C c2= a+b+c;
> 
> may or may not result in reporting compilation errors, which in addition may change between consecutive runs.

Could be.  But we're discussing the Whisper syntax in Mango.io are we not?  So let's stick to that.

-- Chris Sauls

Ivan Senji wrote:
[...]
> but a.b().c() can only be (a.b()).c() and nothing else.

Let [] denote the ordering for type deduction and {}n denote the ordering for evaluation, where {}i is evaluated before {}j if and only if i<j.

You are right, that according to type deduction `x.a().b().c()' can only be annotated by [[x.a()].b()].c() .

But according to evaluation ordering still several versions are possible

   x.{a()}1.{b()}2.{c()}3  // which seems to be the preferred one
   x.{a()}1.{b()}3.{c()}2
   x.{a()}2.{b()}1.{c()}3
   x.{a()}2.{b()}3.{c()}1
   x.{a()}3.{b()}1.{c()}2
   x.{a()}3.{b()}2.{c()}1

-manfred

Manfred Nowak wrote:
> Ivan Senji wrote:
> [...]
> 
>>but a.b().c() can only be (a.b()).c() and nothing else.
> 
> 
> Let [] denote the ordering for type deduction and {}n denote the ordering for evaluation, where {}i is evaluated before {}j if and only if i<j.
> 
> You are right, that according to type deduction `x.a().b().c()' can only be annotated by [[x.a()].b()].c() .
> 
> But according to evaluation ordering still several versions are possible
> 
>    x.{a()}1.{b()}2.{c()}3  // which seems to be the preferred one
>    x.{a()}1.{b()}3.{c()}2
>    x.{a()}2.{b()}1.{c()}3
>    x.{a()}2.{b()}3.{c()}1
>    x.{a()}3.{b()}1.{c()}2
>    x.{a()}3.{b()}2.{c()}1
> 

I am sorry but none of the other evaluation orders is possible.
For example x is of type X, a returns object of type A, b of type B and c of type C.

so we have methods:
class X{  A a();  }
class A{  B b();  }
class B{  C c();  }

or we could think of them this way:

A a(X x_this);
B b(A a_this);
C c(C c_this);

then the following is also true
x.a() === a(x);
x.a().b() === b(a(x));
x.a().b().c() === c(b(a(x)));

And there is no other possible and meaningful and reasonable order of evaluation then the above. a(x) is evaluated first, then b is called with a's result as an argument, then c is called with b's result as argument.

Chris Sauls wrote:

[...]
> the value in this case is impossible to predict perfectly at compile time, which is why the order of operations is in fact fixed.
[...]

Postfix expressions are _not_ left associative and stringed together do _not_ change precedence. Therefore the two calls in `a.b().c()' can be evaluated in any order.

This arguments start to circle around an imaginary spot in the far distance.

If any value is impossible to predict perfectly at compile time by definition that expression is illegal.

If there is an expression E consisting of at least two subexpressions A and B and the value of subexpression B depends on the value computed for subexpression A, then the chain of operators joining both subexpressions together must change precendence somewhere.

If there is no change in precedence, then because the lack of defined associativity in D the subexpressions can be evaluated in any order, regardless of any known dependencies.

Postfix expressions are _not_ left associative and stringed together do _not_ change precedence.

-manfred

Manfred Nowak wrote:
> 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?
> 
I was thinking "precedence" in the general sense, that is both precedence between different operators (precedence per se) and precedence between several instances of the same operator (associativity).
In other words:
"the grammar is built to support the same precedence and associativity semantics as C/C++"
(I think this was somewhat implicitly obvious, because why would Walter want to copy only part of the C/C++ operator evalution rules...)

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

Now hold on just a second.

Manfred Nowak wrote:
> If any value is impossible to predict perfectly at compile time by definition that expression is illegal.

But yet, in a previous post you stated:
> Here you claim, that the values of expressions must be known at
> compile time, which is clearly wrong.
>
> The compiler needs only knowledge upon the types of the expressions
> to generate code for the values given at runtime.

So which way is it?  Must values be reachable at compile time or not?  Clearly, not, just as you asserted previously, and I asserted recently.  As for postfix operators being lest-associative... it really just doesn't matter.  You are right insofar as the types being the important thing at compile time, however the types /are/ reachable in left-associative manner.  The /values/ are not, which means the order of evaluation at /runtime/ is different than the associativity, which is a /compile time/ property of expressions, not a /runtime/ one.

It doesn't make any sense any other way.

-- Chris Sauls

Ivan Senji wrote:

[...]
> x.a().b().c() === c(b(a(x)));
[...]

Am I right, that you start to proof your claim that some of the currently illegal expressions should be made legal by an example that is in fact illegal and then stating that it should be legal?

-manfred