Sean's ideas sound quite good. I'm not sure I saw different _l and _r in there, though.

One thing I *definitely* think is important, is to avoid generic names such
as add(). At minimum it should be op_add(), and I'd prefer __add__(), or
even __op_add__().


"Walter" <walter@digitalmars.com> wrote in message news:bjjd6g$2kvk$1@digitaldaemon.com...
>
> "Daniel Yokomiso" <daniel_yokomiso@yahoo.com.br> wrote in message news:bjj5bg$2ah0$1@digitaldaemon.com...
> > "Walter" <walter@digitalmars.com> escreveu na mensagem news:bjhefn$2qdb$1@digitaldaemon.com...
> > > I'm thinking that the following operator overload functions will cover
> the
> > > territory. Have I missed anything?
> > >
> > > x = foo[y];    =>   x = foo.opIndex(y);
> > >
> > > foo[y] = x;    =>   foo.opIndexAss(y, x);
> > >
> > > foo[a .. b]     =>   foo.opSlice(a, b);
> > >
> > > And yes, I think the other operator overloads should be renamed with
an
> > "op"
> > > prefix.
> > Why not:
> > x = foo[y];    =>   x = foo.get(y);
> > foo[y] = x;    =>   foo.set(y, x);
> > foo[a .. b]    =>   foo.slice(a, b);
> > The other operator names are already nice (i.e. "add" instead of
"opAdd").
> > BTW will array operations be overloaded? Today the spec says:
>
> Hmm. I kinda was thinking "add" was just a little too generic, that it
might
> need something to say it's a magic function to the compiler. Python sets
off
> the operator overloading with a __ prefix and postfix (which I find unattractive, but it does stand out).
>
> > a[] = b[] + 3;    =>  for (int i = 0; i < a.length; i++) { a[i] = b[i] +
> > 3; }
> > But if I have a collection, will it work? I'm saying that because we'll
> need
> > to define some array-like data-structures (e.g. matrices, vector spaces)
> and
> > would be nice to have array operations (like Blitz++ has tensor
notation).
> > Perhaps an "indices" operation could be used:
> >
> >
> > a[] = b[] + 3;
> >
> > foreach (??? i; a.indices()) {a[i] = b[i] + 3; }
>
> Since [] is a slice operation, I was thinking that this could be handled with the slice operator overload (having it return a different object,
with
> its own operator overloads).
>
> > Also it would be nice if I could define more than one index, so a matrix could be written:
> >
> >
> > x = foo[i, j];        =>   x = foo.get(i, j);
> >
> > foo[i, j] = x;        =>   foo.set(i, j, x);
> >
> > foo[0 .. a, 0 .. b]   =>   foo.slice(0 .. a, 0 .. b);
>
> Sean has some ideas along this line:
>
>     x = foo[x][y];    => x = foo.get(x,y);
>
>

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bjk32t$l31$1@digitaldaemon.com...
> Sean's ideas sound quite good. I'm not sure I saw different _l and _r in there, though.

You could certainly have a different one for get than for set.  It might be nice to support [x,y] notation as well, especially for true rectangular arrays, not arrays of arrays.  But that would conflict with the comma operator.  There are already conflicts with the comma operator pretty much everywhere comma is accepted (i.e. parameter lists) so this is not the end of the world.

> One thing I *definitely* think is important, is to avoid generic names
such
> as add(). At minimum it should be op_add(), and I'd prefer __add__(), or
> even __op_add__().

I prefer the "real" names:

operator +
operator []

etc.

There is no possibility of confusion, and you're saying exactly what you want.  You want an operator overload for +=, then by god overload operator +=, not "addass".

This would leave *all* those names available for the user member namespace.

Sean

Sean L. Palmer wrote:
> "Matthew Wilson" <matthew@stlsoft.org> wrote in message
> news:bjk32t$l31$1@digitaldaemon.com...
> 
>>Sean's ideas sound quite good. I'm not sure I saw different _l and _r in
>>there, though.
> 
> 
> You could certainly have a different one for get than for set.  It might be
> nice to support [x,y] notation as well, especially for true rectangular
> arrays, not arrays of arrays.  But that would conflict with the comma
> operator.  There are already conflicts with the comma operator pretty much
> everywhere comma is accepted (i.e. parameter lists) so this is not the end
> of the world.

yes, dump the comma operator, for those that want it add "eval" if you realy need a set of expressions as an expression.
x = eval( a = x, b=c, c ); same as current `x = (a=x), (b=c), c; `
then comma is just list separator in all cases.
eval is kind of
extern(pascal order, caller clean up) T eval( ..., T rv );

> > One thing I *definitely* think is important, is to avoid generic names
> such
> > as add(). At minimum it should be op_add(), and I'd prefer __add__(), or
> > even __op_add__().
>
> I prefer the "real" names:
>
> operator +
> operator []
>
> etc.
>
> There is no possibility of confusion, and you're saying exactly what you want.  You want an operator overload for +=, then by god overload operator +=, not "addass".

Even better!

"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:bjkuks$1spu$1@digitaldaemon.com...
> I prefer the "real" names:
>
> operator +
> operator []

Unfortunately, that doesn't work for things like reverse divide.

"Matthew Wilson" <matthew@stlsoft.org> a écrit dans le message de news:bjldl8$2j4j$1@digitaldaemon.com...
> > > One thing I *definitely* think is important, is to avoid generic names
> > such
> > > as add(). At minimum it should be op_add(), and I'd prefer __add__(),
or
> > > even __op_add__().
> >
> > I prefer the "real" names:
> >
> > operator +
> > operator []
> >
> > etc.
> >
> > There is no possibility of confusion, and you're saying exactly what you want.  You want an operator overload for +=, then by god overload
operator
> > +=, not "addass".
>
> Even better!
>
>

I also prefer "real" name... as in C++ but I think that for postfix++ and
similar it should be a "postfix" modifier... and for case where we want
to make the distinction between l-value and r-value, we should also
uses a modifier.

I would like that operator[] support multiple arguments as a function
and yes we might uses the suggestion eval for an expression
that presently uses comman operator and ban it.

but if something like eval is added, I would also like that this would be possible:

if (int a = f(), a == 25)
{
}

where we could do 1 (ore more) declaration and expression before doing the test... we might uses eval and/or some other keyword

presently, in C++ the trick to declare the variable inside an expression essentially only works when we test against 0...

Walter wrote:
> "Sean L. Palmer" <palmer.sean@verizon.net> wrote in message
> news:bjkuks$1spu$1@digitaldaemon.com...
> 
>>I prefer the "real" names:
>>
>>operator +
>>operator []
> 
> 
> Unfortunately, that doesn't work for things like reverse divide.
> 
what about "operator rev_divide" etc
class Foo {
	this() {
	}

	Foo operator rev_divide ( Foo f ) { .. }
}

although I'd rather see binary ops as
static T operator op (T a, T b )
so there would be no need for sub/reverse_sub

and unary ops as
  T operator op ( [optional params] ) {..} // [] is a unary op.
where "op" is add, sub, etc

are operators `virtual` or not ?

"Walter" <walter@digitalmars.com> escreveu na mensagem news:bjjd6g$2kvk$1@digitaldaemon.com...
>
> "Daniel Yokomiso" <daniel_yokomiso@yahoo.com.br> wrote in message news:bjj5bg$2ah0$1@digitaldaemon.com...

[snip]

> > The other operator names are already nice (i.e. "add" instead of
"opAdd").
> > BTW will array operations be overloaded? Today the spec says:
>
> Hmm. I kinda was thinking "add" was just a little too generic, that it
might
> need something to say it's a magic function to the compiler. Python sets
off
> the operator overloading with a __ prefix and postfix (which I find unattractive, but it does stand out).

So will you change "eq" and "cmp" too? If we're going to change them, it's better to change them all.


> > a[] = b[] + 3;    =>  for (int i = 0; i < a.length; i++) { a[i] = b[i] +
> > 3; }
> > But if I have a collection, will it work? I'm saying that because we'll
> need
> > to define some array-like data-structures (e.g. matrices, vector spaces)
> and
> > would be nice to have array operations (like Blitz++ has tensor
notation).
> > Perhaps an "indices" operation could be used:
> >
> >
> > a[] = b[] + 3;
> >
> > foreach (??? i; a.indices()) {a[i] = b[i] + 3; }
>
> Since [] is a slice operation, I was thinking that this could be handled with the slice operator overload (having it return a different object,
with
> its own operator overloads).

If it's the way it would be nice to create a stride function too:


a[1,3,5,7] = 0; // zeroes only the first four odd positions.


Strides are nice to certain kinds of operations. Returning an intermediate object wouldn't bloat the code? The advantage of Blitz++ is that you don't have intermediate objects automagically appearing everywhere.


> > Also it would be nice if I could define more than one index, so a matrix could be written:
> >
> >
> > x = foo[i, j];        =>   x = foo.get(i, j);
> >
> > foo[i, j] = x;        =>   foo.set(i, j, x);
> >
> > foo[0 .. a, 0 .. b]   =>   foo.slice(0 .. a, 0 .. b);
>
> Sean has some ideas along this line:
>
>     x = foo[x][y];    => x = foo.get(x,y);

Won't this mean "foo.get(x).get(y)"? How will the compiler deal with vectors
of vector: "vec[x][y]" will be "vec.get(x,y)" or "vec.get(x).get(y)". Also
doesn't it make "(foo[x])[y]" an unexpected error?

    Best regards,
    Daniel Yokomiso.

"When I'm working on a problem, I never think about beauty. I think only how
to solve the problem. But when I have finished, if the solution is not
beautiful, I know it is wrong."
- Buckminster Fuller


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.514 / Virus Database: 312 - Release Date: 28/8/2003

Mike Wynn wrote:

> yes, dump the comma operator, for those that want it add "eval" if you realy need a set of expressions as an expression.
> x = eval( a = x, b=c, c ); same as current `x = (a=x), (b=c), c; `
> then comma is just list separator in all cases.
> eval is kind of
> extern(pascal order, caller clean up) T eval( ..., T rv );

With a recursive descend parser it shouldn't matter that something conflicts with a comma operator, as long as you don't need to expect comma operator in the same context.

However, i think dunping the operator and providing a named variant for it is a good idea! However, as it cannot be overloaded, i can hardly figure out any use for it at all...

-eye

"Mike Wynn" <mike@l8night.co.uk> wrote in message news:bjljc1$2rdb$1@digitaldaemon.com...
> are operators `virtual` or not ?

They're just like other functions, i.e. virtual.