• Roland (21/21) Aug 27 2001 I assume D don't have operator overloading.
• Brendan Wright (5/10) Aug 30 2001 I wouldn't honestly know about much about what hassles this sort of thin...
• Brent Schartung (9/16) Aug 30 2001 Careful. I think we're straying dangerously close to "function objects"...
• Dan Hursh (43/58) Aug 30 2001 I don't think the issue is whether or not it can be done. In C++ (the
• Brendan Wright (11/52) Aug 31 2001 phew! I'm not really the expert on this one either. Less expert than you...
• Russ Lewis (6/9) Aug 31 2001 This is a good thing to remember. It is (comparatively) easy to retrofi...
• Charles Hixson (22/29) Sep 05 2001 eeeep! Not very nice at all. Operators should be clearly demarkated
• Roland (13/50) Sep 05 2001 for me 'm3 = m1 plus m2;' is recognizable enough.
• Russ Lewis (10/23) Sep 05 2001 Using infix words is nice in your example, but I think that it will tend...
• Roland (14/23) Sep 06 2001 i tried to translate

Roland <rv ronetech.com> writes:

I assume D don't have operator overloading.

too bad, how will i do with my vectors and matrixs ?

i will have to translate declaration:

Matrix operator+(Matrix& m1, Matrix& m2);

executed:

Matrix m1,m2,m3;
m3 = m1+m2;

to declaration:

Matrix plus(Matrix& m1, Matrix& m2);

executed:

Matrix m1,m2,m3;
m3 = plus(m1,m2);

not very nice..

now imagine 'plus' function could be called like this:

m3 = m1 plus m2;

better isn't it ?
is technicaly possible ?
if yes, no need for operator overloading any more.

sorry for my bad english

Regards

Roland

"Brendan Wright" <brendan_wright hotmail.com> writes:

 now imagine 'plus' function could be called like this:

 m3 = m1 plus m2;

 better isn't it ?
 is technicaly possible ?
 if yes, no need for operator overloading any more.

I wouldn't honestly know about much about what hassles this sort of thing
could introduce, but for 3D work etc it sure would make code heaps nicer and
cleaner!! I hope something can be done to implement some form of operator
overloading...

-Brendan

"Brent Schartung" <bschartung home.com> writes:

Careful.  I think we're straying dangerously close to "function objects",
one of the most obscure features of C++ (IMHO of course).  For the
uninitiated, it's a class with operator() defined; i.e. less::operator()
(char*t,int n); --I think that's right--so you can pass it to a template,
for example.  Say you define a less class that operates on two of your
classes; you'd use that less class to create a sorting template class.
Weird?

Possibly useful, definitely one of the dustier corners of the language.

Brent


 now imagine 'plus' function could be called like this:

 m3 = m1 plus m2;

 better isn't it ?
 is technicaly possible ?
 if yes, no need for operator overloading any more.

Dan Hursh <hursh infonet.isl.net> writes:

Brendan Wright wrote:
 
 now imagine 'plus' function could be called like this:

 m3 = m1 plus m2;

 better isn't it ?
 is technicaly possible ?
 if yes, no need for operator overloading any more.

 
 I wouldn't honestly know about much about what hassles this sort of thing
 could introduce, but for 3D work etc it sure would make code heaps nicer and
 cleaner!! I hope something can be done to implement some form of operator
 overloading...
 
 -Brendan

	I don't think the issue is whether or not it can be done.  In C++ (the
nature model to look at for another C follow up) operator overloading
has caused a number of problems.  The question is can it be done
better.  Walter has addressed some of the more common uses of operator
overloading.  String concatenation and (... something else that evades
me at the moment).  
	Like you, I agree that overloading is a good thing, because I like to
do 3D math on occasion.  Even if D did include a way of doing 3D math,
I've found that in other languages that there are tradeoffs that can be
made on implementation, so it is not likely that D will find the one
true way that is good (or even reasonable) in all imaginable cases.  (I
could be wrong.)  So a library should do it, but a library can only
prove a procedural interface when infix is much more appropriate.
	That is not a reason to just cop out and pick a sorry implementation
for operator overloading.  We should investigate something better.  I
see a few problems with progress here.  
	1) there is one Walter, and his hands are full.
	2) ops overloading does seem important to Walter and
	   it is hardly a show stopper for D.  I would hold out
	   of a later version to review this.
	3) In order to fix the problems, we would need a good formal
	   statement of the problems.  I personally am too biased in
	   favor of ops overloading to do that.
	4) formally state the desired function.  For me it is a lot more
	   string concatenation.  I haven't really gotten my head around 
	   this myself, so I haven't pushed it.

	For me I think it boils down to wanting my own infix operations for
certain types.  I haven't been able to justify the need for the regular
operators used on built-ins, except for in the case of writing generic
functions that can operate on both built-ins and ADT's with infix ops. 
Since D doesn't have an answer for generic programming either, it's
premature to use that argument.
	I like the idea for writing my own first class objects, but C++ didn't
exactly get that right either, so it is hard to argue from that
perspective.  Since D doesn't not seem interested in wandering down the
road of reflectiveness, I don't really have any good arguments.

	I would like to hear some of the good reasons against operator
overloading.  "I don't like it", "C++ did it wrong so it sucks" and "I
shot myself in the foot with it" don't count.  How you shot yourself is
valid.  Exactly how C++ got it wrong is valid too.  Personal ascetics
can go either way depend on the reasons.

Dan

"Brendan Wright" <brendan_wright hotmail.com> writes:

 I don't think the issue is whether or not it can be done.  In C++ (the
 nature model to look at for another C follow up) operator overloading
 has caused a number of problems.  The question is can it be done
 better.  Walter has addressed some of the more common uses of operator
 overloading.  String concatenation and (... something else that evades
 me at the moment).
 Like you, I agree that overloading is a good thing, because I like to
 do 3D math on occasion.  Even if D did include a way of doing 3D math,
 I've found that in other languages that there are tradeoffs that can be
 made on implementation, so it is not likely that D will find the one
 true way that is good (or even reasonable) in all imaginable cases.  (I
 could be wrong.)  So a library should do it, but a library can only
 prove a procedural interface when infix is much more appropriate.
 That is not a reason to just cop out and pick a sorry implementation
 for operator overloading.  We should investigate something better.  I
 see a few problems with progress here.
 1) there is one Walter, and his hands are full.
 2) ops overloading does seem important to Walter and
    it is hardly a show stopper for D.  I would hold out
    of a later version to review this.
 3) In order to fix the problems, we would need a good formal
    statement of the problems.  I personally am too biased in
    favor of ops overloading to do that.
 4) formally state the desired function.  For me it is a lot more
    string concatenation.  I haven't really gotten my head around
    this myself, so I haven't pushed it.

 For me I think it boils down to wanting my own infix operations for
 certain types.  I haven't been able to justify the need for the regular
 operators used on built-ins, except for in the case of writing generic
 functions that can operate on both built-ins and ADT's with infix ops.
 Since D doesn't have an answer for generic programming either, it's
 premature to use that argument.
 I like the idea for writing my own first class objects, but C++ didn't
 exactly get that right either, so it is hard to argue from that
 perspective.  Since D doesn't not seem interested in wandering down the
 road of reflectiveness, I don't really have any good arguments.

 I would like to hear some of the good reasons against operator
 overloading.  "I don't like it", "C++ did it wrong so it sucks" and "I
 shot myself in the foot with it" don't count.  How you shot yourself is
 valid.  Exactly how C++ got it wrong is valid too.  Personal ascetics
 can go either way depend on the reasons.

phew! I'm not really the expert on this one either. Less expert than you it
seems anyway. Without operator overloading the language does stay nice and
clean I guess, op. overloading seems to kind of hide a lot of what is really
going on - possibly not a good thing when it cames to making a nice simple
high-performing language. Perhaps we could start an underground movement to
develop a secret pre-processor that converts op. overloading code to
procedural or whatever. Because there must be a level at which you can do a
simple "operator -> two input function call" conversion without getting
involved in Dangerous Tricky Things. But then again, maybe I just don't
understand the issues... :-)

-Brendan

Russ Lewis <russ deming-os.org> writes:

Dan Hursh wrote:

         2) ops overloading does seem important to Walter and
            it is hardly a show stopper for D.  I would hold out
            of a later version to review this.

This is a good thing to remember.  It is (comparatively) easy to retrofit
operator
overloading and templates into the language specification later.  If we include
some poorly designed version now, that design will have a lot of inertia (to
support old code).  Let's leave questionable features out for now and help
Walter
get the compiler out *yesterday*.

Charles Hixson <charleshixsn earthlink.net> writes:

Roland wrote:

 ...  now imagine 'plus' function could be called like this:

 m3 = m1 plus m2;

 better isn't it ? is technicaly possible ? if yes, no need for
 operator overloading any more.

 sorry for my bad english

 Regards

 Roland

eeeep!  Not very nice at all.  Operators should be clearly demarkated 
from the rest of the language, distinguishable at a glance.  The alter 
the order of invocation.  Now in FORTH there are fancy things that 
appear to be operators, but actually act quite differently, but even in 
that foot-loose language there tends to be a clear syntactic marker used 
to differentiate those words from the others.  (I can't remember what it 
is anymore.  Either they begin with a period or end with a colon or some 
such.  It's purely a convention, but it's so necessary for the language 
to be understood that it tends to be adhered to even though anyone can 
define any word of any kind that they choose.  Or even redefined words 
standardly defined in the system.)

I prefer something simple, like :+: or :plus:, but note the boundary 
markers.  This would make them distinguishable at a glance.  And I think 
that this would be important.  These are actually just method calls with 
sugar, i.e., a :+: b == a.:+:(b), there shouldn't be much compiler 
overhead, and I feel that they should be a overloadable as any other 
method.  But I am not arguing that the standard operators should be 
overloadable.  They may have special compiler optimizations, etc.  But I 
think that user definable operators are desireable, and that they should 
be overloadable.  But for the sake of intelligibility, please keep their 
syntax class easily recognizable.

Roland <rv ronetech.com> writes:

Charles Hixson a écrit :

 Roland wrote:

  > ...  now imagine 'plus' function could be called like this:
  >
  > m3 = m1 plus m2;
  >
  > better isn't it ? is technicaly possible ? if yes, no need for
  > operator overloading any more.
  >
  > sorry for my bad english
  >
  > Regards
  >
  > Roland
  >
 eeeep!  Not very nice at all.  Operators should be clearly demarkated
 from the rest of the language, distinguishable at a glance.  The alter
 the order of invocation.  Now in FORTH there are fancy things that
 appear to be operators, but actually act quite differently, but even in
 that foot-loose language there tends to be a clear syntactic marker used
 to differentiate those words from the others.  (I can't remember what it
 is anymore.  Either they begin with a period or end with a colon or some
 such.  It's purely a convention, but it's so necessary for the language
 to be understood that it tends to be adhered to even though anyone can
 define any word of any kind that they choose.  Or even redefined words
 standardly defined in the system.)

 I prefer something simple, like :+: or :plus:, but note the boundary
 markers.  This would make them distinguishable at a glance.  And I think
 that this would be important.  These are actually just method calls with
 sugar, i.e., a :+: b == a.:+:(b), there shouldn't be much compiler
 overhead, and I feel that they should be a overloadable as any other
 method.  But I am not arguing that the standard operators should be
 overloadable.  They may have special compiler optimizations, etc.  But I
 think that user definable operators are desireable, and that they should
 be overloadable.  But for the sake of intelligibility, please keep their
 syntax class easily recognizable.

for me 'm3 = m1 plus m2;' is recognizable enough.

the main arguments against operator overloading i note are:
- it hides computation time too much,
- you can't make a find on '+' word as it will find you overloaded operator
and normal one as well.

when i read 'm3 = m1 plus m2' i know:
- m1 or m2 or both are classes,
- 'plus' is a function i wrote and i can make a find on its name.
personally don't need any more.

i think Brent Schartung argument:
Careful.  I think we're straying dangerously close to "function objects",
one of the most obscure features of C++

is better if D implements function objects.

Roland

Russ Lewis <russ deming-os.org> writes:

Roland wrote:

 for me 'm3 = m1 plus m2;' is recognizable enough.

 the main arguments against operator overloading i note are:
 - it hides computation time too much,
 - you can't make a find on '+' word as it will find you overloaded operator
 and normal one as well.

 when i read 'm3 = m1 plus m2' i know:
 - m1 or m2 or both are classes,
 - 'plus' is a function i wrote and i can make a find on its name.
 personally don't need any more.

 i think Brent Schartung argument:
Careful.  I think we're straying dangerously close to "function objects",
one of the most obscure features of C++

 is better if D implements function objects.

Using infix words is nice in your example, but I think that it will tend to
suffer from 'PERL syndrome' (so much syntax flexibility that the code is nearly
impossible to read).  This might also be legal:

   var1 each word in this line is another operator but which ones do what var2;

Which would also be legal.

I really like operator overloading in C++, but I understand that it may be too
complex or unnecessary for most applications.  What can we do about this?

I have a ponder...but it's OT enough I'm going to start a new thread about it.
Look for 'externally processed blocks'.

Roland <rv ronetech.com> writes:

Russ Lewis a écrit :

 Roland wrote:

 for me 'm3 = m1 plus m2;' is recognizable enough.

 Using infix words is nice in your example, but I think that it will tend to
 suffer from 'PERL syndrome' (so much syntax flexibility that the code is nearly
 impossible to read).  This might also be legal:

    var1 each word in this line is another operator but which ones do what var2;

 Which would also be legal.

i tried to translate

var1 each word in this line is another operator but which ones do what var2;

replace 'each' by '+', 'word' by '-', 'in' by '/' ..'what' by '*', you have
something like

var1 +-/..* var2;

not legal in C++

an other way is to translate like this (all one argument operator exept 'each'):

each(var1,
word(in(this(line(is(another(operator(but(which(ones(do(what(var2)))))))))))));

witch is less clear than

var1 each word in this line is another operator but which ones do what var2;

 Look for 'externally processed blocks'.

 i will

Roland