I've been thinking of how we could easily (with an operator) compare
strings.

As Walter pointed out, == is problematic because you might want to compare the address of the arrays or you might want to compare the values in them.  Even if we came up with an elegant balance for that, what happens if you want to compare arrays of arrays?  Or what if you want to compare arrays of non-char types?

char a[][];
char b[][];
....
if( /* the array of strings in a */
    /* is the same as */
    /* the array of strings in b */ )

I just thought of a new operator: the array value comparison
operator,    *= =.  The idea is to imply a "dereferencing compare."  It
is only valid between two arrays of the same type, and it returns true
if and only if they are the same length and contain idential elements.
For multidimensional arrays, you could use as many leading stars as
needed:

char a[];
char b[];
char x[][];
char y[][];

if( a == b )
    // if a and b are the exact same array in memory
if( a *== b )
    // if a and b are equivalent strings
if( x == y )
    // if x and y are the exact same array
if( x *== y )
    // if x and y are the same length, and for all  i<x.length,   x[i]
== y[i].
    // that is, x and y are different arrays, but all their elements
point to
    // exactly the same arrays in memory
if( x **== y )
    // if x and y are the same length, and for all i<x.legth,   x[i]
*==  y[i].
    // that is, x and y are different arrays, and all of their elements
might
    // point to different strings, but the strings are equivalent.

This could go on to ***== and so on.  No need to put an arbitrary limitation on it.

Of course, you would also implement matching routines for the other
comparators:
*!=
*<
*>
*<=
*>=
**!=
**<
and so on.

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3C281D5C.1E8E1C1B@deming-os.org...

> I just thought of a new operator: the array value comparison
> operator,    *= =.  The idea is to imply a "dereferencing compare."  It
> is only valid between two arrays of the same type, and it returns true
> if and only if they are the same length and contain idential elements.

Why not use the "array contents" operator for this?

    if (a == b) ...        // compare pointers
    if (a[] == b[]) ...    // compare arrays

Pavel Minayev wrote:

> Why not use the "array contents" operator for this?
>
>     if (a == b) ...        // compare pointers
>     if (a[] == b[]) ...    // compare arrays

Might work...

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a09eq6$1vrn$1@digitaldaemon.com...
> "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3C281D5C.1E8E1C1B@deming-os.org...
> > I just thought of a new operator: the array value comparison
> > operator,    *= =.  The idea is to imply a "dereferencing compare."  It
> > is only valid between two arrays of the same type, and it returns true
> > if and only if they are the same length and contain idential elements.
> Why not use the "array contents" operator for this?
>     if (a == b) ...        // compare pointers
>     if (a[] == b[]) ...    // compare arrays

I thought of that, but unfortunately then the slicing operator becomes semantically ambiguous. The only way the contents operator works is by it having special meaning *only* when used as an lvalue. Sigh.

"Walter" <walter@digitalmars.com> wrote in message news:a0btal$c56$1@digitaldaemon.com...

> I thought of that, but unfortunately then the slicing operator becomes semantically ambiguous. The only way the contents operator works is by it having special meaning *only* when used as an lvalue. Sigh.

Hmmm... I can't understand what you mean. Could you please post an example of such ambiguity?

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a0cbf7$ljq$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:a0btal$c56$1@digitaldaemon.com...
> > I thought of that, but unfortunately then the slicing operator becomes semantically ambiguous. The only way the contents operator works is by
it
> > having special meaning *only* when used as an lvalue. Sigh.
> Hmmm... I can't understand what you mean. Could you please post an example of such ambiguity?


a[] is a synonym for a[0..a.length]. If I write:
    foo[3..5]
do I mean the array, or the contents of the array? If the latter, then much
of the uses of slicing are obviated. If the former, then I can't assign a
special meaning to [].

"Walter" <walter@digitalmars.com> wrote in message news:a0d1va$13o1$2@digitaldaemon.com...

> do I mean the array, or the contents of the array? If the latter, then
much
> of the uses of slicing are obviated. If the former, then I can't assign a special meaning to [].

Whichever the case, what's the problem? Comparison operators don't modify their operands, so whether slice is part of array or a brand new one doesn't matter, right? In fact D already defines == and friends on arrays and slices (AFAIK) so it is legal to write:

    if (a[] == b[]) ...

But it is only legal if both arrays are of the same size. Making it work on differently sized arrays would give us pretty much everything we need.

Walter wrote:


> a[] is a synonym for a[0..a.length]. If I write:
>     foo[3..5]
> do I mean the array, or the contents of the array? If the latter, then much
> of the uses of slicing are obviated. If the former, then I can't assign a
> special meaning to [].


Do you anticipate wanting to compare slices for reference
identity rather than for content identity? It's a little
perlesque/DWIMy, but could you treat slice syntax differently
in comparison expressions than in assignment or other
expressions?

-RB

"Russell Borogove" <kaleja@estarcion.com> wrote in message news:3C2A1913.9050303@estarcion.com...
> Walter wrote:
> > a[] is a synonym for a[0..a.length]. If I write:
> >     foo[3..5]
> > do I mean the array, or the contents of the array? If the latter, then
much
> > of the uses of slicing are obviated. If the former, then I can't assign
a
> > special meaning to [].
> Do you anticipate wanting to compare slices for reference identity rather than for content identity?

Yes.

> It's a little
> perlesque/DWIMy, but could you treat slice syntax differently
> in comparison expressions than in assignment or other
> expressions?

Each special case adds complexity, that doesn't mean it is not worth doing, the case just has to be fairly compelling.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a0d2h6$142m$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:a0d1va$13o1$2@digitaldaemon.com...
>
> > do I mean the array, or the contents of the array? If the latter, then
> much
> > of the uses of slicing are obviated. If the former, then I can't assign
a
> > special meaning to [].
>
> Whichever the case, what's the problem? Comparison operators don't modify their operands, so whether slice is part of array or a brand new one doesn't matter, right? In fact D already defines == and friends on arrays and slices (AFAIK) so it is legal to write:
>
>     if (a[] == b[]) ...
>
> But it is only legal if both arrays are of the same size. Making it work on differently sized arrays would give us pretty much everything we need.

I'm going to have to revisit the a[] op b[] syntax, as I don't think it is going to work.