View mode: basic / threaded / horizontal-split · Log in · Help
August 01, 2002
Re: new properties for dynamic arrays
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
August 01, 2002
Re: new properties for dynamic arrays
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
>
>
>
August 02, 2002
Re: new properties for dynamic arrays
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)
{
...
}
August 02, 2002
Re: Accessing the others members
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)
>
>
August 02, 2002
Re: new properties for dynamic arrays
"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)
{
}
August 02, 2002
Re: new idea (bad idea?)
"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).
August 02, 2002
Re: new properties for dynamic arrays
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(). =)
August 03, 2002
Re: new idea (bad idea?)
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).
August 03, 2002
Re: new idea (bad idea?)
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).
>
>
>
>
August 03, 2002
Re: new idea (bad idea?)
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?
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home