"Pavel Minayev" <evilone@omen.ru> writes:

> Perl maybe?
> 
>     if (a eq b) ...
>     if (a !eq b) ...

Gosh, why not this:

    if (a .EQ. b) ...
    if (a .NE. b) ...


:=|

<la7y6nvo@shamko.com> wrote in message news:s7citam5pgo.fsf@michael.shamko.com...

> Gosh, why not this:
>
>     if (a .EQ. b) ...
>     if (a .NE. b) ...

1) too long
2) all keywords should be lowercase

"Pavel Minayev" <evilone@omen.ru> writes:

> <la7y6nvo@shamko.com> wrote in message news:s7citam5pgo.fsf@michael.shamko.com...
> 
> > Gosh, why not this:
> >
> >     if (a .EQ. b) ...
> >     if (a .NE. b) ...
> 
> 1) too long
> 2) all keywords should be lowercase

Sorry...  I guess the meaning of the :=| emoticon didn't get through.

It wasn't a serious suggestion.  My point was, using operators used by Perl doesn't seem any better to me than using operators used by FORTRAN.  Cribbing features used in other, dissimilar languages seems like a bad idea in general.

<la7y6nvo@shamko.com> wrote in message news:s7cd70t6anm.fsf@michael.shamko.com...

> It wasn't a serious suggestion.  My point was, using operators used by Perl doesn't seem any better to me than using operators used by FORTRAN.  Cribbing features used in other, dissimilar languages seems like a bad idea in general.

The problem is, there is nothing even close in C/C++. So
we have to invent it or steal from somebody.

"Pavel Minayev" <evilone@omen.ru> writes:

> <la7y6nvo@shamko.com> wrote in message news:s7cd70t6anm.fsf@michael.shamko.com...
> 
> > It wasn't a serious suggestion.  My point was, using operators used by Perl doesn't seem any better to me than using operators used by FORTRAN.  Cribbing features used in other, dissimilar languages seems like a bad idea in general.
> 
> The problem is, there is nothing even close in C/C++. So
> we have to invent it or steal from somebody.

Quote from Butler Lampson:

    "We already have a way to extend programming languages.
     It's called 'procedures'.  They work great!"

I see no reason to have special purpose operators solely for string comparison, especially since the semantics of such operations is not a settled question (should they be case sensitive or not, for example?).

Now, if you want to talk about generalizing the language so that the regular comparison operators can be used for user defined datatypes, that's a different topic entirely.

<la7y6nvo@shamko.com> wrote in message news:s7c666l696j.fsf@michael.shamko.com...
> "Pavel Minayev" <evilone@omen.ru> writes:

> I see no reason to have special purpose operators solely for string comparison, especially since the semantics of such operations is not a settled question (should they be case sensitive or not, for example?).

First of all, we are not talking of string comparison here. We are talking about comparing arrays, strings are just a subset...

Second (actually, first), strings are just TOO important and
frequently used to handle them with procedures. It was so in
C, all those strcmp and strcpy, which I just hated, while most
other languages - BASIC, Pascal, and now Java - offer
convenient string handling... Then came C++, STL and std::string
(the latter is by the way the reason why I always prefer C++
over C, even when there are no other advantages). D states
itself as the "practical language", which I personally understand
as making it convenient for programmers and common-day tasks
rather than centering around some "common idea" (a major flaw
of Java IMO). It's so frequent you have to compare two strings
for equality, the language should provide a convenient way for
this. If it works on arrays of any kinds, that's even better!

Now concerning "unsettled" semantics. The answer is simple:
do it like everybody does! For example, comparison should be
case sensitive since all other languages consider this the
default. Additional case insensitive comparison operators would
be cool but not so necessary since they aren't used that often.

Russell Borogove wrote:

>...
> 
>    if (a $= b)     // "string equal" to speakers of BASIC
>    if (a []= b)    // "array equal"
>    if (a === b)    // because = and == aren't confusing enuf
> 
> -RB

This doesn't directly address the problem of basic operators (how about "=?" as a choice), but to me it feels related.

There needs to be ways to limit the number of basic operators required.  Perhaps it's time to think again about making string a class (or at least having a String class that can be used as if "anything" were an instance of it.  That way the needed operations could be defined.  The problem is that there needs to be a way to allow the class to be extended differently by different people.  So someone would be able to define it such that:
"able was I ere I saw elba".capitalize.split_at("Ere") == "Able Was I"
even though capitalize was not a method defined for string by the language+libs.

Note that the problem here is that the method is being invoked off of the constant string.  A cast could be used to solve this, but such an approach is cumbersome.  Ditto for the creation of a temporary object.  So perhaps what is needed is the ability to declare an object that is a parent of a defined class?  A descendant doesn't solve this problem. Of course what is really being requested is the ability to extend an existing class that has been compiled, and (perhaps) is only available in binary. The exact details aren't too important to the solution of the problem (Python, Ruby, Sather, Smalltalk, etc. each solve this problem, but they use different ways to solve it).  But solving it in a compiled language may be more difficult.  (C, C++, Eiffel, and Java don't seem to have any solution.)

But one of the things that I frequently find myself wanting to do is define methods (and operators) on String that don't exist in the pre-defined system classes.  Presumably similar problems exist for other people, possibly with respect to different classes.  (Do you need to define a new operation on Complex numbers?)  But the case for String is particularly clear, because the language comes with significant support for string constants.  If one already had to write String('a', 'b', 'l', 'e', ' ', ... 'E', 'l', 'b', 'a') then the additional effort used in typeing MyString instead of String would be insignificant.

"Charles Hixson" <charleshixsn@earthlink.net> wrote in message news:3C33630F.4010005@earthlink.net...

> required.  Perhaps it's time to think again about making string a class (or at least having a String class that can be used as if "anything" were an instance of it.  That way the needed operations could be defined.  The problem is that there needs to

Don't forget that D doesn't support operator overloading. So be string a class, it would be a method cmp() rather than function, and no other differences.

Charles Hixson wrote:

> "able was I ere I saw elba".capitalize.split_at("Ere") == "Able
> Was I"

You can already implement such things in D, if you just declare global functions instead of requiring member functions:

char[] Capitalize(char[]);
char[] SplitAt(char[],char[]);
...
if(SplitAt(Capitalize("able was I ere I saw elba"),"Ere") == "Able Was
I")
    ...

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

It'd be really handy to be able to decorate an existing class with extra (non-virtual) member functions.  Access would probably be restricted to public interface.

It'd really be syntactic sugar for global functions to masquerade themselves as member functions of some other class.  But sometimes you just want everything to be consistent from the user's point of view.

Maybe operator overloading could be done this way as well.  You could declare the operators (in terms of other normal member functions) at the scope in which they will be used.  Then nobody else has to deal with them.

Sean

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3C342D92.39417435@deming-os.org...
> Charles Hixson wrote:
>
> > "able was I ere I saw elba".capitalize.split_at("Ere") == "Able
> > Was I"
>
> You can already implement such things in D, if you just declare global functions instead of requiring member functions:
>
> char[] Capitalize(char[]);
> char[] SplitAt(char[],char[]);
> ...
> if(SplitAt(Capitalize("able was I ere I saw elba"),"Ere") == "Able Was
> I")
>     ...