> > Existing operators have limited usefulness, even for simple vector operations where there are two types of product.  What existing two operators are you going to redefine for them?
> >

OddesE <OddesE_XYZ@hotmail.com> wrote in message news:a3mu6r$1sun$1@digitaldaemon.com...
> People keep mentioning that example (and it is a good one), but how many examples like that are there really?

Lots.  In fact most of the places where operators can be used do not conform to the standard meanings of the existing operators. Equality can be made an exception.

OdessE writes:
> Defining new
> operators might be great and it might not, but it seems strange to
> me if you could define new operators such as for square root, or
> dot product or sum (or what is that strange E called in English :) ),
> but not for very basic operations such as =, ==, +, -, * and /.

How do you intend to logically redefine the meaning of the square root function?


> To me,
> defining new operators seems like operator overloading 'on steroids'.

  Creating new operators is to operator overloading what creating new
functions are to function overloading.


OdessE writes:
> Why do you oppose overloading of simple operators but support the more powerfull 'operator overloading on steroids'?

  Because operator overloading is distinct from creating new operators.  If
there is to be one feature added, then it should be creating new operators.

 Overlaying new function onto existing operators simply clouds the meaning
of every statement in a program.

"D" <s_nudds@hotmail.com> wrote in message news:a3nn6k$2bf2$1@digitaldaemon.com...
> A new operator that I define.  Perhaps I will call it .+ or .v+ where the
v
> indicates a user defined vector operation.

I think you'll run into trouble trying to use '.' as part of your operators... since '.' is already used for member access etc.  If someone forgets a space it could cause lots of problems.

Sean

Arrrg, tokens should be whitespace delimited.

However, I'm open to optional formats.

Sean L. Palmer <spalmer@iname.com> wrote in message news:a3odsq$2lo0$1@digitaldaemon.com...
> "D" <s_nudds@hotmail.com> wrote in message news:a3nn6k$2bf2$1@digitaldaemon.com...
> > A new operator that I define.  Perhaps I will call it .+ or .v+ where
the
> v
> > indicates a user defined vector operation.
>
> I think you'll run into trouble trying to use '.' as part of your operators... since '.' is already used for member access etc.  If someone forgets a space it could cause lots of problems.
>
> Sean
>
>

"D" <s_nudds@hotmail.com> wrote in message news:a3nnm3$2bmc$1@digitaldaemon.com...
>
> > > Existing operators have limited usefulness, even for simple vector operations where there are two types of product.  What existing two operators are you going to redefine for them?
> > >
>
> OddesE <OddesE_XYZ@hotmail.com> wrote in message news:a3mu6r$1sun$1@digitaldaemon.com...
> > People keep mentioning that example (and it is a good one), but how many examples like that are there really?
>
> Lots.  In fact most of the places where operators can be used do not
conform
> to the standard meanings of the existing operators. Equality can be made
an
> exception.
>

And assignment.
And how many ways are there to define > or < ?


> OdessE writes:
> > Defining new
> > operators might be great and it might not, but it seems strange to
> > me if you could define new operators such as for square root, or
> > dot product or sum (or what is that strange E called in English :) ),
> > but not for very basic operations such as =, ==, +, -, * and /.
>
> How do you intend to logically redefine the meaning of the square root function?
>

How do you intend to logically redefine the meaning of the assignment
operator?  Your reasoning makes sense, but you keep contradicting
yourself by saying that defining new operators is not bad. I think most
people are pretty familiar with =, +, -, *, /, ==, < and >.
I doubt many of them are familiar with the hundreds of math operators
that exist today. Check out the Math operators section of a Unicode
table. And then there are ofcourse the operators that I invent myself.
Do you really think they wil make sense? How about:

Table <+- Record1;

That means adding a record to a table. I invented the operator myself, cool huh. But  string1 = string2 + string3, now *that* is a mystery!


>
> > To me,
> > defining new operators seems like operator overloading 'on steroids'.
>
>   Creating new operators is to operator overloading what creating new
> functions are to function overloading.
>

No it is not. Operators are predefined symbols, even in math. Sure, new ones are 'made' up now and then, but it is nothing to compare with normal functions!


> OdessE writes:
> > Why do you oppose overloading of simple operators but support the more powerfull 'operator overloading on steroids'?
>
>   Because operator overloading is distinct from creating new operators.
If
> there is to be one feature added, then it should be creating new
operators.
>
>  Overlaying new function onto existing operators simply clouds the meaning
> of every statement in a program.
>

string1 = string2 + string3;

Cloudy that statement heh?

string1.JGfkhgkjgh (CMyString::Ghhyhgdfgf (string2, string3));

or

string1 :*$=: string2 :*$+: string3;

Now *that* is clear. Cloudy code can be written using any of these constructs. Fire programmers who define assignment functions as JGfkhgkjgh(). Don't blame the language!


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
__________________________________________
Remove _XYZ from my address when replying by mail

> > Lots.  In fact most of the places where operators can be used do not
> conform
> > to the standard meanings of the existing operators. Equality can be made
> an
> > exception.

OddesE <OddesE_XYZ@hotmail.com> wrote in message news:a3pi39$6ls$1@digitaldaemon.com...
> And assignment.
> And how many ways are there to define > or < ?

  Yes, and assignment.  As for > and <, it is clear from the existance of ->
and >> and << that "><" could
be defined to mean a variety of things from shift to align, to point's to...

   I could see > being used to shift the bits in a bitmap to the right.
   or used to select the n th entry in a table or structure.
   or perhaps check if the object on the left side is bigger than that on
the right.
   Perhaps it would check if  the object on the left could be made smaller
by compression.
   Perhaps it will perform the compression.

   file = file > compressionfactor

   There are many possibilities..


> > How do you intend to logically redefine the meaning of the square root function?

Odesse writes:
> How do you intend to logically redefine the meaning of the assignment operator?

  I don't.  I oppose operator overloading.


Odesse writes:
> Your reasoning makes sense, but you keep contradicting
> yourself by saying that defining new operators is not bad. I think most
> people are pretty familiar with =, +, -, *, /, ==, < and >.
> I doubt many of them are familiar with the hundreds of math operators
> that exist today. Check out the Math operators section of a Unicode
> table. And then there are ofcourse the operators that I invent myself.

  We program in ASCII not unicode.  I fail to see your point.


Odesse writes:
> Do you really think they wil make sense? How about:
>
> Table <+- Record1;
>
> That means adding a record to a table. I invented the operator myself, cool huh. But  string1 = string2 + string3, now *that* is a mystery!

Strings are basic operators in D, so I presume the above syntax is supported.

As to

Table <+- Record1;

I see from the operator that it is user defined.  Since there is presumably
no operator overloading
I will construct a master table telling me the character equivalents of the
opcodes you have invented.
I will then turn to that page and see what the operator does.

In short order I will have memorized the table and the meaning of your
program will no longer be
obfuscated by operators that appear to be something they are not.


> > > To me,
> > > defining new operators seems like operator overloading 'on steroids'.
> >
> >   Creating new operators is to operator overloading what creating new
> > functions are to function overloading.

Odesse writes:
> No it is not. Operators are predefined symbols, even in math. Sure, new ones are 'made' up now and then, but it is nothing to compare with normal functions!

Yes Operators are predefined and have sanctioned meanings.  You prove my
point.
Altering the sanctioned meanings that we are all conditioned to recognize
is a disaster waiting to happen.

My analogy  stands in fact, your observation strengthens my argument.


> >   Because operator overloading is distinct from creating new operators.
> If
> > there is to be one feature added, then it should be creating new
> operators.
> >
> >  Overlaying new function onto existing operators simply clouds the
meaning
> > of every statement in a program.
> >
>
> string1 = string2 + string3;
>
> Cloudy that statement heh?
>
> string1.JGfkhgkjgh (CMyString::Ghhyhgdfgf (string2, string3));
>
> or
>
> string1 :*$=: string2 :*$+: string3;
>
> Now *that* is clear. Cloudy code can be written using any of these constructs. Fire programmers who define assignment functions as JGfkhgkjgh(). Don't blame the language!


The difference of course is that with operator overloading programmers are forced to write obscure code.

When the have the ability to create new operators, they have the option of making their code have clear meaning.

We have already seen that the assignment operator can be taken as being a
1:1 copy.
So, from your example...

   beta = alpha :$+ omega

  What do we know about this expression?

  We know that :$+ is the addition operator that adds two strings.
   Because there is no operator overloading we know that the operator is
unique.
  Hence we can conclude that alpha and omega are two string values.
  We also know that the result will be a string value
  Hence we know that beta is also a string.

  So by knowing the meaning of :$+ (which does provide reasonable visual
cues to it's intended meaning)
we can conclude everything we need to know about the expression at hand.

Odesse.  Thank you for once again proving my point.

In the past, when writing script languages and general-purpose lexers I'm often tempted to require whitespace.  Users tend to get annoyed if you do though.  I'm sure not used to putting whitespace everywhere.

Sean

"D" <s_nudds@hotmail.com> wrote in message news:a3pge4$5hq$1@digitaldaemon.com...
> Arrrg, tokens should be whitespace delimited.
>
> However, I'm open to optional formats.
>
> Sean L. Palmer <spalmer@iname.com> wrote in message news:a3odsq$2lo0$1@digitaldaemon.com...
> > "D" <s_nudds@hotmail.com> wrote in message news:a3nn6k$2bf2$1@digitaldaemon.com...
> > > A new operator that I define.  Perhaps I will call it .+ or .v+ where
> the
> > v
> > > indicates a user defined vector operation.
> >
> > I think you'll run into trouble trying to use '.' as part of your operators... since '.' is already used for member access etc.  If
someone
> > forgets a space it could cause lots of problems.
> >
> > Sean

> Odesse writes:
> > Your reasoning makes sense, but you keep contradicting
> > yourself by saying that defining new operators is not bad. I think most
> > people are pretty familiar with =, +, -, *, /, ==, < and >.
> > I doubt many of them are familiar with the hundreds of math operators
> > that exist today. Check out the Math operators section of a Unicode
> > table. And then there are ofcourse the operators that I invent myself.
>
>   We program in ASCII not unicode.  I fail to see your point.

Maybe it's time a programming *language* started supporting Unicode. Editors will follow.

Sean

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:a3r09f$27h0$1@digitaldaemon.com...

> Maybe it's time a programming *language* started supporting Unicode. Editors will follow.


The very first phase of compilation (as stated in the D specs) is that:

"The source file is checked to see if it is in ascii or wchar, and the appropriate scanner is loaded."

=)

Lets get some unicode keyboards first.
Better yet.  Scrap this unicode nonsense while there is still a chance.


Sean L. Palmer <spalmer@iname.com> wrote in message news:a3r09f$27h0$1@digitaldaemon.com...
> > Odesse writes:
> > > Your reasoning makes sense, but you keep contradicting
> > > yourself by saying that defining new operators is not bad. I think
most
> > > people are pretty familiar with =, +, -, *, /, ==, < and >.
> > > I doubt many of them are familiar with the hundreds of math operators
> > > that exist today. Check out the Math operators section of a Unicode
> > > table. And then there are ofcourse the operators that I invent myself.
> >
> >   We program in ASCII not unicode.  I fail to see your point.
>
> Maybe it's time a programming *language* started supporting Unicode. Editors will follow.
>
> Sean

"D" <s_nudds@hotmail.com> wrote in message news:a3qv4k$26uo$1@digitaldaemon.com...
>
>
> > > Lots.  In fact most of the places where operators can be used do not
> > conform
> > > to the standard meanings of the existing operators. Equality can be
made
> > an
> > > exception.
>
> OddesE <OddesE_XYZ@hotmail.com> wrote in message news:a3pi39$6ls$1@digitaldaemon.com...
> > And assignment.
> > And how many ways are there to define > or < ?
>
>   Yes, and assignment.  As for > and <, it is clear from the existance
of ->
> and >> and << that "><" could
> be defined to mean a variety of things from shift to align, to point's
to...
>
>    I could see > being used to shift the bits in a bitmap to the right.
>    or used to select the n th entry in a table or structure.
>    or perhaps check if the object on the left side is bigger than that on
> the right.
>    Perhaps it would check if  the object on the left could be made smaller
> by compression.
>    Perhaps it will perform the compression.
>
>    file = file > compressionfactor
>
>    There are many possibilities..
>
>
> > > How do you intend to logically redefine the meaning of the square root function?
>
> Odesse writes:
> > How do you intend to logically redefine the meaning of the assignment operator?
>
>   I don't.  I oppose operator overloading.
>
>
> Odesse writes:
> > Your reasoning makes sense, but you keep contradicting
> > yourself by saying that defining new operators is not bad. I think most
> > people are pretty familiar with =, +, -, *, /, ==, < and >.
> > I doubt many of them are familiar with the hundreds of math operators
> > that exist today. Check out the Math operators section of a Unicode
> > table. And then there are ofcourse the operators that I invent myself.
>
>   We program in ASCII not unicode.  I fail to see your point.
>
>
> Odesse writes:
> > Do you really think they wil make sense? How about:
> >
> > Table <+- Record1;
> >
> > That means adding a record to a table. I invented the operator myself, cool huh. But  string1 = string2 + string3, now *that* is a mystery!
>
> Strings are basic operators in D, so I presume the above syntax is supported.
>

Actually I think at the moment it is not.
Now if we could use operator overloading that wouldn't matter.
String addition through operators could (and I think should) be added
to the core language ofcourse, but is it really plausible that every
datatype
in existence that we would like to use operators on should be added
to the core language? What if we want an int256? What if we need
any mathematical datatype that operators are normally used on?
You can't include them all, so some will be left out.


> As to
>
> Table <+- Record1;
>
> I see from the operator that it is user defined.  Since there is
presumably
> no operator overloading
> I will construct a master table telling me the character equivalents of
the
> opcodes you have invented.
> I will then turn to that page and see what the operator does.
>

Just like you could do with a normal function. So what is the point?
To me the whole point of operator overloading is that you know
what operation is performed without having to consult documentation.
I don't know what <+- does. At least with a normal function I can
read it from it's name. Table.Add (Record);
These new operators are actually a step back.


> In short order I will have memorized the table and the meaning of your
> program will no longer be
> obfuscated by operators that appear to be something they are not.
>

Cool, memorizing tables for every program. Sounds practical.

>
> > > > To me,
> > > > defining new operators seems like operator overloading 'on
steroids'.
> > >
> > >   Creating new operators is to operator overloading what creating new
> > > functions are to function overloading.
>
> Odesse writes:
> > No it is not. Operators are predefined symbols, even in math. Sure, new ones are 'made' up now and then, but it is nothing to compare with normal functions!
>
> Yes Operators are predefined and have sanctioned meanings.  You prove my
> point.
> Altering the sanctioned meanings that we are all conditioned to recognize
> is a disaster waiting to happen.
>
> My analogy  stands in fact, your observation strengthens my argument.
>

No it does not. The meaning of the operation + is defined. It means adding two entities. It does not say exactly what type those entities are. Could be integers, could be floats or could be strings. With operator overloading you are *not* altering the sanctioned meaning of the operator, you are just enabling your new type, your class, to be used in that predefined operation.


>
> > >   Because operator overloading is distinct from creating new
operators.
> > If
> > > there is to be one feature added, then it should be creating new
> > operators.
> > >
> > >  Overlaying new function onto existing operators simply clouds the
> meaning
> > > of every statement in a program.
> > >
> >
> > string1 = string2 + string3;
> >
> > Cloudy that statement heh?
> >
> > string1.JGfkhgkjgh (CMyString::Ghhyhgdfgf (string2, string3));
> >
> > or
> >
> > string1 :*$=: string2 :*$+: string3;
> >
> > Now *that* is clear. Cloudy code can be written using any of these constructs. Fire programmers who define assignment functions as JGfkhgkjgh(). Don't blame the language!
>
>
> The difference of course is that with operator overloading programmers are forced to write obscure code.

No they are not.
They are enabled to allow their classes to behave in the same way as
other types. Sometimes this makes great sense and is not obscure at all.


>
> When the have the ability to create new operators, they have the option of making their code have clear meaning.
>

No they don't. They are creating new operators. They are inventing them, making them up, grabbing them from a hat. No one else but the one that invented the operator knows anything about it. How is that clearer than just saying Add() or Assign()?  If it is to save some typing, don't bother. If it is to add clarity to the language, it is not helping.


> We have already seen that the assignment operator can be taken as being a
> 1:1 copy.
> So, from your example...
>
>    beta = alpha :$+ omega
>
>   What do we know about this expression?
>

Nothing, just that it includes a really strange operator no one knows. *You* might think it is clear, but in other languages a $ generally has absolutely nothing to do with strings. +, on the other hand, is a universally known math symbol.


>   We know that :$+ is the addition operator that adds two strings.

No we don't, we would have to look that up.


>    Because there is no operator overloading we know that the operator is
> unique.
>   Hence we can conclude that alpha and omega are two string values.

We could also just look at their declaration, but hey that would be impractical, rather just memorize some operator tables...


>   We also know that the result will be a string value
>   Hence we know that beta is also a string.
>
>   So by knowing the meaning of :$+ (which does provide reasonable visual
> cues to it's intended meaning)

No it does not. I see a +, which I know, but what that : and $ mean, I just don't know, sorry.


> we can conclude everything we need to know about the expression at hand.
>

After reading a pile of documentation...



--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
__________________________________________
Remove _XYZ from my address when replying by mail