www.digitalmars.com         C & C++   DMDScript  

D - Reverse Operator Overloading

reply "Walter" <walter digitalmars.com> writes:
I'm looking at the overloading of commutative operators add, multiply, etc.
There are a couple of options for dealing with the (1 + a) case:

1) Provide a separate "add_r" function to make a.add_r(1)
2) Allow the compiler to swap the operands and call a.add(1)
3) Allow the compiler to swap the operands unless there is an "add_r"
function defined.

I'm leaning towards (2), it is simpler and in keeping with the way the
builtin operators work. Note that this would only apply to those operators
that are mathematically commutative. It does not allow associative
rearrangement, and does not allow replacing (a - b) with (a + (-b)), etc.
Aug 16 2002
next sibling parent reply Burton Radons <loth users.sourceforge.net> writes:
Walter wrote:

 I'm looking at the overloading of commutative operators add, multiply, etc.
 There are a couple of options for dealing with the (1 + a) case:
 
 1) Provide a separate "add_r" function to make a.add_r(1)
 2) Allow the compiler to swap the operands and call a.add(1)
 3) Allow the compiler to swap the operands unless there is an "add_r"
 function defined.
 
 I'm leaning towards (2), it is simpler and in keeping with the way the
 builtin operators work. Note that this would only apply to those operators
 that are mathematically commutative. It does not allow associative
 rearrangement, and does not allow replacing (a - b) with (a + (-b)), etc.

It's not really worth the gain when you can write out a basic reverse with one line: Vector operator (extended a) + (Vector b) { return b + a; } Vector operator (extended a) - (Vector b) { return -b + a; } Vector operator (extended a) * (Vector b) { return b * a; } IMO it's clearer to have every permutation written out and doesn't interfere with getting anything done. It's not worth the special case effort for the two operators which can sometimes sorta be automatically reversed.
Aug 16 2002
parent reply "Jason Mills" <jmills cs.mun.ca> writes:
Walter wrote:
 
 I'm looking at the overloading of commutative operators add, multiply, etc.
 There are a couple of options for dealing with the (1 + a) case:

 1) Provide a separate "add_r" function to make a.add_r(1)
 2) Allow the compiler to swap the operands and call a.add(1)
 3) Allow the compiler to swap the operands unless there is an "add_r"
 function defined.

and then Burton Radons wrote:
 It's not really worth the gain when you can write out a basic reverse
 with one line:

 Vector operator (extended a) + (Vector b) { return b + a; }
 Vector operator (extended a) - (Vector b) { return -b + a; }
 Vector operator (extended a) * (Vector b) { return b * a; }

In earlier postings there was some discussion as to what syntax operator overloading should have. It seems from above that a solution as not been reached: Vector operator (extended a) + (Vector b); Vector add(a); What are the results of the "Operator Overloading Vote" posting? Is operator overloading syntax still open for votes? Have any decisions been made regarding the syntax? It would be terrible if different implementations of D implemented operator overloading differently. Jason
Aug 17 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Jason Mills" <jmills cs.mun.ca> wrote in message
news:20020817.135143.339834416.5441 localhost.localdomain...
 It would be terrible if different implementations of D implemented

 overloading differently.

I've got it mostly implemented now, stay tuned! Of course, with all the conflicting ideas on it, it's a sure thing that not everyone will be pleased, but I think what I've got will address what operator overloading is needed for in a simple, easy-to-understand manner.
Aug 17 2002
next sibling parent reply "anderson" <anderson firestar.com.au> writes:
I'm sure what ever you come up with will be brilliant. Operator Overloading
is i no better hands.

"Walter" <walter digitalmars.com> wrote in message
news:ajlssa$1qds$1 digitaldaemon.com...
 "Jason Mills" <jmills cs.mun.ca> wrote in message
 news:20020817.135143.339834416.5441 localhost.localdomain...
 It would be terrible if different implementations of D implemented

 overloading differently.

I've got it mostly implemented now, stay tuned! Of course, with all the conflicting ideas on it, it's a sure thing that not everyone will be pleased, but I think what I've got will address what operator overloading

 needed for in a simple, easy-to-understand manner.

Aug 17 2002
parent reply "Walter" <walter digitalmars.com> writes:
"anderson" <anderson firestar.com.au> wrote in message
news:ajn6ar$12j$1 digitaldaemon.com...
 I'm sure what ever you come up with will be brilliant. Operator

 is i no better hands.

Thanks for the vote of confidence. I want the result to wind up being so obvious that people will think "of course, there's no magic there, I could have done that myself!" The hardest engineering thing in the world to do is come up with something simple and obvious. It's all too easy to come up with something complicated :-(
Aug 17 2002
parent "anderson" <anderson firestar.com.au> writes:
"Walter" <walter digitalmars.com> wrote in message
news:ajncr4$7n2$2 digitaldaemon.com...
 "anderson" <anderson firestar.com.au> wrote in message
 news:ajn6ar$12j$1 digitaldaemon.com...
 I'm sure what ever you come up with will be brilliant. Operator

 is i no better hands.

Thanks for the vote of confidence. I want the result to wind up being so obvious that people will think "of course, there's no magic there, I could have done that myself!" The hardest engineering thing in the world to do

 come up with something simple and obvious.

 It's all too easy to come up with something complicated :-(

Yes, brilliance doesn't mean things need to be complicated. Brilliance often makes things easier for others.
Aug 18 2002
prev sibling parent "Sean L. Palmer" <seanpalmer earthlink.net> writes:
The language is still alpha anyway so now is the perfect time to experiment
with different syntaxes.  And I'm sure once we begin to use it, any flaws
will present themselves promptly.

Please nobody start using operator overloading yet unless you're willing to
throw the code away and start over once the final syntax is established.

It seems Burton is going in a good direction so far.  I'm just surprised
Walter is on board with it.  ;)   I'm glad all those huge threads weren't in
vain.

Sean

"Walter" <walter digitalmars.com> wrote in message
news:ajlssa$1qds$1 digitaldaemon.com...
 "Jason Mills" <jmills cs.mun.ca> wrote in message
 news:20020817.135143.339834416.5441 localhost.localdomain...
 It would be terrible if different implementations of D implemented

 overloading differently.

I've got it mostly implemented now, stay tuned! Of course, with all the conflicting ideas on it, it's a sure thing that not everyone will be pleased, but I think what I've got will address what operator overloading

 needed for in a simple, easy-to-understand manner.

Aug 18 2002
prev sibling next sibling parent reply Pavel Minayev <evilone omen.ru> writes:
On Fri, 16 Aug 2002 17:54:54 -0700 "Walter" <walter digitalmars.com> wrote:

 I'm leaning towards (2), it is simpler and in keeping with the way the
 builtin operators work. Note that this would only apply to those operators
 that are mathematically commutative. It does not allow associative
 rearrangement, and does not allow replacing (a - b) with (a + (-b)), etc.

And are there any operators that are _always_ commutative? I might be wrong, but I remember some kind of numbers in math for which + is not commutative... IMHO it's better to define operators separately for every case.
Aug 17 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:CFN374854774504051 news.digitalmars.com...
 And are there any operators that are _always_ commutative? I might be

 but I remember some kind of numbers in math for which + is not

I can't think of any.
 IMHO it's better to define operators separately for every case.

Aug 17 2002
parent "anderson" <anderson firestar.com.au> writes:
I agree with Pavel here, it should be standard across all operators. That
way there's no confusion.

"Walter" <walter digitalmars.com> wrote in message
news:ajl03j$hj4$1 digitaldaemon.com...
 "Pavel Minayev" <evilone omen.ru> wrote in message
 news:CFN374854774504051 news.digitalmars.com...
 And are there any operators that are _always_ commutative? I might be

 but I remember some kind of numbers in math for which + is not

I can't think of any.
 IMHO it's better to define operators separately for every case.


Aug 17 2002
prev sibling next sibling parent reply "anderson" <anderson firestar.com.au> writes:
A major point for using overloaded operators is for matrix/vector type
operations which contain things which are not commutative. I'd say either 1
or 3. Or 1 and 2 (providing a both operation).


"Walter" <walter digitalmars.com> wrote in message
news:ajk6mq$2o08$1 digitaldaemon.com...
 I'm looking at the overloading of commutative operators add, multiply,

 There are a couple of options for dealing with the (1 + a) case:

 1) Provide a separate "add_r" function to make a.add_r(1)
 2) Allow the compiler to swap the operands and call a.add(1)
 3) Allow the compiler to swap the operands unless there is an "add_r"
 function defined.

 I'm leaning towards (2), it is simpler and in keeping with the way the
 builtin operators work. Note that this would only apply to those operators
 that are mathematically commutative. It does not allow associative
 rearrangement, and does not allow replacing (a - b) with (a + (-b)), etc.

Aug 17 2002
parent reply "Walter" <walter digitalmars.com> writes:
"anderson" <anderson firestar.com.au> wrote in message
news:ajkvq6$h3d$1 digitaldaemon.com...
 A major point for using overloaded operators is for matrix/vector type
 operations which contain things which are not commutative. I'd say either

 or 3. Or 1 and 2 (providing a both operation).

The only time the commutativity is an issue is when the left operand is not a class object, i.e. is a scalar or array. Isn't matrix math commutative when adding/multiplying by a constant?
Aug 17 2002
next sibling parent "anderson" <anderson firestar.com.au> writes:
"Walter" <walter digitalmars.com> wrote in message
news:ajl2ei$106c$1 digitaldaemon.com...
 "anderson" <anderson firestar.com.au> wrote in message
 news:ajkvq6$h3d$1 digitaldaemon.com...
 A major point for using overloaded operators is for matrix/vector type
 operations which contain things which are not commutative. I'd say


 1
 or 3. Or 1 and 2 (providing a both operation).

The only time the commutativity is an issue is when the left operand is

 a class object, i.e. is a scalar or array. Isn't matrix math commutative
 when adding/multiplying by a constant?

Your right. I suppose if there are any cases for non commutative you could define an integer as a class and get around it that way.
Aug 17 2002
prev sibling parent reply "anderson" <anderson firestar.com.au> writes:
Come to think of it....

How will...

Matrix ** Integer

be handled?


"Walter" <walter digitalmars.com> wrote in message
news:ajl2ei$106c$1 digitaldaemon.com...
 "anderson" <anderson firestar.com.au> wrote in message
 news:ajkvq6$h3d$1 digitaldaemon.com...
 A major point for using overloaded operators is for matrix/vector type
 operations which contain things which are not commutative. I'd say


 1
 or 3. Or 1 and 2 (providing a both operation).

The only time the commutativity is an issue is when the left operand is

 a class object, i.e. is a scalar or array. Isn't matrix math commutative
 when adding/multiplying by a constant?

Aug 17 2002
next sibling parent "anderson" <anderson firestar.com.au> writes:
"anderson" <anderson firestar.com.au> wrote in message
news:ajl71t$14of$1 digitaldaemon.com...
 Come to think of it....

 How will...

 Matrix ** Integer

 be handled?


 "Walter" <walter digitalmars.com> wrote in message
 news:ajl2ei$106c$1 digitaldaemon.com...
 "anderson" <anderson firestar.com.au> wrote in message
 news:ajkvq6$h3d$1 digitaldaemon.com...
 A major point for using overloaded operators is for matrix/vector type
 operations which contain things which are not commutative. I'd say


 1
 or 3. Or 1 and 2 (providing a both operation).

The only time the commutativity is an issue is when the left operand is

 a class object, i.e. is a scalar or array. Isn't matrix math commutative
 when adding/multiplying by a constant?


Aug 17 2002
prev sibling parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
Speaking of **, are there any plans for D to support exponentiation?  It's
such a basic math function...

Neither ** nor ^ are good choices for operator since ^ already means xor and
a ** b can be mistaken for a * (*b).

I guess there's always pow()...

Sean

"anderson" <anderson firestar.com.au> wrote in message
news:ajl71t$14of$1 digitaldaemon.com...
 Come to think of it....

 How will...

 Matrix ** Integer

 be handled?

Aug 18 2002
next sibling parent "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:ajnom1$kfq$1 digitaldaemon.com...
 Speaking of **, are there any plans for D to support exponentiation?  It's
 such a basic math function...

 Neither ** nor ^ are good choices for operator since ^ already means xor

 a ** b can be mistaken for a * (*b).

 I guess there's always pow()...

I've always been partial to FORTRAN's exponentiation operator, but it doesn't fit in well with all the other operators C/C++/D has. pow() is ugly, but it does work.
Aug 18 2002
prev sibling next sibling parent reply Pavel Minayev <evilone omen.ru> writes:
On Sun, 18 Aug 2002 02:25:01 -0700 "Sean L. Palmer" <seanpalmer earthlink.net> 
wrote:

 Speaking of **, are there any plans for D to support exponentiation?  It's
 such a basic math function...
 
 Neither ** nor ^ are good choices for operator since ^ already means xor and
 a ** b can be mistaken for a * (*b).
 
 I guess there's always pow()...

Hm... Maybe a^^b?
Aug 18 2002
parent reply "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:CFN374868462475694 news.digitalmars.com...
 I guess there's always pow()...


It looks like a logical xor to me. Regards, Martin M. Pedersen
Aug 18 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Martin M. Pedersen" <mmp www.moeller-pedersen.dk> wrote in message
news:ajp79j$236i$1 digitaldaemon.com...
 "Pavel Minayev" <evilone omen.ru> wrote in message
 news:CFN374868462475694 news.digitalmars.com...
 I guess there's always pow()...



It's been proposed as a logical xor for C many times.
Aug 18 2002
next sibling parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
The != operator functions pretty well as a logical xor.

Sean

"Walter" <walter digitalmars.com> wrote in message
news:ajpa1n$268h$1 digitaldaemon.com...
 "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> wrote in message
 news:ajp79j$236i$1 digitaldaemon.com...
 "Pavel Minayev" <evilone omen.ru> wrote in message
 news:CFN374868462475694 news.digitalmars.com...
 I guess there's always pow()...



It's been proposed as a logical xor for C many times.

Aug 18 2002
parent "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:ajpvap$2ri4$1 digitaldaemon.com...
 The != operator functions pretty well as a logical xor.

Yes, the counter was ^^ added insufficient utility to make it worthwhile.
Aug 19 2002
prev sibling parent reply "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> writes:
Hi,

"Walter" <walter digitalmars.com> wrote in message
news:ajpa1n$268h$1 digitaldaemon.com...
 Hm... Maybe a^^b?



I often wondered why it wasn't there, as it would make the set of operators more consistent. It seems that I'm not the only one. The same could be said about &&= and ||=. However, I can't say I have missed them much, and the set of operators in D is already large enough. So consider this a comment, not a proposal for D. Keep up the good work. Regards, Martin
Aug 20 2002
next sibling parent reply Pavel Minayev <evilone omen.ru> writes:
On Tue, 20 Aug 2002 17:22:22 +0100 "Martin M. Pedersen" 
<mmp www.moeller-pedersen.dk> wrote:

 I often wondered why it wasn't there, as it would make the set of operators
 more consistent. It seems that I'm not the only one. The same could be said

Logical xor is operator !=
 about &&= and ||=. However, I can't say I have missed them much, and the set

These, I think they could be added. We have &= and |=, then why not &&= and ||= ?
Aug 20 2002
parent reply "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> writes:
Hi,

"Pavel Minayev" <evilone omen.ru> wrote in message
news:CFN374888137990278 news.digitalmars.com...
 Logical xor is operator !=

Not exactly, as 2!=1 yields true. != is only a logical xor if the operands are guaranteed to be either 0 or 1. Regards, Martin M. Pedersen
Aug 20 2002
parent reply "Richard Krehbiel" <rich kastle.com> writes:
"Martin M. Pedersen" <mmp www.moeller-pedersen.dk> wrote in message
news:ajtnne$1a2r$1 digitaldaemon.com...
 Hi,

 "Pavel Minayev" <evilone omen.ru> wrote in message
 news:CFN374888137990278 news.digitalmars.com...
 Logical xor is operator !=

Not exactly, as 2!=1 yields true. != is only a logical xor if the operands are guaranteed to be either 0 or 1.

So, instead use !a != !b. Still not inconvenient. The benefit from the logical operators && and || is their short-circuit behavior (sometimes only the left hand side need be evaluated). Except for that, there's scarcely any reason to have them. Considering this, why have a logical xor, since it's not short-circuit-able (both sides must always be evaluated)? It's similarly hard to justify the &&= and ||= operators.
Aug 20 2002
next sibling parent reply "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> writes:
Hi,

"Richard Krehbiel" <rich kastle.com> wrote in message
news:ajtqvv$1daq$1 digitaldaemon.com...
 Not exactly, as 2!=1 yields true. != is only a logical xor if the


 are guaranteed to be either 0 or 1.


Maybe not. But a bit inconsistent, I think. No big issue, though.
 The benefit from the logical operators && and || is their short-circuit
 behavior (sometimes only the left hand side need be evaluated).

Good point.
 Considering this, why have
 a logical xor, since it's not short-circuit-able (both sides must always

 evaluated)?  It's similarly hard to justify the &&= and ||= operators.

I would expect them to short-circuit too. Regards, Martin M. Pedersen
Aug 20 2002
parent "Richard Krehbiel" <rich kastle.com> writes:
"Martin M. Pedersen" <mmp www.moeller-pedersen.dk> wrote in message
news:ajtv3s$1i83$1 digitaldaemon.com...
 Hi,

 "Richard Krehbiel" <rich kastle.com> wrote in message
 news:ajtqvv$1daq$1 digitaldaemon.com...
 The benefit from the logical operators && and || is their short-circuit
 behavior (sometimes only the left hand side need be evaluated).

Good point.
 Considering this, why have
 a logical xor, since it's not short-circuit-able (both sides must always

 evaluated)?  It's similarly hard to justify the &&= and ||= operators.

I would expect them to short-circuit too.

You know, I didn't think about that hard enough. &&= and ||= could indeed short-circuit, they could be defined not to evaluate the left side if the right side is zero/non-zero, which can be a big win if it's something like "DBlookup()->array[VMthrasher()] ||= var;". But of course, today you'd code it as "if(var) DBlookup()->array[VMthrasher()] |= 1;". Still not such a big deal, I think. -- Richard Krehbiel, Arlington, VA, USA rich kastle.com (work) or krehbiel3 comcast.net (personal)
Aug 21 2002
prev sibling parent Pavel Minayev <evilone omen.ru> writes:
On Tue, 20 Aug 2002 12:38:35 -0400 "Richard Krehbiel" <rich kastle.com> wrote:

 evaluated)?  It's similarly hard to justify the &&= and ||= operators.

This can be used to break long boolean expression into several short ones, like it is sometimes done with arithmetic.
Aug 20 2002
prev sibling parent "Sean L. Palmer" <seanpalmer earthlink.net> writes:
I actually do find myself wanting &&= and ||= quite a lot.

bool succeeded = true;
succeeded &&= TrySomething();
succeeded &&= TrySomethingElse();
if (!succeeded)
    printf("Either TrySomething or TrySomethingElse failed\n");

Sean

"Martin M. Pedersen" <mmp www.moeller-pedersen.dk> wrote in message
news:ajtmff$18nu$1 digitaldaemon.com...
 Hi,

 "Walter" <walter digitalmars.com> wrote in message
 news:ajpa1n$268h$1 digitaldaemon.com...
 Hm... Maybe a^^b?



I often wondered why it wasn't there, as it would make the set of

 more consistent. It seems that I'm not the only one. The same could be

 about &&= and ||=. However, I can't say I have missed them much, and the

 of operators in D is already large enough. So consider this a comment, not

 proposal for D. Keep up the good work.

 Regards,
 Martin

Aug 20 2002
prev sibling next sibling parent "anderson" <anderson firestar.com.au> writes:
How about,

*^

_*

_^

^_

(^)

Although I hate keyboard switching, I suppose powers arn't used that much
(but when they are there useful).

"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:ajnom1$kfq$1 digitaldaemon.com...
 Speaking of **, are there any plans for D to support exponentiation?  It's
 such a basic math function...

 Neither ** nor ^ are good choices for operator since ^ already means xor

 a ** b can be mistaken for a * (*b).

 I guess there's always pow()...

 Sean

 "anderson" <anderson firestar.com.au> wrote in message
 news:ajl71t$14of$1 digitaldaemon.com...
 Come to think of it....

 How will...

 Matrix ** Integer

 be handled?


Aug 19 2002
prev sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
There's no reason we couldn't use text operators.  Remember the inline function
syntax we played with a while back?

    MyObj a;    OtherObj b;
    a exp b;    // implemented by MyObj.exp(OtherObj) ???

"Sean L. Palmer" wrote:

 Speaking of **, are there any plans for D to support exponentiation?  It's
 such a basic math function...

 Neither ** nor ^ are good choices for operator since ^ already means xor and
 a ** b can be mistaken for a * (*b).

 I guess there's always pow()...

 Sean

 "anderson" <anderson firestar.com.au> wrote in message
 news:ajl71t$14of$1 digitaldaemon.com...
 Come to think of it....

 How will...

 Matrix ** Integer

 be handled?


-- The Villagers are Online! villagersonline.com .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ] .[ (a version.of(English).(precise.more)) is(possible) ] ?[ you want.to(help(develop(it))) ]
Aug 19 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3D611057.D1573627 deming-os.org...
 There's no reason we couldn't use text operators.  Remember the inline

 syntax we played with a while back?

     MyObj a;    OtherObj b;
     a exp b;    // implemented by MyObj.exp(OtherObj) ???

Inline text operators, without any distinguishing special characters, would be a **** to parse. For example, this sentence would be valid D syntax.
Aug 19 2002
next sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Walter wrote:

 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3D611057.D1573627 deming-os.org...
 There's no reason we couldn't use text operators.  Remember the inline

 syntax we played with a while back?

     MyObj a;    OtherObj b;
     a exp b;    // implemented by MyObj.exp(OtherObj) ???

Inline text operators, without any distinguishing special characters, would be a **** to parse. For example, this sentence would be valid D syntax.

I keep forgetting that. Sorry. Any thoughts on if it would be a good idea if there WERE distinguishing characters? Any thoughts on what those characters could be? -- The Villagers are Online! villagersonline.com .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ] .[ (a version.of(English).(precise.more)) is(possible) ] ?[ you want.to(help(develop(it))) ]
Aug 19 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3D611A88.5EDF83A4 deming-os.org...
 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3D611057.D1573627 deming-os.org...
 There's no reason we couldn't use text operators.  Remember the inline

 syntax we played with a while back?

     MyObj a;    OtherObj b;
     a exp b;    // implemented by MyObj.exp(OtherObj) ???

Inline text operators, without any distinguishing special characters,


 be a **** to parse. For example, this sentence would be valid D syntax.


 there WERE distinguishing characters?  Any thoughts on what those

 could be?

It would be workable if there were distinguishing characters, like perhaps bracketing the identifier with :, as in a :exp: b. The next problem is what is the operator precedence.
Aug 19 2002
next sibling parent "anderson" <anderson firestar.com.au> writes:
"Walter" <walter digitalmars.com> wrote in message
news:ajruie$2edb$2 digitaldaemon.com...
 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3D611A88.5EDF83A4 deming-os.org...
 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3D611057.D1573627 deming-os.org...
 There's no reason we couldn't use text operators.  Remember the




 function
 syntax we played with a while back?

     MyObj a;    OtherObj b;
     a exp b;    // implemented by MyObj.exp(OtherObj) ???

Inline text operators, without any distinguishing special characters,


 be a **** to parse. For example, this sentence would be valid D



 I keep forgetting that.  Sorry.  Any thoughts on if it would be a good

 there WERE distinguishing characters?  Any thoughts on what those

 could be?

It would be workable if there were distinguishing characters, like perhaps bracketing the identifier with :, as in a :exp: b. The next problem is what is the operator precedence.

Parhaps a number could be kept with the function definition. int exp:4(int a, int b); //precedence level 4 ...or as someone alreay suggested, give them all the same precedence. That level could be at the highest level just below brackets. I say that because, most often a :func: will be a high order function.
Aug 19 2002
prev sibling parent reply Russell Lewis <spamhole-2001-07-16 deming-os.org> writes:
Walter wrote:
 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3D611A88.5EDF83A4 deming-os.org...
 
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3D611057.D1573627 deming-os.org...

There's no reason we couldn't use text operators.  Remember the inline

function
syntax we played with a while back?

    MyObj a;    OtherObj b;
    a exp b;    // implemented by MyObj.exp(OtherObj) ???

Inline text operators, without any distinguishing special characters,


be a **** to parse. For example, this sentence would be valid D syntax.

I keep forgetting that. Sorry. Any thoughts on if it would be a good

idea if
there WERE distinguishing characters?  Any thoughts on what those

characters
could be?

It would be workable if there were distinguishing characters, like perhaps bracketing the identifier with :, as in a :exp: b. The next problem is what is the operator precedence.

IMHO, it should be the same as function calls. In fact, we really have a function call - it's just inline syntax because that is more readable for mathematical expressions.
Aug 20 2002
parent "Walter" <walter digitalmars.com> writes:
"Russell Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3D6264F5.60704 deming-os.org...
 as in a :exp: b. The next problem is what is the operator precedence.

a function call - it's just inline syntax because that is more readable for mathematical expressions.

Your rationale makes perfect sense.
Aug 20 2002
prev sibling parent reply Burton Radons <loth users.sourceforge.net> writes:
Walter wrote:

 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3D611057.D1573627 deming-os.org...
 
There's no reason we couldn't use text operators.  Remember the inline

syntax we played with a while back?

    MyObj a;    OtherObj b;
    a exp b;    // implemented by MyObj.exp(OtherObj) ???

Inline text operators, without any distinguishing special characters, would be a **** to parse. For example, this sentence would be valid D syntax.

Not really. In the first pass, you consume statements and declarations but keep function bodies and initialisers as strings of tokens; parse the context, then create the syntax trees for the stuff that was deferred. The utility is a whole other matter. I consider "a.exp (b)" superior to "(a exp b)" because: a) It's explicit about who's doing what to whom. Operator precedence is a non-issue. b) It doesn't keep exp from being used in various contexts. c) It's the same number of characters. d) The (a exp b) syntax doesn't offer anything new. e) Making expressions look closer to mathematical drawings is an IDE issue, not a lingual responsibility, and they're facilitated in this by keeping things simple and as method-based as possible.
Aug 20 2002
parent "Walter" <walter digitalmars.com> writes:
"Burton Radons" <loth users.sourceforge.net> wrote in message
news:3D61F29C.7090600 users.sourceforge.net...
 The utility is a whole other matter.  I consider "a.exp (b)" superior to
 "(a exp b)" because:

 a) It's explicit about who's doing what to whom.  Operator precedence is
 a non-issue.

 b) It doesn't keep exp from being used in various contexts.

 c) It's the same number of characters.

 d) The (a exp b) syntax doesn't offer anything new.

 e) Making expressions look closer to mathematical drawings is an IDE
 issue, not a lingual responsibility, and they're facilitated in this by
 keeping things simple and as method-based as possible.

I agree with your reasoning. I don't think (a exp b) offers enough additional utility to make it worthwhile.
Aug 20 2002
prev sibling next sibling parent reply Patrick Down <pat codemoon.com> writes:
"Walter" <walter digitalmars.com> wrote in
news:ajk6mq$2o08$1 digitaldaemon.com: 

 I'm looking at the overloading of commutative operators add, multiply,
 etc. There are a couple of options for dealing with the (1 + a) case:
 
 1) Provide a separate "add_r" function to make a.add_r(1)
 2) Allow the compiler to swap the operands and call a.add(1)
 3) Allow the compiler to swap the operands unless there is an "add_r"
 function defined.
 
 I'm leaning towards (2), it is simpler and in keeping with the way the
 builtin operators work. Note that this would only apply to those
 operators that are mathematically commutative. It does not allow
 associative rearrangement, and does not allow replacing (a - b) with
 (a + (-b)), etc. 
 
 

Number 2 works in a lot of cases. 1. It's true that for at least the math systems I use operations with basic types (int,float) are commutative. However I'm not a mathmation so I don't know if this is universally true. 2. The author of some math libary can make sure that all the types that are not commutative have left associative operators. i.e class A { A mul(B b) { } } class B ( B mul(A a) { } } The problem comes when some other programmer now wants to extend the math libary with type C. With the the reverse operators he can get it to work. class C { C mul(A a) { } A mul_r(C c) { } } So I'm inclined to vote for option #3.
Aug 17 2002
next sibling parent "Walter" <walter digitalmars.com> writes:
"Patrick Down" <pat codemoon.com> wrote in message
news:Xns926D747D2D455patcodemooncom 63.105.9.61...
 2. The author of some math libary can make sure that
 all the types that are not commutative have left
 associative operators.  i.e

 class A { A mul(B b) { } }
 class B ( B mul(A a) { } }

 The problem comes when some other programmer now wants to
 extend the math libary with type C.  With the the reverse
 operators he can get it to work.

 class C
 {
   C mul(A a) { }
   A mul_r(C c) { }
 }

 So I'm inclined to vote for option #3.

You make a very good point. I'll leave the door open for #3 in case it does become necessary.
Aug 18 2002
prev sibling parent "anderson" <anderson firestar.com.au> writes:
Parhaps another idea that could easily be implemented later, would be the
ability to add overloaded operators to the data types themselves.

ie.

//File B.d
extend int //You can extend int as many time as you want and should be kept
in it's related module.
{
    int add(B b) { }
}

class B
{
    B add(int X) { }
    B add(B X) { }
}

//File Main.d
import B

...
B b

b = X + b + X

...


Also arrays...

//File B.d
extend int[]
{
    int[] add(B b) { }
}
...

One disadvantage of swizzled operator overloading is that it's always bound
to be less optimal then a direct method. However as I said, it's not
imperative at the moment.
Aug 19 2002
prev sibling parent reply "anderson" <anderson firestar.com.au> writes:
How will division work?

For example will:

FLOAT / MATRIX
Use the division overload?

MATRIX / FLOAT
Use the multiplication overloader by rearrangement?

Rearranged to:
(1/FLOAT) * MATRIX


Otherwise I sense there would be problems.
Aug 19 2002
parent "anderson" <anderson firestar.com.au> writes:
IC now

http://www.digitalmars.com/d/operatoroverloading.html

"anderson" <anderson firestar.com.au> wrote in message
news:ajqfbu$cin$1 digitaldaemon.com...
 How will division work?

 For example will:

 FLOAT / MATRIX
 Use the division overload?

 MATRIX / FLOAT
 Use the multiplication overloader by rearrangement?

 Rearranged to:
 (1/FLOAT) * MATRIX


 Otherwise I sense there would be problems.

Aug 19 2002