D - Reverse Operator Overloading
- "Walter" <walter digitalmars.com> Aug 16 2002
- Burton Radons <loth users.sourceforge.net> Aug 16 2002
- "Jason Mills" <jmills cs.mun.ca> Aug 17 2002
- "Walter" <walter digitalmars.com> Aug 17 2002
- "anderson" <anderson firestar.com.au> Aug 17 2002
- "Walter" <walter digitalmars.com> Aug 17 2002
- "anderson" <anderson firestar.com.au> Aug 18 2002
- "Sean L. Palmer" <seanpalmer earthlink.net> Aug 18 2002
- Pavel Minayev <evilone omen.ru> Aug 17 2002
- "Walter" <walter digitalmars.com> Aug 17 2002
- "anderson" <anderson firestar.com.au> Aug 17 2002
- "anderson" <anderson firestar.com.au> Aug 17 2002
- "Walter" <walter digitalmars.com> Aug 17 2002
- "anderson" <anderson firestar.com.au> Aug 17 2002
- "anderson" <anderson firestar.com.au> Aug 17 2002
- "anderson" <anderson firestar.com.au> Aug 17 2002
- "Sean L. Palmer" <seanpalmer earthlink.net> Aug 18 2002
- "Walter" <walter digitalmars.com> Aug 18 2002
- Pavel Minayev <evilone omen.ru> Aug 18 2002
- "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> Aug 18 2002
- "Walter" <walter digitalmars.com> Aug 18 2002
- "Sean L. Palmer" <seanpalmer earthlink.net> Aug 18 2002
- "Walter" <walter digitalmars.com> Aug 19 2002
- "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> Aug 20 2002
- Pavel Minayev <evilone omen.ru> Aug 20 2002
- "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> Aug 20 2002
- "Richard Krehbiel" <rich kastle.com> Aug 20 2002
- "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> Aug 20 2002
- "Richard Krehbiel" <rich kastle.com> Aug 21 2002
- Pavel Minayev <evilone omen.ru> Aug 20 2002
- "Sean L. Palmer" <seanpalmer earthlink.net> Aug 20 2002
- "anderson" <anderson firestar.com.au> Aug 19 2002
- Russ Lewis <spamhole-2001-07-16 deming-os.org> Aug 19 2002
- "Walter" <walter digitalmars.com> Aug 19 2002
- Russ Lewis <spamhole-2001-07-16 deming-os.org> Aug 19 2002
- "Walter" <walter digitalmars.com> Aug 19 2002
- "anderson" <anderson firestar.com.au> Aug 19 2002
- Russell Lewis <spamhole-2001-07-16 deming-os.org> Aug 20 2002
- "Walter" <walter digitalmars.com> Aug 20 2002
- Burton Radons <loth users.sourceforge.net> Aug 20 2002
- "Walter" <walter digitalmars.com> Aug 20 2002
- Patrick Down <pat codemoon.com> Aug 17 2002
- "Walter" <walter digitalmars.com> Aug 18 2002
- "anderson" <anderson firestar.com.au> Aug 19 2002
- "anderson" <anderson firestar.com.au> Aug 19 2002
- "anderson" <anderson firestar.com.au> Aug 19 2002
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
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
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
"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
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
"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
"anderson" <anderson firestar.com.au> "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
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
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
"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
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
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
"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
"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
1or 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
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
1or 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
"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
1or 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
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
"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
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
"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
"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
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
"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
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
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
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
"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
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
"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
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
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
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
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
"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
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
"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
"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
functionsyntax 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
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
functionsyntax 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 ifthere WERE distinguishing characters? Any thoughts on what those
characterscould 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
"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
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
"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
"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
"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
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
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
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