> > If everyone is dead keen on operator overloading, then let's have it.
But
> > if we're going to add it, let's at least be able to add new (lexically
new)
> > operators such as A . B and ||v||.  I can live with inheriting the precedence of 'standard' operators such as * - + / etc, as long as for
new
> > operators you can specificy their precedence (e.g., I'd like ||v|| to
have
> > the smae precedence as unary -)
>
> Agreed, with support for operators written with arbitrary Unicode.
>
> (Arrggh. I'm crushed. The bastards rejected the Klingon encoding for
Unicode.
> There is no justice in the world.)

:-) hehe

hehe - I don't like operator overloading either, but given that everyone was beating me up about it, I assumed I was in the minority.  I agree with everything on your list.

Peter.

"Angus Graham" <agraham_d@agraham.ca> wrote in message news:9m1epf$1d47$1@digitaldaemon.com...
> "kaffiene" <kaffiene@xtra.co.nz> wrote
>
> > If everyone is dead keen on operator overloading, then let's have it.
>
> Not everyone is dead keen on it.  I haven't commented on the subject (or followed this thread) simply because I'm so uninterested in it.
>
> But so that my silence != consent, I will say what I don't like about overloaded operators (although I'm sure I will repeat some stuff).
>
> - I don't like not being able to see at a glance what is a built in type
and
> what is a class.  Stroustrup thinks classes should not be second class
> citizens. I disagree.
> - I don't like the added complexity to the language.
> - I don't look forward to explaining their use to new programmers.
> - I don't like the way overloaded operators can be easily written wrong
and
> used wrong so that they generate various temporaries and assignments that
> are not obvious to the programmer.
> - I don't like the way overloaded operators hide their true runtime cost
in
> a cursory look at the code.
> - I don't like the way they are harder to debug, as they encourage putting
> many function calls on one line.
> - I don't like the way they reduce the self-documenting nature of code.
> concatenate() is clear,
>
convert_strings_to_integer_representations_and_add_them_and_then_convert_res
> ult_to_string() is clear, but string_result = string1 + string2 is
> definitely not clear.
> - I don't like the way we always end up with some classes using overloaded
> operators and some not leading to two ways of doing the same thing.
>
>
> Angus Graham
>
> ps
> - I do not like them on a train.
> - I do not like them on a plane.
> - I do not like them here nor there.
> - I do not like them anywhere.
>
>
>

Angus Graham wrote:

> "kaffiene" <kaffiene@xtra.co.nz> wrote
>
> - I don't like not being able to see at a glance what is a built in type and what is a class

So do I.

> . - I don't like the way they reduce the self-documenting nature of code. concatenate() is clear, convert_strings_to_integer_representations_and_add_them_and_then_convert_res ult_to_string() is clear, but string_result = string1 + string2 is definitely not clear.

I Agree. Using (member) functions with a clear self explaining name as Add, Minus, Eq, Ge, Gt, Le, etc is more self explaining as anything else IMHO.

> Angus Graham
>
> ps
> - I do not like them on a train.
> - I do not like them on a plane.
> - I do not like them here nor there.
> - I do not like them anywhere.

<g>

Arjan

Yes overloaded operators are useful.
Creating operators like Charles Hixson sugest can be usefull as well !
Me if i use D langage in the future, i would like to have both.

In fact Charles Hixson's way it looks like an other way of calling functions
with the first argument placed before the name of the function and the second
argument placed after the name of the function and no parenthesis.
why not any function with one or two arguments be able to be called that way ?

Roland

Charles Hixson a écrit :

> Overloaded operators can be quite useful, but perhaps the standard operators shouldn't be overloadable.  Perhaps one should instead be able to define infix functions (i.e., operators) have a form like, O, just as a wild choice /\:[-~!@#$%^&*_+`,?0-9A-z]*\:/, i.e., no white space, no colons, no control characters, no parens, bracketts, or braces, no backslash, and surrounded by colons.  Also require white-space separation from everything else.  So one could define :+: to add matrices, etc., and as these would really be functions, they should follow the normal overloading rules of functions.
>
> This would allow them to be easily parsed, would distinguish them
> clearly from the standard operators, and would provide the majority of
> the notational compactness that normal operators provide.  The fact that
> A :+: B would be syntactic sugar for A.add (B) is minor, but convenient.
>    As to precedence ... they should probably bind more strongly than any
> other operator, and all to the same degree.  If you want to get fancy,
> you'ld need to use parentheses.

	It seemed like you were mostly against A + B and Add(A, B) being
synonyms, right?  (OK you said A.add(B), but I hate that syntax and C++
supported the other so I used it.)  Anyhow, what would you think of a
syntax that allowed the design of an API to decide with a routine would
be only an infix or if there could be a public function syntax too?  We
don't need to use C++ syntax.  It was pretty ugly.  If anything, it
sound like Walter wants D to be an apology for what C++ did to C.
	I only want the operators because I doubt that we can anticipate all
the good ways people use operators when they can.  If we are sure we can
cover it all, then fine, otherwise I'd hate to lose a good tool just
because somebody else abused it.  I'm not dead set on passing out guns
and rope for the inexperience to shoot and hang themselves with, but the
inexperienced can injure themselves with some of the most handy and
powerful of tools.  It might be it a good idea to leave operator
overloading the the advanced or special purpose chapter of the manual
and let the programmer grow into it, kind of like word alignment, inline
assembler and alternate calling conventions.

Dan

kaffiene wrote:
> 
> If everyone is dead keen on operator overloading, then let's have it.  But if we're going to add it, let's at least be able to add new (lexically new) operators such as A . B and ||v||.  I can live with inheriting the precedence of 'standard' operators such as * - + / etc, as long as for new operators you can specificy their precedence (e.g., I'd like ||v|| to have the smae precedence as unary -)
> 
> Peter.
> 
> "kaffiene" <kaffiene@xtra.co.nz> wrote in message news:9m17t7$19b9$1@digitaldaemon.com...
> > [snip]
> >
> > > I take your point and will try to avoid that in the future, but I'd like
> > you to
> > > get back to the point and answer my questions. How is A.Add(B) not
> > introducing
> > > maintenance complexity in complicated expressions? How is A.Add(B) not
> > adding a
> > > new notation that differs from the traditional A+B?
> >
> > My point is that you will be using <class>.<method>(<params>) anyway for 'normal' methods on the class - some people will use this for things like addition , subtraction etc... other people will use <class> + <class>, <class> * scalar etc...  When you get programmers looking over the code, some classes will do things using method calls, some will do things using overloaded operators.  The code is therefore more variant in style which means an increased maintenence cost.
> >
> > In *either* approach (overloaded operators or all method calls) you will still get the situation that a + b will be valid for all scalars and
> invalid
> > for some classes
> > (all in the case of no operator overloading).  Even if you allow operator
> > overloading, you can still have A.Add(B) as a variant notation so I reject
> > the assertion that not having operator overloading gives you a 'new
> > notation'.
> >
> > >
> > > > > No, that is a very bad idea, and not only for technological reasons. Mathematicians invented operator precedence, not compilers
> (precedence
> > is
> > > > not
> > > > > an artifact of limited technology, it is a simplifying notation.) I
> > don't
> > > > know
> > > > > of any context where mathematicians read AxB+C as meaning
> (Ax(B+C))...
> > But
> > > >
> > > > If you are talking about vectors, then A + B * C is the vector A added
> > to
> > > > vector B (resulting in a vector) crossed with the vector C (resulting
> in
> > a
> > > > vector).  This evaluates as (A + B) * C.  There you have a context in
> > which
> > > > the standard arithmetic operator precedence does not hold.
> > >
> > > ??? You may be right in your field, but that's the very first time I
> ever
> > hear
> > > this. Any pointer justifying this notation?
> > >
> > > Let me take a few books here. Quantum mechanics book, formula H^=E0+A'/4.sigma1.sigma2+Dsigma[1,z].sigma[2.z]. I know that the . has
> > higher
> > > precedence here, no parentheses.
> > >
> > > An old book by Lillian Lieber on Relativity (one of the few I have in
> > English):
> > > Tensor notation all over the place: A.B+C.D, where + is lower priority.
> > Just in
> > > case you wonder, some of these tensor products actually are the dot
> > product you
> > > are describing
> > >
> > > A third book, same thing, sampling three equations at random, they all
> had
> > > A+B.C mean A+(B.C).
> > >
> > > So, again, I'm very curious wrt. the field where A+B.C means (A+B).C. If
> > this
> > > is a "frequent case", I might change my mind on priority of operators in
> > LX.
> >
> > Oh sorry - I didn't mean to imply that the + operator had a higher precedence than *, I was using the brackets to indicate how the notation
> is
> > parsed naturally.  The + operator - vector addition does not have a naturally higher precedence than * - vector cross product.  It parses naturally left to right.
> >
> > [snip]
> >
> > Peter.
> >
> >

Mind if I put that in the FAQ? -Walter

Angus Graham wrote in message <9m1epf$1d47$1@digitaldaemon.com>...
>"kaffiene" <kaffiene@xtra.co.nz> wrote
>
>> If everyone is dead keen on operator overloading, then let's have it.
>
>Not everyone is dead keen on it.  I haven't commented on the subject (or followed this thread) simply because I'm so uninterested in it.
>
>But so that my silence != consent, I will say what I don't like about overloaded operators (although I'm sure I will repeat some stuff).
>
>- I don't like not being able to see at a glance what is a built in type
and
>what is a class.  Stroustrup thinks classes should not be second class
>citizens. I disagree.
>- I don't like the added complexity to the language.
>- I don't look forward to explaining their use to new programmers.
>- I don't like the way overloaded operators can be easily written wrong and
>used wrong so that they generate various temporaries and assignments that
>are not obvious to the programmer.
>- I don't like the way overloaded operators hide their true runtime cost in
>a cursory look at the code.
>- I don't like the way they are harder to debug, as they encourage putting
>many function calls on one line.
>- I don't like the way they reduce the self-documenting nature of code.
>concatenate() is clear,
>convert_strings_to_integer_representations_and_add_them_and_then_convert_re
s
>ult_to_string() is clear, but string_result = string1 + string2 is
>definitely not clear.
>- I don't like the way we always end up with some classes using overloaded
>operators and some not leading to two ways of doing the same thing.
>
>
>Angus Graham
>
>ps
>- I do not like them on a train.
>- I do not like them on a plane.
>- I do not like them here nor there.
>- I do not like them anywhere.
>
>
>

Dan Hursh wrote:
> 	It seemed like you were mostly against A + B and Add(A, B) being
> synonyms, right?  (OK you said A.add(B), but I hate that syntax and
> C++ supported the other so I used it.)  Anyhow, what would you think
> of a syntax that allowed the design of an API to decide with a routine would be only an infix or if there could be a public function
> syntax too?  We don't need to use C++ syntax.  It was pretty ugly....
> 
> Dan
> ...
But you can certainly do it the way you are talking about.  Add (A, B) always works (inside of a class) if Add is a method of the class.  So just make it a method of Object (or some descendant of Object that all of your classes descend from).  Or put it in an interface that you implement, but far enough up the tree that it will be an ancestor to all the classes in which you are working.

Hmph, it's really hard to decide where exactly to put a post when you're replying to many...

So, I was thinking about operator overloading and templates a fair bit last night.  You see, I like both of them, though not enough to defend them with the zeal that some have.  Although I use them, I'd be willing to lose them, but I would mourn their demise.  While I was so thinking, I came up with an idea that had been described previously, but I don't think ever fully and in one place.

My train of thought went as such:

One of the main complaints about operator overloading is it confuses what a given operator means in a given situation.  This is a Bad Thing.  However, we get around this by not using operator overloading, but operator definition.  Thus I refer to exhibit a), by Charles Hixson:

> Perhaps one should instead be able
> to define infix functions (i.e., operators) have a form like, O, just as
> a wild choice /\:[-~!@#$%^&*_+`,?0-9A-z]*\:/, i.e., no white space, no
> colons, no control characters, no parens, bracketts, or braces, no backslash, and surrounded by colons.  Also require white-space separation from everything else.  So one could define :+: to add matrices, etc., and as these would really be functions, they should follow the normal overloading rules of functions.

Don't do operator *overloading* do operator *definition*!  So, having come up with a completely unoriginal idea, I got excited.  But :+: and :-: and :*: and such all over the place could get quite ugly, IMHO.  So how to solve this?  Enter exhibits b) and c), by Rusell Bornschlegel:

> Agreed, with support for operators written with arbitrary Unicode.

> This would let you use, e.g., u22C5 ("dot operator") for matrix
> multiply, u22C5 and u00D7 ("multiplication sign") for dot and cross
> products of vectors, u221A, u221B, u221C for square, third, and fourth
> roots, etc.

Unicode!  D supports Unicode!  Again excited that I had found somthing completely unoriginal, I rushed to my computer, and went to www.unicode.org.  I'm not an expert on Unicode, but I know what it does.  I thought to myself: "Unicode is perfect!  It must have an entire section devoted to mathematical symbols!"  And lo-and-behold!  It does!  For the interested, you can look here:

http://www.unicode.org/charts/PDF/U2200.pdf (PDF)
or here:
http://charts.unicode.org/Web/U2200.html (GIFs, but I couldn't connect)

If you haven't seen the vast extent of possibilities with this block, go check out that PDF file.  Neato.

So, the end result of my proposition is this:  Allow the definition of new infix and unary operators from the Unicode block 2200 to 22FF, mathematical operators.  Also, symbols from this block are *reserved* for new operators. (The allowance of colon delimeted operators was something I hadn't thought of... but could be another allowed grammar for new ops)

The reason I don't say 'arbitrary' unicode is that then I'd go right ahead and define all sorts of cool operators from the Japanese kanji. Obfuscated D at its finest.  Heck, I'd see if I could make Rashoomon with a few english interjections a program :)

I think this takes care of some of the concerns about operator overloading/definition.  I'm going to do a point-by-point on Angus Graham's wonderful list, which outlines just about every reason not to have operators change (and which I 100% agree with, despite liking operator overloading).  However, I'm going to rearrange it into "solved" and "not-solved":

Solved (or minimised)
---------------------

> - I don't like not being able to see at a glance what is a built in type and
> what is a class.  Stroustrup thinks classes should not be second class
> citizens. I disagree.

Problem solved.  New operators for new types.

> - I don't look forward to explaining their use to new programmers.

True, but I think that is minimised by the fact that you're adding, not redefining.

> - I don't like the way overloaded operators hide their true runtime cost in
> a cursory look at the code.

The cost would be less hidden due to the fact that they are unique, and therefore identifiable.

> - I don't like the way they reduce the self-documenting nature of code.
> concatenate() is clear,
> convert_strings_to_integer_representations_and_add_them_and_then_convert_res
> ult_to_string() is clear, but string_result = string1 + string2 is
> definitely not clear.

Less of a problem due to the uniqueness of the operators.

Not solved
----------

> - I don't like the added complexity to the language.

If you mean, just as a feature... well, I can't stop that :)

> - I don't like the way overloaded operators can be easily written wrong and
> used wrong so that they generate various temporaries and assignments that
> are not obvious to the programmer.

*sigh* I can't argue against this point, it's too true.

> - I don't like the way they are harder to debug, as they encourage putting
> many function calls on one line.

Again, a problem.

> - I don't like the way we always end up with some classes using overloaded
> operators and some not leading to two ways of doing the same thing.

Yet again, a fundamental problem.

So, I'll admit it isn't perfect, but it might be a start for a compromise between the two camps.

OTOH, to be honest, I wouldn't miss them much at all... for mathematical vectors, and that's about it.  But, in what appears to be the "philosophy of D" I was looking for the "better solution".

Yet another treatise from the guy who talks too much.

Cheers,

Eric

P.S. I never did find a solution for templates, and I'd miss them a lot... *sigh*
P.P.S. For me, generics won't cut it.  I need meta-programming...
P.P.P.S. Would you like them in a house?  Would you like them with a mouse?  Or in a box?  Or with a fox?  Would you like them with a goat? Would you like them on a boat?  (I'm sorry, I love the great Doctor... not to mention I think operator overloading is much more acceptable with a goat)

Thanks for the entertaining and excellent summary. BTW, what is "meta-programming" as opposed to generics?

Eric Gerlach wrote in message <3B892085.2060903@canada.com>...
>Hmph, it's really hard to decide where exactly to put a post when you're replying to many...
>
>So, I was thinking about operator overloading and templates a fair bit last night.  You see, I like both of them, though not enough to defend them with the zeal that some have.  Although I use them, I'd be willing to lose them, but I would mourn their demise.  While I was so thinking, I came up with an idea that had been described previously, but I don't think ever fully and in one place.
>
>My train of thought went as such:
>
>One of the main complaints about operator overloading is it confuses what a given operator means in a given situation.  This is a Bad Thing.
>  However, we get around this by not using operator overloading, but
>operator definition.  Thus I refer to exhibit a), by Charles Hixson:
>
> > Perhaps one should instead be able
> > to define infix functions (i.e., operators) have a form like, O, just as
> > a wild choice /\:[-~!@#$%^&*_+`,?0-9A-z]*\:/, i.e., no white space, no
> > colons, no control characters, no parens, bracketts, or braces, no
>backslash, and surrounded by colons.  Also require white-space separation from everything else.  So one could define :+: to add matrices, etc., and as these would really be functions, they should follow the normal overloading rules of functions.
>
>Don't do operator *overloading* do operator *definition*!  So, having come up with a completely unoriginal idea, I got excited.  But :+: and :-: and :*: and such all over the place could get quite ugly, IMHO.  So how to solve this?  Enter exhibits b) and c), by Rusell Bornschlegel:
>
> > Agreed, with support for operators written with arbitrary Unicode.
>
> > This would let you use, e.g., u22C5 ("dot operator") for matrix multiply, u22C5 and u00D7 ("multiplication sign") for dot and cross products of vectors, u221A, u221B, u221C for square, third, and fourth roots, etc.
>
>Unicode!  D supports Unicode!  Again excited that I had found somthing completely unoriginal, I rushed to my computer, and went to www.unicode.org.  I'm not an expert on Unicode, but I know what it does.
>  I thought to myself: "Unicode is perfect!  It must have an entire
>section devoted to mathematical symbols!"  And lo-and-behold!  It does!
>  For the interested, you can look here:
>
>http://www.unicode.org/charts/PDF/U2200.pdf (PDF)
>or here:
>http://charts.unicode.org/Web/U2200.html (GIFs, but I couldn't connect)
>
>If you haven't seen the vast extent of possibilities with this block, go check out that PDF file.  Neato.
>
>So, the end result of my proposition is this:  Allow the definition of new infix and unary operators from the Unicode block 2200 to 22FF, mathematical operators.  Also, symbols from this block are *reserved* for new operators. (The allowance of colon delimeted operators was something I hadn't thought of... but could be another allowed grammar for new ops)
>
>The reason I don't say 'arbitrary' unicode is that then I'd go right ahead and define all sorts of cool operators from the Japanese kanji. Obfuscated D at its finest.  Heck, I'd see if I could make Rashoomon with a few english interjections a program :)
>
>I think this takes care of some of the concerns about operator overloading/definition.  I'm going to do a point-by-point on Angus Graham's wonderful list, which outlines just about every reason not to have operators change (and which I 100% agree with, despite liking operator overloading).  However, I'm going to rearrange it into "solved" and "not-solved":
>
>Solved (or minimised)
>---------------------
>
> > - I don't like not being able to see at a glance what is a built in
>type and
> > what is a class.  Stroustrup thinks classes should not be second class citizens. I disagree.
>
>Problem solved.  New operators for new types.
>
> > - I don't look forward to explaining their use to new programmers.
>
>True, but I think that is minimised by the fact that you're adding, not redefining.
>
> > - I don't like the way overloaded operators hide their true runtime
>cost in
> > a cursory look at the code.
>
>The cost would be less hidden due to the fact that they are unique, and therefore identifiable.
>
> > - I don't like the way they reduce the self-documenting nature of code.
> > concatenate() is clear,
> >
>convert_strings_to_integer_representations_and_add_them_and_then_convert_re
s
> > ult_to_string() is clear, but string_result = string1 + string2 is
> > definitely not clear.
>
>Less of a problem due to the uniqueness of the operators.
>
>Not solved
>----------
>
> > - I don't like the added complexity to the language.
>
>If you mean, just as a feature... well, I can't stop that :)
>
> > - I don't like the way overloaded operators can be easily written
>wrong and
> > used wrong so that they generate various temporaries and assignments
that
> > are not obvious to the programmer.
>
>*sigh* I can't argue against this point, it's too true.
>
> > - I don't like the way they are harder to debug, as they encourage
>putting
> > many function calls on one line.
>
>Again, a problem.
>
> > - I don't like the way we always end up with some classes using
>overloaded
> > operators and some not leading to two ways of doing the same thing.
>
>Yet again, a fundamental problem.
>
>So, I'll admit it isn't perfect, but it might be a start for a compromise between the two camps.
>
>OTOH, to be honest, I wouldn't miss them much at all... for mathematical vectors, and that's about it.  But, in what appears to be the "philosophy of D" I was looking for the "better solution".
>
>Yet another treatise from the guy who talks too much.
>
>Cheers,
>
>Eric
>
>P.S. I never did find a solution for templates, and I'd miss them a
>lot... *sigh*
>P.P.S. For me, generics won't cut it.  I need meta-programming...
>P.P.P.S. Would you like them in a house?  Would you like them with a
>mouse?  Or in a box?  Or with a fox?  Would you like them with a goat?
>Would you like them on a boat?  (I'm sorry, I love the great Doctor...
>not to mention I think operator overloading is much more acceptable with
>a goat)
>

This is going to look like I'm jumping the fence repeatedly on operator overloading. For the record, I'm in favor of D incorporating C++'s operator overloading capability (though not necessarily using the same definition syntax) _and_ in extending this to arbitrary single-unicode-above-ASCII-character operators.

I understand the problems with operator overloading, and am willing to accept them. My need to write code manipulating matrices and vectors makes this an absolute requirement for my language-of-choice.

Eric Gerlach wrote:
> So, the end result of my proposition is this:  Allow the definition of new infix and unary operators from the Unicode block 2200 to 22FF, mathematical operators.  Also, symbols from this block are *reserved* for new operators. (The allowance of colon delimeted operators was something I hadn't thought of... but could be another allowed grammar for new ops)
> 
> The reason I don't say 'arbitrary' unicode is that then I'd go right ahead and define all sorts of cool operators from the Japanese kanji. Obfuscated D at its finest.  Heck, I'd see if I could make Rashoomon with a few english interjections a program :)

I'd be annoyed if Unicode operator definition were adopted with
that arbitrary restriction, personally. The Miscellaneous Technicals
in the 2300 block include the operators used by the APL language,
which at least have some justification for being used as user-defined
operators in a programming language. The Mathematical Operators in
the 2200 block also include a slash, an asterisk, and a tilde, so
you can't easily distinguish from the builtin operators. There are
lots of operators there that look something like other operators
in C.

Your proposal is thus simultaneously too restrictive for me, and not safe enough for Mr. Graham.

-RB