Sean Kelly wrote:
> Bruno Medeiros wrote:
>> Sean Kelly wrote:
>>>
>>> It's an issue because it's confusing, as previous discussions can attest.  I'm still not convinced that there is sufficient reason to define an evaluation order, since most other languages don't and it doesn't seem to be a problem, but I'll admit that it would make for less confusion.
>>
>> What do you mean by "most other languages"? Have you seen my other post which mentions that not only Java, but C#, Python, and even Ruby all have well defined evaluation orders?
> 
> True.  I suppose I should have said "most other languages I've used" :-p  I'm wondering if it's fair to include languages that don't support operator overloading though, or multiple calling conventions.  Can a strong parallel be drawn between D and any of the languages you mention, insofar as this issue is concerned?
> 
> 
> Sean

C# does support operator overload. Dunno about Python and Ruby.
But I don't see how operator overloading or calling conventions would have any effect on having a completely defined expression order of evaluation. Indeed, I don't think it makes any difference.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros wrote:
> C# does support operator overload. Dunno about Python and Ruby.
> But I don't see how operator overloading or calling conventions would
> have any effect on having a completely defined expression order of
> evaluation. Indeed, I don't think it makes any difference.

Python:

>>> class FakeInt:
        def __init__(self, v):
            self.v = v
        def __add__(self, rhs):
            return FakeInt(self.v+rhs.v)
        def __str__(self):
            return str(self.v)

>>> FakeInt(2) + FakeInt(3)
5

	-- Daniel

-- 
int getRandomNumber()
{
    return 4; // chosen by fair dice roll.
              // guaranteed to be random.
}

http://xkcd.com/

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/

Manfred Nowak wrote:
> Bruno Medeiros wrote
> 
>>    Evaluate operands in the same order as the associativity rule
>>    of the    operator.
> 
> You require all operators to have an associativity? Then what is the associativity of the operators for comparison?
>  

Huh? "require all operators to have an associativity"?... Any C-based language has an associativity rule for all operators! Didn't you know that?? The associativity for comparison operators is listed here:
http://en.wikipedia.org/wiki/Operators_in_C_and_C%2B%2B
(it's the same in D)


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Op Fri, 27 Apr 2007 18:42:12 -0700
schreef Sean Kelly <sean@f4.ca>:

> Bruno Medeiros wrote:
> > Sean Kelly wrote:
> >>
> >> It's an issue because it's confusing, as previous discussions can attest.  I'm still not convinced that there is sufficient reason to define an evaluation order, since most other languages don't and it doesn't seem to be a problem, but I'll admit that it would make for less confusion.
> > 
> > What do you mean by "most other languages"? Have you seen my other post which mentions that not only Java, but C#, Python, and even Ruby all have well defined evaluation orders?
> 
> True.  I suppose I should have said "most other languages I've used" :-p I'm wondering if it's fair to include languages that don't support operator overloading though, or multiple calling conventions.

Python supports operator overloading and "multiple calling conventions"?  ;-)


-- 
JanC

Bruno Medeiros wrote

> (it's the same in D)
| Comparison operators are no longer associative
changelog for D 1.007

Sadly you seem unwilling to state your capabilities with respect to identifying assignment subsequences wich can be specifically attributed.

-manfred

Jan Claeys wrote:
> Op Fri, 27 Apr 2007 18:42:12 -0700
> schreef Sean Kelly <sean@f4.ca>:
> 
>> Bruno Medeiros wrote:
>>> Sean Kelly wrote:
>>>> It's an issue because it's confusing, as previous discussions can attest.  I'm still not convinced that there is sufficient reason
>>>> to define an evaluation order, since most other languages don't
>>>> and it doesn't seem to be a problem, but I'll admit that it would
>>>> make for less confusion.
>>> What do you mean by "most other languages"? Have you seen my other
>>> post which mentions that not only Java, but C#, Python, and even
>>> Ruby all have well defined evaluation orders?
>> True.  I suppose I should have said "most other languages I've
>> used" :-p I'm wondering if it's fair to include languages that don't
>> support operator overloading though, or multiple calling
>> conventions. 
> 
> Python supports operator overloading and "multiple calling
> conventions"?  ;-)

Ah well :-)  I suppose I'm just worried we'd be trading away a potential for optimization for support of a coding strategy that no one should be using anyway.


Sean

Manfred Nowak wrote:
> Bruno Medeiros wrote
> 
>> (it's the same in D) 
> | Comparison operators are no longer associative
> changelog for D 1.007
> 

Hum, you're right, I forgot about that, sorry.

So, going back to your original question:


Manfred Nowak wrote:
> Bruno Medeiros wrote
>
>>    Evaluate operands in the same order as the associativity rule
>>    of the
>>    operator.
>
> You require all operators to have an associativity? Then what is the
> associativity of the operators for comparison?
>

Ok, I understand the question. Very well, let's use a different learning rule:

  All operands are evaluated left to right, with the exception of the assignment operators which are evaluated right-to-left.

I think it is even easier to learn than the previous one. Any problem with this one?


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros wrote
> All operands are evaluated left to right, with the exception of the assignment operators which are evaluated right-to-left.
[...]
> Any problem with this one?

Don't you see a reason why Walter has tossed himself out of this thread?

Given an expression `a op b'
|  The expression is rewritten as both:
|    a.opfunc(b)
|    b.opfunc_r(a)

This is from the specs! Now what is the evaluation order of `a op b'?
`a' then `b'?
`b' then `a'?

If there is a cloud some people only see the silver lining.

-manfred

Manfred Nowak wrote:
> If there is a cloud some people only see the silver lining.

That's a great phrase! I'm stealing it for my own purposes :-) Thanks!

--benji

Manfred Nowak wrote:
> Bruno Medeiros wrote
>> All operands are evaluated left to right, with the exception of
>> the assignment operators which are evaluated right-to-left.
> [...]
>> Any problem with this one?
> 
> Don't you see a reason why Walter has tossed himself out of this
> thread?
> 
> Given an expression `a op b'
> |  The expression is rewritten as both:
> |    a.opfunc(b)
> |    b.opfunc_r(a)
> 
> This is from the specs! Now what is the evaluation order of `a op b'?
> `a' then `b'?
> `b' then `a'?
> 
> If there is a cloud some people only see the silver lining.
> 
> -manfred 

Hum, good point. This looks like an unprecedented case, I don't know if any other languages have reverse operator overloading like D. In any case a design decision would have to be made (thus creating a new evaluation rule).
I would say that the order should be 'a' then 'b', because this way the programmer doesn't have to check which operator function is being invoked to know the evaluation order of such expression. This makes the code less dependent, which is particularly important since the underlying operator function could change in time, (from a non-reverse, to a reverse one, for example), and it would be best to maintain the original order semantics.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D