Jonathan Andrew <jon@ece.arizona.edu> escreveu em news:3D497E7A.F479D5B3 @ece.arizona.edu:

> This keeps you from being able to define new symbols to use, and
> sometimes there are cases where it would be nice to use symbols
> that don't necessarily represent adding, so forth.
> For example, if you had some kind of class for a signal function,
> and you wanted * to represent convolution, you wouldn't want to
> use a function called mul() to represent that operation, even though
> it uses the same symbol. (on a keyboard at least)
> 

I have read another post which speak about having not the operation but the symbol used:

> Maybe something like
> class Vector
> {
>       static operator(*) cross(VectorA, VectorB);
>       static operator(*) mul(VectorA, int);
>       static operator(.) dot(VectorA, VectorB);
>       .... etc.
> }
> 


In this example, the compiler can, without many problems, associate the symbol "+" with the identifier "cross". There are no need of specify it in all operator declaration.

And another post which specify a serious problem:

> A better approach would be to simply disallow overloading the global operators, and say "no" to overloading the syntax:
> 
>     1 + A;
> 
> An alternative is for the compiler to rewrite (1+A) as (A+1) and then
> look for an operator+ overload, but that can lead to trouble for (A+B)
> where both A and B overload operator+.
> 

But this have a problem

> There are mathmatical systems where A+B != B+A.

In this example, maybe could solve by making the signal operator ordinary procedures and funcions (void and <type>).

Rewriting all of this we could have:

class someType
{
    	override void cross(int i)
    	{
    	    	// this will take care of expressions like
    	    	// A + 1
    	}
    	override int cross()
    	{
    	    	// this will take care of expressions like
    	    	// 1 + A
    	}
}

And all of this could be writed in two forms:

A := A + 1;

or

A.cross(1 + A.cross());

--
dmd -JR

That is a good idea. I'm sorry I missed it when anderson said it.

"Juan Carlos Arevalo Baeza" <jcab@roningames.com> wrote in message news:ahpjb0$7k7$1@digitaldaemon.com...
>  Like anderson said. You can use different versions. I'd use two, the
> "normal" version and the reverse version:
>
> class Vector: object {
>   Vector add(Vector other); // Enough for both commutations
>   Vector mul(double other); // Vector * double
>   Vector rmul(double other); // double * Vector
> };
>
> class Matrix: object {
>   Matrix add(Matrix other); // Enough for both commutations
>   Matrix mul(double other); // Matrix * double
>   Matrix rmul(double other); // double * Matrix
>   Vector rmul(Vector other); // Vector * Matrix
> };
>
>    You can always easily do the disambiguation in whichever manner is most
> consistent with D rules.
>
> Salutaciones,
>                          JCAB
>
>
>

Just stay with the brackets then. As I said, is didn't think <> was a good option but all other brackets are in uses with C++ so I guess it's the only option. At least it's better then without.

"Pavel Minayev" <evilone@omen.ru> wrote in message
news:CFN374700137667593@news.digitalmars.com...
On Thu, 1 Aug 2002 17:29:48 +0100 "Martin M. Pedersen"
<mmp@www.moeller-pedersen.dk> wrote:

> Not really, considering the operators "<", ">", "<<", ">>", etc. "operator<<>" would be recognized by the lexer as the three tokens "operator", "<<", and ">", thereby introducing the need for extra spacing
as
> in "operator< < >" ("<>" is a token recognized by the lexer too). Its the same problem as with templates in C++ - let us learn from it.

I think round braces are the best choice. When grouped properly, they look just alright:

vector operator(+) (vector a, vector b)
{
...
}

This is a slightly different question then this line, but still in the same subject matter. In C++ I always had trouble accessing the hidden datatypes of the other member. If I didn't have direct access to some variable I'd have to write a function member so that I could access it (or even worse make the variable public). While is ok in some cases, in others it breaks the structure of the data abstraction, allowing access to members that shouldn't be even scene.

Perhaps using static (with full access to both members privates) is the solution to this, but I recon there may be some better idea. Parhaps, and I'm by no way clear on the details, could add some type of privlage system on member functions so that we can specify which functions have access to which members (or something, I'm not clear on the idea here). Parhaps I could be simular to java packages. Parhaps a class could belong to seveal prilage groups. Or parhaps theres some other better idea. I would really like the solution to this to be non-special case. Parhaps D already has something.

"Jonathan Andrew" <jon@ece.arizona.edu> wrote in message news:3D497E7A.F479D5B3@ece.arizona.edu...
> Juarez Rudsatz wrote:
>
> > "anderson" <anderson@firestar.com.au> wrote in news:aia87q$2m8d$1 @digitaldaemon.com:
> >
> > > No, I agree with you. I was thinking (to stop it looking pointerish)
...
> > >
> > >  class Vector
> > >  {
> > >        operator<*>(VectorA, VectorB);
> > >        operator<->(VectorA, int);
> > >        operator<.>(VectorA, VectorB);
> > >        .... etc.
> > >  }
> > > Or another symbol because () makes it look like a weird function (but
is
> > > better then without).
> >
> > Why not use the keyword and type already available in language :
> >
> > Class Vector
> > {
> >         void add (int A) {}             // V + 1
> >         int add () {}                   // 1 + A
> > }
>
> This keeps you from being able to define new symbols to use, and
> sometimes there are cases where it would be nice to use symbols
> that don't necessarily represent adding, so forth.
> For example, if you had some kind of class for a signal function,
> and you wanted * to represent convolution, you wouldn't want to
> use a function called mul() to represent that operation, even though
> it uses the same symbol. (on a keyboard at least)
>
>

"anderson" <anderson@firestar.com.au> wrote in news:aickhl$peh$1@digitaldaemon.com:

> 
> vector operator(+) (vector a, vector b)
> {
> ...
> }

vector operator"+"(vector a, vector b)
{
}

"Patrick Down" <pat@codemoon.com> wrote in message news:Xns925DCD940507patcodemooncom@63.105.9.61...
> "anderson" <anderson@firestar.com.au> wrote in news:aickhl$peh$1@digitaldaemon.com:
>
> >
> > vector operator(+) (vector a, vector b)
> > {
> > ...
> > }
>
> vector operator"+"(vector a, vector b)
> {
> }

That's an idea.

<babble> - Parhaps you can get some ideas from this

Come to think of it I remember a language (I thing VB) that put variables with spaces in square brackets like:

[go to the shops] = [go to the shops] + 1

If course you couldn't use square brackets in D, but perhaps the same symbol could be used for spaces in words as well.

perhaps


 vector _+_ (vector a, vector b)
{
}

and for functions with spaces

int _function with space_ () {}

but "_" may not stand out enough so I'd recommend something else.

Personally I'd really like it if the operator keyword could be left out all-together but I don't think that would get though the consensus.

//Perhaps
vector a+b (vector a, vector b)
{
}

and for reverse

vector b+a (vector b, vector a)
{
}

or (but then things get difficult to determine order)

vector (vector b)+(vector a)
{
}


But I'd still like it to be part of the class object as well. It probably should be a constructor come to think of it.

//Is there any need for reversing here?
this (vector b) + (vector a)
{

}

//int + vector
this (int b) + (vector a)
{

}

//vector + int
this (vector b) + (int a)
{

}

//That is simular to a global method but it's more part of the object

//However, if you have two classes with the same inputs, how do you
determine which one to use
// I'd suggest explictily telling it like when there is a problem (hopefully
rare - and in any case casting could be used):

int a;
vector b;
vector C;

vectorB new, new2;

new = a + b; //Uses vectorB method
new2 = a + vector(+) c;  //Uses vector's method

or

new = a + b; //Uses vectorB method
new2 = a + vector.+ c; //Uses vector's method

//But then you'll still have precedence problems (for example if you want to
work from backwards)
//Parhaps syntax from EBNF (Extended Backus-Naur form) - Walter should be
familiar with this,
//could be used in some way. For anyone else, it's a way of discribing
syntax like the complier does.
//Such as operator precedence and associativity. I don't have any ideas
there (yet).

On Thu, 1 Aug 2002 15:30:13 -0700 "Walter" <walter@digitalmars.com> wrote:

> Of course, you're right, but unfortunately I screwed up and allowed the cmp operator to be a member <g>.

Then, with introduction of new overloading scheme, the default version
of operator(==) and friends would just call cmp(). =)

If operator overloading makes it into D, one of the cool things in C++ is the Spirit parser generator ( spirit.sourceforge.net ) which implements quasi-EBNF in C++ using operator overloading.  So to avoid some of the problems they had, it'd be nice if there were support for postfix * and postfix +.

But there's already enough ambiguity with * to cause your head to spin.

Sean

"anderson" <anderson@firestar.com.au> wrote in message news:aid6lp$1cuc$1@digitaldaemon.com...
> //But then you'll still have precedence problems (for example if you want
to
> work from backwards)
> //Parhaps syntax from EBNF (Extended Backus-Naur form) - Walter should be
> familiar with this,
> //could be used in some way. For anyone else, it's a way of discribing
> syntax like the complier does.
> //Such as operator precedence and associativity. I don't have any ideas
> there (yet).

I was thing parhaps precedence could be done with a number.

this a+b 5(vector a, vector b); //Precidence level 5
this b+a 5(vector a, vector b); //Precidence level 5 (reverse)
this z*x 4(vector z, vector x); //Precedence level 4

//Of course there would be a default precedence, so the numbers should only be used by the experts

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:aig81s$21jv$1@digitaldaemon.com...
> If operator overloading makes it into D, one of the cool things in C++ is the Spirit parser generator ( spirit.sourceforge.net ) which implements quasi-EBNF in C++ using operator overloading.  So to avoid some of the problems they had, it'd be nice if there were support for postfix * and postfix +.
>
> But there's already enough ambiguity with * to cause your head to spin.
>
> Sean

That also. Except, parhaps that could not be done on the operator level parhaps something like

= prefix(+ X Y)
= postfix(X Y -)

> "anderson" <anderson@firestar.com.au> wrote in message news:aid6lp$1cuc$1@digitaldaemon.com...
> > //But then you'll still have precedence problems (for example if you
want
> to
> > work from backwards)
> > //Parhaps syntax from EBNF (Extended Backus-Naur form) - Walter should
be
> > familiar with this,
> > //could be used in some way. For anyone else, it's a way of discribing
> > syntax like the complier does.
> > //Such as operator precedence and associativity. I don't have any ideas
> > there (yet).
>
>
>
>

On Sat, 3 Aug 2002 20:49:30 +0800 "anderson" <anderson@firestar.com.au> wrote:

> I was thing parhaps precedence could be done with a number.
> 
> this a+b 5(vector a, vector b); //Precidence level 5
> this b+a 5(vector a, vector b); //Precidence level 5 (reverse)
> this z*x 4(vector z, vector x); //Precedence level 4
> 
> //Of course there would be a default precedence, so the numbers should only be used by the experts

I think that user-defined operator precedence is just too complex, and mostly unused feature. Does it really worth Walter's time to spend to implement it?