"Daniel Yokomiso" <daniel_yokomiso@yahoo.com.br> wrote in message news:bjlmcg$2vf1$1@digitaldaemon.com...
> So will you change "eq" and "cmp" too? If we're going to change them, it's better to change them all.

Yes, and you're right.

> Strides are nice to certain kinds of operations. Returning an intermediate object wouldn't bloat the code?

I don't know yet. Have to try it and see.

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

I was thinking that it could be disambiguated by looking for the existence of:

    get(int i, int j);
vs:
    get(int i);

It would take the longest one it found.

-operator
+operator
++operator
--operator
operator++
operator--
oper+ator
oper-ator
oper*ator
oper/ator
oper,ator    // I don't mind operator comma as long as you use it to build a
list or sequence
operator[]
operator[][]

Harharhar!

Sean

"Philippe Mori" <philippe_mori@hotmail.com> wrote in message news:bjlhf8$2oi4$1@digitaldaemon.com...
> 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...

This is why you make two versions, one with A on left and B on right, and one with B on left and A on right.

I think you meant reverse subtract?

This is only a PITA if the operators are constrained to be member functions. Then you gotta define one parm as "this".

Sean

"Walter" <walter@digitalmars.com> wrote in message news:bjlhbd$2odl$1@digitaldaemon.com...
>
> "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.

"Walter" <walter@digitalmars.com> ha scritto nel messaggio news:bjlhbd$2odl$1@digitaldaemon.com...
>
> "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.

How about:

operator ++
operator postfix ++   ||   postfix operator ++   || operator ++ postfix
operator -
operator reverse -   ||   reverse operator -   ||   operator - reverse
operator /
operator reverse /   ||  reverse operator /   ||   operator / reverse

Did I (as almost usual ;-) ) overlook something?

Ric

----- Original Message ----- 
From: "Walter" <walter@digitalmars.com>
Newsgroups: D
Sent: Wednesday, September 10, 2003 3:30 AM
Subject: Re: Array operator overloading
>
> "Daniel Yokomiso" <daniel_yokomiso@yahoo.com.br> wrote in message news:bjlmcg$2vf1$1@digitaldaemon.com...

[snip]

> > > 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?
>
> I was thinking that it could be disambiguated by looking for the existence of:
>
>     get(int i, int j);
> vs:
>     get(int i);
>
> It would take the longest one it found.

Hmmm, this kind of ad hoc parsing wasn't one of the things you were trying to get rid of? If we have "foo[x][y]" I'll probably want to write "bar = foo[x]; baz = bar[y];", but in this case it'll be an error, because "[]" isn't an operator, while "[][]" is. I prefer "foo[x,y]" because it's more concise and unambiguous. BTW I think it's an error to mix the syntax of true multi-dimensional arrays with ragged arrays, we should have true multi-dimensional arrays as a language feature and a ragged array is just a one-dimensional array of arrays:


int[] foo;   // one-dimensional array of ints
int[,] bar;  // bi-dimensional array of ints
int[][] baz; // one-dimensional array of one-dimensional arrays of ints

int[,,][,,,,][] qux; // guess what ;)


    If we make the syntax clearer will be easier for everyone to use it and
the semantics will be clearer (probably the code will be more amenable to
optimization).

    Best regards,
    Daniel Yokomiso.

"If at first you succeed try not to look astonished."


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

"Daniel Yokomiso" <daniel_yokomiso@yahoo.com.br> wrote in message news:bjpj65$2b1u$1@digitaldaemon.com...
> > It would take the longest one it found.
> Hmmm, this kind of ad hoc parsing wasn't one of the things you were trying to get rid of?

Yes. I don't like it either.

> If we have "foo[x][y]" I'll probably want to write "bar =
> foo[x]; baz = bar[y];", but in this case it'll be an error, because "[]"
> isn't an operator, while "[][]" is. I prefer "foo[x,y]" because it's more
> concise and unambiguous. BTW I think it's an error to mix the syntax of
true
> multi-dimensional arrays with ragged arrays, we should have true multi-dimensional arrays as a language feature and a ragged array is just
a
> one-dimensional array of arrays:
>
>
> int[] foo;   // one-dimensional array of ints
> int[,] bar;  // bi-dimensional array of ints
> int[][] baz; // one-dimensional array of one-dimensional arrays of ints
>
> int[,,][,,,,][] qux; // guess what ;)
>
>
>     If we make the syntax clearer will be easier for everyone to use it
and
> the semantics will be clearer (probably the code will be more amenable to
> optimization).

I guess I'm just so used to the C version of things. I don't know what the right answer is, I'll think about it some more.

"Riccardo De Agostini" <riccardo.de.agostini@email.it> wrote in message news:bjmsus$1kmm$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> ha scritto nel messaggio news:bjlhbd$2odl$1@digitaldaemon.com...
> > "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.
>
> How about:
>
> operator ++
> operator postfix ++   ||   postfix operator ++   || operator ++ postfix
> operator -
> operator reverse -   ||   reverse operator -   ||   operator - reverse
> operator /
> operator reverse /   ||  reverse operator /   ||   operator / reverse
>
> Did I (as almost usual ;-) ) overlook something?

That'll work, but it just doesn't look like much of an improvement :-( Anyhow, I'll think about it some more.

Walter wrote:
> "Daniel Yokomiso" <daniel_yokomiso@yahoo.com.br> wrote in message
> news:bjpj65$2b1u$1@digitaldaemon.com...
> 
>>>It would take the longest one it found.
>>
>>Hmmm, this kind of ad hoc parsing wasn't one of the things you were trying
>>to get rid of?
> 
> 
> Yes. I don't like it either.
> 
> 
>>If we have "foo[x][y]" I'll probably want to write "bar =
>>foo[x]; baz = bar[y];", but in this case it'll be an error, because "[]"
>>isn't an operator, while "[][]" is. I prefer "foo[x,y]" because it's more
>>concise and unambiguous. BTW I think it's an error to mix the syntax of
> 
> true
> 
>>multi-dimensional arrays with ragged arrays, we should have true
>>multi-dimensional arrays as a language feature and a ragged array is just
> 
> a
> 
>>one-dimensional array of arrays:
>>
>>
>>int[] foo;   // one-dimensional array of ints
>>int[,] bar;  // bi-dimensional array of ints
>>int[][] baz; // one-dimensional array of one-dimensional arrays of ints
>>
>>int[,,][,,,,][] qux; // guess what ;)
>>
>>
>>    If we make the syntax clearer will be easier for everyone to use it
> 
> and
> 
>>the semantics will be clearer (probably the code will be more amenable to
>>optimization).
> 
> 
> I guess I'm just so used to the C version of things. I don't know what the
> right answer is, I'll think about it some more.
> 

much as I like the idea of multi-dim arrays being passable, I can forsee  someone wanting to pass an N dim array
int func( int[,*] f ) { if f.dimensions = 1 .... etc }

I think if nothing more this is another reason that growable array should be a templated class, the only think D offers is "block" which can be sliced
same syntax as now just no ~=/~ operator on T[]
func( T[] f ) { ... same as now arrays are passed with their length. }

however with the operator overloading
each [] is a call to operator_index
foo[a][b] => foo.operator_index(a).operator_index(b)
foo[a,b] => foo.operator_index(a,b)
foo[a,b][c,d] => foo.operator_index(a,b).operator_index(b,c)
either disallow range or pass as a Range object
foo[a] => calls foo::operator_index( a.type )
foo[a..b] => calls foo::operator_index( Range )
or calls foo.operator_index( foo.operator_create_range(a, b) );
index then called with the return type from create_range which might be anything.

foo[a..b][d] => foo.operator_index( new range(a,b) ).operator_index(d)

ranges seem to me to be leading up the c++ path, where although you can overload x,y,z the performance penalty grows with the ease programing/flexability.
I think most uses of range are covered by just allowing one use
foo[a..b] => operator_slice( int a, int b )

I'm happy to have
class My2Obj {
	int[] operator_index( int a ) { .... }
}
My2Obj foo;
foo[a][b] => foo.operator_index(a).operator_index(b)
 which is foo.operator_index(a)[b]

template array( T ) {
	class Ar2D {
	T[] ar;
	this( int xw, int yw ) { ar = new T[xw*yw]; sw = xw; }
	int[] operator_index( int a ) {
		return ar[(a*sw)..(a*sw+sw)]
	}
	int operator_index( int a, b ) {
		return ar[a+(b*sw)]
	}
}
alias instance array(int).Ar2D myblock;

myBlock foo = new myBlock( xm, ym );
foo[y][x] now equiv to foo[x,y]
you can do foo[y]
and it behaves like
bar = new int[xm][ym];
only bar should be a true array of arrays.
that goes for
int[4][5] b; should create array of arrays not a single block

just a bit of syntactic sugar.

what about "put" ? we still need a put to do a hashtable (I like the syntax of assoc arrays, but think they should be classes not primatives)
template array( T, M ) {
	class Hashtable {
		class Entry {
			M key;
			T val;
			Entry next;
		}
	Entry[] ar;
	this() { }
	T operator_index( M a ) {
		return find_in_chain( ar[a.hashcode%ar.length], a );
	}
}

"Walter" <walter@digitalmars.com> wrote in 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.
> 
> 

I like this approach for the indexing operator.  I don't have a big opinion on the exact function names but I'm in the op_add, op_mul, op_whatever camp.

I would like to have multidimensional indexing and slicing too.  I prefer the array[x,y] syntax.  I don't think that you need to support it as a basic feature of D arrays but it would be nice to define classes that would support it.

Hi,

I don't want to disturb you, guys. But I am working a lot in Matlab and it has some nice features for arrays (I think they are the best):

-arrays are multidimensional and are indexed as a[2,4,5] (example to select an
element);
-syntax like a[:,3] will select all the third column of the matrix a;
-a[:] will concatenate all the columns of a into 1 column vector;
-a*b is standard matrix multiplication while a.*b is multiplying element by
element;
-the same stands for a^2 and a.^2;
-a[4:end] will select the elements from 4 to the end of the vector (no matter
how long);
-and more...

Only to give you an ideea.


Felix

PS Yes, Matlab is an interpreter, but all the code can be compiled in C. (eh, almost, no objects available for that).







In article <bjr184$196c$1@digitaldaemon.com>, Mike Wynn says...
>
>Walter wrote:
>> "Daniel Yokomiso" <daniel_yokomiso@yahoo.com.br> wrote in message news:bjpj65$2b1u$1@digitaldaemon.com...
>> 
>>>>It would take the longest one it found.
>>>
>>>Hmmm, this kind of ad hoc parsing wasn't one of the things you were trying to get rid of?
>> 
>> 
>> Yes. I don't like it either.
>> 
>> 
>>>If we have "foo[x][y]" I'll probably want to write "bar =
>>>foo[x]; baz = bar[y];", but in this case it'll be an error, because "[]"
>>>isn't an operator, while "[][]" is. I prefer "foo[x,y]" because it's more
>>>concise and unambiguous. BTW I think it's an error to mix the syntax of
>> 
>> true
>> 
>>>multi-dimensional arrays with ragged arrays, we should have true multi-dimensional arrays as a language feature and a ragged array is just
>> 
>> a
>> 
>>>one-dimensional array of arrays:
>>>
>>>
>>>int[] foo;   // one-dimensional array of ints
>>>int[,] bar;  // bi-dimensional array of ints
>>>int[][] baz; // one-dimensional array of one-dimensional arrays of ints
>>>
>>>int[,,][,,,,][] qux; // guess what ;)
>>>
>>>
>>>    If we make the syntax clearer will be easier for everyone to use it
>> 
>> and
>> 
>>>the semantics will be clearer (probably the code will be more amenable to
>>>optimization).
>> 
>> 
>> I guess I'm just so used to the C version of things. I don't know what the right answer is, I'll think about it some more.
>> 
>
>much as I like the idea of multi-dim arrays being passable, I can forsee
>  someone wanting to pass an N dim array
>int func( int[,*] f ) { if f.dimensions = 1 .... etc }
>
>I think if nothing more this is another reason that growable array
>should be a templated class, the only think D offers is "block" which
>can be sliced
>same syntax as now just no ~=/~ operator on T[]
>func( T[] f ) { ... same as now arrays are passed with their length. }
>
>however with the operator overloading
>each [] is a call to operator_index
>foo[a][b] => foo.operator_index(a).operator_index(b)
>foo[a,b] => foo.operator_index(a,b)
>foo[a,b][c,d] => foo.operator_index(a,b).operator_index(b,c)
>either disallow range or pass as a Range object
>foo[a] => calls foo::operator_index( a.type )
>foo[a..b] => calls foo::operator_index( Range )
>or calls foo.operator_index( foo.operator_create_range(a, b) );
>index then called with the return type from create_range which might be
>anything.
>
>foo[a..b][d] => foo.operator_index( new range(a,b) ).operator_index(d)
>
>ranges seem to me to be leading up the c++ path, where although you can
>overload x,y,z the performance penalty grows with the ease
>programing/flexability.
>I think most uses of range are covered by just allowing one use
>foo[a..b] => operator_slice( int a, int b )
>
>I'm happy to have
>class My2Obj {
>	int[] operator_index( int a ) { .... }
>}
>My2Obj foo;
>foo[a][b] => foo.operator_index(a).operator_index(b)
>  which is foo.operator_index(a)[b]
>
>template array( T ) {
>	class Ar2D {
>	T[] ar;
>	this( int xw, int yw ) { ar = new T[xw*yw]; sw = xw; }
>	int[] operator_index( int a ) {
>		return ar[(a*sw)..(a*sw+sw)]
>	}
>	int operator_index( int a, b ) {
>		return ar[a+(b*sw)]
>	}
>}
>alias instance array(int).Ar2D myblock;
>
>myBlock foo = new myBlock( xm, ym );
>foo[y][x] now equiv to foo[x,y]
>you can do foo[y]
>and it behaves like
>bar = new int[xm][ym];
>only bar should be a true array of arrays.
>that goes for
>int[4][5] b; should create array of arrays not a single block
>
>just a bit of syntactic sugar.
>
>what about "put" ? we still need a put to do a hashtable (I like the
>syntax of assoc arrays, but think they should be classes not primatives)
>template array( T, M ) {
>	class Hashtable {
>		class Entry {
>			M key;
>			T val;
>			Entry next;
>		}
>	Entry[] ar;
>	this() { }
>	T operator_index( M a ) {
>		return find_in_chain( ar[a.hashcode%ar.length], a );
>	}
>}
>
>
>
>
>
>
>
>