"Charles Hixson" <charleshixsn@earthlink.net> wrote in message news:3B828ADA.8010506@earthlink.net...
> kaffiene wrote:
> > "Christophe de Dinechin" <descubes@earthlink.net> wrote in message
> > news:3B80C66E.A86462DB@earthlink.net...
> > ...vector
> > example above) then the natural precendence of operators may change as
well.
> >
> > Peter.
> >
> It seems reasonable to me that all new operators should same precedence as the dot operator.  If you want to specify a different order, you need to use parenthesis.
>
> The idea here is that these operators are merely syntactic sugar for the
> functional notation.  A :+: B === A.add(B).  It is a bit easier to read.
>   But you don't want to encourage excessive proliferation, because if
> you do, then it won't be easier any more.  So you give them the same
> precedence as the dot operator.  (That's what they really are.)

I agree with your point about the profliferation of operator overloading making things harder.  That's why I was arguing previously that it's probably better not to overload operators at all.

Peter.

"Charles Hixson" <charleshixsn@earthlink.net> wrote in message news:3B828CC2.70706@earthlink.net...
> kaffiene wrote:
> > Eiffel seems to do a lot of things well that C++ doesn't.  But I'm a
bigot -
> > I can't stand that pascal-esque sytnax =)
> > ...
> >
> Eiffel is much less flexible in many ways than C++.  This is both good and bad.  The syntax doesn't matter that much if we are mining it for features to include in a new language.  Not unless we consider the syntax as one of the features that we are mining.

Oh sure!  That's exactly what I meant - I like a lot of the ideas in Eiffel. I just don't use it because of the syntax.

Peter.

Christophe de Dinechin wrote:
> 
> a wrote:
> 
> > I like the
> > suggestion of the 'written' syntax.  It is powerful but could blow off
> > several toes if aimed at one's foot.
> 
> Why? Could you give an example?
> 
> Christophe


It's hard to give an example without a concrete syntax to start with. (Christophe, you might also remember that I'm bad at examples. :)  One case I'm thinking of would be unexpected ambiguity like:

	typedef int[3] vec;
	typedef double scalar;
	vec build_vec(scalar larry, scalar curly, scalar moe)
		written ( larry curly moe )
	{
		return { larry, curly, moe }; // I know this array syntax wouldn't
	} 				      // but wouldn't it would be nice?

	scalar abs(vec tor) written || tor ||
	{            // using the sqrt syntax I defined as \/ <exp> |
		return \/tor[0] * tor[0] + tor[1] * tor[1] + tor[2] * tor[2] |;
	}

	scalar x = 0;
	scalar z = 1.0;
	vec why = {1, 1, 1}

	// NOTE: I'm assuming that abs is defined for built in types like int
	int it = abs( x || why || z ); // and that bool could cast to int

What is it?  Is it 0 since x could short circuit the '||' or is it sqrt(0, sqrt(3), 1).  It could reasonably be either.  You might be able to build a compiler that could brute force through and catch all the possible ambiguities in a given piece of code, but you could still end up with libraries that can't be used together do to a nasty mix of poorly chosen written clauses.

Don't get me wrong.  I like the feature.  It's just like many of C++'s
(or perl's) features. Beautiful when used right and dangerous if used
wrong.  The same it true of C++'s operator overloads, but man they are
handy at times.  The ability to say:
	written A * B + C
	written (A * B) + C
or the like would have made libraries like blitz++ a lot easier to do I
bet.  I suspect they would have made the templates less necessary,
making the compile times faster.  But Walter seems to favor safety and
simpler implementation.  This probably crosses a line for him.

Cheers,
Dan

kaffiene wrote:
> "Charles Hixson" <charleshixsn@earthlink.net> wrote in message
> news:3B828ADA.8010506@earthlink.net...
> 
>>kaffiene wrote:
>>
>>>"Christophe de Dinechin" <descubes@earthlink.net> wrote in message
>>>news:3B80C66E.A86462DB@earthlink.net...
>>>...vector
>>>example above) then the natural precendence of operators may change as
>>>
> well.
> 
>>>Peter.
>>>
>>>
>>It seems reasonable to me that all new operators should same precedence
>>as the dot operator.  If you want to specify a different order, you need
>>to use parenthesis.
>>
>>The idea here is that these operators are merely syntactic sugar for the
>>functional notation.  A :+: B === A.add(B).  It is a bit easier to read.
>>  But you don't want to encourage excessive proliferation, because if
>>you do, then it won't be easier any more.  So you give them the same
>>precedence as the dot operator.  (That's what they really are.)
>>
> 
> I agree with your point about the profliferation of operator overloading
> making things harder.  That's why I was arguing previously that it's
> probably better not to overload operators at all.
> 
> Peter.
> 
> 
> 

But you ignore the adjective "excessive".  It makes a big difference here.  Reasonable use of operator syntax greatly IMPROVES readability. Still, it's probably reasonable to restrict the overloading to non-predefined operators.

kaffiene wrote:

> > My impression is that your own background did not expose you to such "math-oriented" environments. Then, you are right, avoiding operator overloading is probably the right thing to do.
>
> I majored in Computer Graphics.  I quite familiar with both animation for broadcast using raytracing and real time graphics using OpenGL and DirectX. I have written several raytracers.  I am about to take up a job with a broadcast graphics company.  These are "math-oriented" environments.  Your impression is wrong.
>
> I noticed that another poster asked you to refrain from sarcasm at one point - I would also ask you to refrain from personal assumptions.  If you want to debate the technical merits of a language feature, please do so but don't do it by claiming that people with alternate opinions are ignorant.

I said it was an impression, I never claimed it was a fact. You did not qualify your comment above as such ;-) And, sometimes, sarcasm is funny, if properly identified as such. Sorry the other guy took it personally, it was actually a grunt against the C++ committee and Bjarne's decision to have template<> rather than, e.g., template[].

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?


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


>
>
> > technology also indicates that this is a bad idea, because arbitrary precedences would render most expressions ambiguous.
>
> *sigh* - please read the history of this thread.  My point is that for *new* operators that don't already exist in the language, you need to specify precedence.  For example, a Vector class could overload * for cross-product, but C++ doesn't allow overloading . (period) for dot product or ||v|| for magnitude.  If you introduce new operators you must be able to specify the precedence.  If you change the context of an operator (e.g. * in the vector example above) then the natural precendence of operators may change as well.

We have a different definition of "new" operator. You call "new" an operator that can be overloaded, I call new an operator that doesn't exist in the language.

While I have a weaker feeling about defining some arbitray precedence for "A znort B", I have a strong feeling about defining it for "A*B" as a function of the types of A and B. There, compiler technology has a serious issue, because it means that to parse any expression, you have to do semantics on the items in the expression. That makes it really really hard.

In addition, unless you give me a pointer for the A+B.C example above, I stick to it that mathematicians do not generally change the precedence of operators based on the type of arguments.


Christophe

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

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

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

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

-RB

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

Same here, I don't like operator overloads, the complexity added for 'syntactic' sugar is not worth it. I use to write C++ libraries with operator overloads, and there are so many gotchas. If someone wants those, there's always C++. --Kent