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


operator

 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


 operator

 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
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


Overloading

 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


 Overloading

 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 :-(



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


 operator

 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 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


wrong,

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


commutative...

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


 wrong,

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


 commutative...

 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,


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 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


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 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




either

 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


not

 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




either

 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


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:
"anderson" <anderson firestar.com.au> wrote in message
news:ajl71t$14of$1 digitaldaemon.com...

 Come to think of it....

 How will...

 Matrix ** Integer


  Integer ** Matrix

 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




 either

 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


 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
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


and

 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()...


 Hm... Maybe a^^b?


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()...


 Hm... Maybe a^^b?


 It looks like a logical xor to me.


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()...


 Hm... Maybe a^^b?


 It looks like a logical xor to me.


 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?


 It looks like a logical xor to me.


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


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




operands

 are guaranteed to be either 0 or 1.


 So, instead use !a != !b.  Still not inconvenient.


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


be

 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


 be

 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?


 It looks like a logical xor to me.


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


 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
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


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 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


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, 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


 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, 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


 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,




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?


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








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,




 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?


 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,




 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?


 
 
 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.


 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.


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


 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, 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) { }
}
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) { }
 }





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