> (b) Go the whole hog and design a system that allows creation of arbitrary operators and overloading the precedence of these and existant operators. This actually *would* allow your system to live up to the rhetoric, but
you
> have to put up with the proliferation of style choices made by each individual programmer you work with, and live with the fact that that a maintenance programmer who is unfamiliar with the given mathematical notation will have an uphill battle to be able to work on your codebase.

I think it's funny that you believe that somebody that "is unfamiliar with the given mathematical notation" would be able to understand the concepts involved in such a codebase enough to *qualify* as a maintenance programmer. I know this firsthand... I never took Calculus, so reading research papers which deal with mathematical subject matter (as I have many occasion to do as a 3D graphics programmer) usually means I'm left not fully grokking the theory behind why something works, just because they're using notation to do the explanation... notation I never learned properly.

Yes, to the inexperienced, it looks like job security.  Forcing mathematical concepts to be handled thru functional notation just results in really unreadably messy math, and if your *math* is unreadable, you are bound to have bugs in the math code.  Let's see that maintenance programmer try to fix some of those.

Sean

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:9rj3u0$2pf2$1@digitaldaemon.com...
> For those who've been shot in the foot and are against operator
overloading,
> I have this to say:   if you can't tolerate being shot in the foot, you
may
> be in the wrong profession.  ;)
>
> Sean


Owwww! -Walter

While operator overloading is an idea with many merits, I just don't see that arbitrary operators with arbitrary precedence would lead to something that wouldn't be better done with YACC.

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:9rj5av$2qnl$1@digitaldaemon.com...
> > (b) Go the whole hog and design a system that allows creation of
arbitrary
> > operators and overloading the precedence of these and existant
operators.
> > This actually *would* allow your system to live up to the rhetoric, but
> you
> > have to put up with the proliferation of style choices made by each individual programmer you work with, and live with the fact that that a maintenance programmer who is unfamiliar with the given mathematical notation will have an uphill battle to be able to work on your codebase.
>
> I think it's funny that you believe that somebody that "is unfamiliar with the given mathematical notation" would be able to understand the concepts involved in such a codebase enough to *qualify* as a maintenance
programmer.
> I know this firsthand... I never took Calculus, so reading research papers which deal with mathematical subject matter (as I have many occasion to do as a 3D graphics programmer) usually means I'm left not fully grokking the theory behind why something works, just because they're using notation to
do
> the explanation... notation I never learned properly.
>
> Yes, to the inexperienced, it looks like job security.  Forcing
mathematical
> concepts to be handled thru functional notation just results in really unreadably messy math, and if your *math* is unreadable, you are bound to have bugs in the math code.  Let's see that maintenance programmer try to fix some of those.
>
> Sean
>
>
>

Walter wrote:

> While operator overloading is an idea with many merits, I just don't see that arbitrary operators with arbitrary precedence would lead to something that wouldn't be better done with YACC.

Much of the operator overloading I've seen often appears to be little more than a wish for an infix notation, to use instead standard functional call notation used to invoke a two parameter function.  Rather than directly support operator overloading, why not support a generic infix function call?

So, instead of:  val = pow(2,10);

We could have:  val = 2 pow 10;

Then, if I wish to "overload" the multiplication operator, I might do something like this:

myType x(myType a, myType b) infix { return <however these two types multiply>;
}

And use it like this:  product = varA x varB;

For functions of two parameters, perhaps the infix form can be unambiguously detected by its use, and no "infix" keyword or declaration syntax will be needed.  Be sure to give user-defined infix operators the lowest possible precedence, which should also encourage the use of parentheses to clarify such notation.

Is this Food or Fluff?  It certainly is Syntactic Sugar, but it looks sweet to me...


-BobC

I agree.
I suggested something like this.
see Operator overloading, ann other idea

Ciao

Roland


"Robert W. Cunningham" a écrit :

> Walter wrote:
>
> > While operator overloading is an idea with many merits, I just don't see that arbitrary operators with arbitrary precedence would lead to something that wouldn't be better done with YACC.
>
> Much of the operator overloading I've seen often appears to be little more than a wish for an infix notation, to use instead standard functional call notation used to invoke a two parameter function.  Rather than directly support operator overloading, why not support a generic infix function call?
>
> So, instead of:  val = pow(2,10);
>
> We could have:  val = 2 pow 10;
>
> Then, if I wish to "overload" the multiplication operator, I might do something like this:
>
> myType x(myType a, myType b) infix { return <however these two types multiply>;
> }
>
> And use it like this:  product = varA x varB;
>
> For functions of two parameters, perhaps the infix form can be unambiguously detected by its use, and no "infix" keyword or declaration syntax will be needed.  Be sure to give user-defined infix operators the lowest possible precedence, which should also encourage the use of parentheses to clarify such notation.
>
> Is this Food or Fluff?  It certainly is Syntactic Sugar, but it looks sweet to me...
>
> -BobC

> So, instead of:  val = pow(2,10);
> 
> We could have:  val = 2 pow 10;

The problem arises what is if you have:
x = 2 pow 10 pow 3;

Should it do pow(pow(2 , 10), 3) , or pow(2, pow(10, 3)) ?

or with x = 2 pow 3 x 4 * 2 + 7 % 3 pow 8;

How do you define and sort priority of these new infix functions? Additionally you should be able to tell the compiler which rules this operation follows, is it communative? associative? can he extract common arguments? like a * b + a * c => a * (b + c).

I think a general operator decleration and ruling system is something nobody yet managed to design/implement.

- Axel
-- 
|D) http://www.dtone.org

This problem could not be soulved by defining operator precedence levels ? e.g :

Level 1
--------------------
~ , ^ , &, ando anothers
Level 3
--------------------
* / %
Level 5
--------------------
+ -
Level 7
--------------------
* / %
Level 9
--------------------
== != > <

Two or more operator in same level can be operated in any order. Your infix fuction level must be in ( 0..10 ).

> So, instead of:  val = pow(2,10);
>
> We could have:  val = 2 pow 10;

The problem arises what is if you have:
x = 2 pow 10 pow 3;

Should it do pow(pow(2 , 10), 3) , or pow(2, pow(10, 3)) ?

or with
x = 2 pow 3 x 4 * 2 + 7 % 3 pow 8;

How do you define and sort priority of these new infix functions? Additionally you should be able to tell the compiler which rules this operation follows, is it communative? associative? can he extract common arguments? like a * b + a * c => a * (b + c).

I think a general operator decleration and ruling system is something nobody yet managed to design/implement.

- Axel

"Axel Kittenberger" <axel@dtone.org> wrote in message news:9s62ji$1hoh$1@digitaldaemon.com...
> > So, instead of:  val = pow(2,10);
> >
> > We could have:  val = 2 pow 10;
>
> The problem arises what is if you have:
> x = 2 pow 10 pow 3;
>
> Should it do pow(pow(2 , 10), 3) , or pow(2, pow(10, 3)) ?
>
> or with
> x = 2 pow 3 x 4 * 2 + 7 % 3 pow 8;
>
> How do you define and sort priority of these new infix functions? Additionally you should be able to tell the compiler which rules this operation follows, is it communative? associative? can he extract common arguments? like a * b + a * c => a * (b + c).
>
> I think a general operator decleration and ruling system is something nobody yet managed to design/implement.
>
> - Axel
> --
> |D) http://www.dtone.org

I think I'd rather deal with precedence in terms of existing operators in the language.  i.e. give my new super_plus operator the same precedence as operator +, or maybe give my dot product operator a higher precedence than operator *, but lower than unary &.  In fact though I wouldn't mind having to use explicit parens around my expressions for now until someone works out a good system for this.

I like the commutative/associative modifiers (there are more, but I'm no mathematician) because they give the compiler hints about how it can rearrange expressions during optimization, something it does know about the builtin operators.  M1 * M2 != M2 * M1 when M is a matrix, or a quaternion.

The big problem to be solved here is how can you make a language parser that can insert arbitrary grammar pieces into the parser during compilation, in fact it would have to be done only within a certain scope.  Even more troublesome is that a symbol may not be visible in the source file; it'd have to be able to change the grammar to add these operators whenever it detects a scope has been accessed/entered during parsing of an expression.

Another big problem for operator overloading is how to deal with promotion of arguments.  Ideally this could be done by stating a preference for one typecast direction over another, thus preferring float->double as safer than double->float for instance, char->int as safer than int->char, so that if it sees 'R' plus 43 it'll know to promote the 'R' to int instead of vice-versa.

I'm disappointed that there will likely be no operator overloading in D 1.0.

Sean

"Juarez Rudsatz" <juarez@mpsinf.com.br> wrote in message news:9s6dbf$1pv9$1@digitaldaemon.com...
> This problem could not be soulved by defining operator precedence levels ? e.g :
>
> Level 1
> --------------------
> ~ , ^ , &, ando anothers
> Level 3
> --------------------
> * / %
> Level 5
> --------------------
> + -
> Level 7
> --------------------
> * / %
> Level 9
> --------------------
> == != > <
>
> Two or more operator in same level can be operated in any order. Your infix fuction level must be in ( 0..10 ).
>
> > So, instead of:  val = pow(2,10);
> >
> > We could have:  val = 2 pow 10;
>
> The problem arises what is if you have:
> x = 2 pow 10 pow 3;
>
> Should it do pow(pow(2 , 10), 3) , or pow(2, pow(10, 3)) ?
>
> or with
> x = 2 pow 3 x 4 * 2 + 7 % 3 pow 8;
>
> How do you define and sort priority of these new infix functions? Additionally you should be able to tell the compiler which rules this operation follows, is it communative? associative? can he extract common arguments? like a * b + a * c => a * (b + c).
>
> I think a general operator decleration and ruling system is something nobody yet managed to design/implement.
>
> - Axel
>
> "Axel Kittenberger" <axel@dtone.org> wrote in message news:9s62ji$1hoh$1@digitaldaemon.com...
> > > So, instead of:  val = pow(2,10);
> > >
> > > We could have:  val = 2 pow 10;
> >
> > The problem arises what is if you have:
> > x = 2 pow 10 pow 3;
> >
> > Should it do pow(pow(2 , 10), 3) , or pow(2, pow(10, 3)) ?
> >
> > or with
> > x = 2 pow 3 x 4 * 2 + 7 % 3 pow 8;
> >
> > How do you define and sort priority of these new infix functions? Additionally you should be able to tell the compiler which rules this operation follows, is it communative? associative? can he extract common arguments? like a * b + a * c => a * (b + c).
> >
> > I think a general operator decleration and ruling system is something nobody yet managed to design/implement.
> >
> > - Axel
> > --
> > |D) http://www.dtone.org
>
>

Axel Kittenberger wrote:
> associative, or communative, or ummm. I forget now the name of the last one from a = b, and b = c follows a = c.
transitive

Walter wrote:
> 
> I agree that operator overloading can be used for matrix and vector classes, in fact, the first user of my C++ compiler used it to develop a matrix class! The results were disappointing, though. It's amazingly difficult to write a good class that overloads operators.

There are lots of other common applications, too; consider a Date
class. In Java, the lack of operator overloading means that to add
a number of days to a Date you have to write this:
   d.setDate( d.getDate() + n );
and to compare dates:
   if (d1.before(d2)) ...

In "sensible" languages (C++, Ada etc.), you can overload operators
so that you can say "if (d1 + n < d2) ...", which IMHO is a hell of
a lot more readable.

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------