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

OddesE <OddesE_XYZ@hotmail.com> wrote in message news:a3ulb6$1s2p$1@digitaldaemon.com...
> 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?

  Clearly not.  Since all new datatypes that can be defined within the
language are aggregate.


Odesse writes::
> 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.

  Then you must use an aggregate datatype to simulate them, and only the
equality operators
would apply to them.

  For other operations new operators would need to be defined.  .+ .- .* and
./ look reasonable to me.


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

Odesse writes:
> Just like you could do with a normal function. So what is the point?

   Your statement is completely false.  Are you just being childish or are
you
as ignorant as a door?

    With your inferior concept of operator overloading, you can not simply
consult a table
to find which operation an operator is performing because with your method
the same operator
is used to perform a multitude of operations.

  When new operators are defined however, there is a 1 to 1 correspondance
between operators
and function.


Odesse writes:
> To me the whole point of operator overloading is that you know
> what operation is performed without having to consult documentation.

  And you have already admitted that you don't.   So your support for
operator
overloading is based on an irrational religious dogma rather than fact.


Odesse writes:
> I don't know what <+- does. At least with a normal function I can read it from it's name. Table.Add (Record);

True enough, but you always know exactly what the standard operators "+-*/
etc.} do.
And they constitute the vast bulk of operators used.


Odesse:
> These new operators are actually a step back.

  As new operators provide all of the functionality of the old operators,
and also
provide substantial advantage, and remove the flaws inherent in operator
overloading,
the ability to provide new operators is clearly superior.


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

Odesse writes:
> Cool, memorizing tables for every program. Sounds practical.

   Eminently more practical than having to remember the alternate meanings
of
existing operators that are overloaded.

  In fact, you lose on this point as well, for while + may be redefined to
mean
add a  script segment to the end of a *.mpg file,  I have no such
requirement.

  I could just as easily define the operator for the function to be
.addscript.

The function then transforms from

a + b               (your inferior solution)
a .addscript b  (my superior solution)



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

Odesse writes:
> No it does not. The meaning of the operation + is defined. It means adding two entities.

Unless it's applied to strings, in which case it means append the second string with the first.

Once again your argument is based on nonsense.

You are embarrasing yourself Odesse.

I suggest you lick your wounds, pick yourself up, go home and learn from
your
failure here.

"D" <s_nudds@hotmail.com> ha scritto nel messaggio news:a3tvlc$rco$1@digitaldaemon.com...
> Lets get some unicode keyboards first.

A japanese keyboard is an exapmle.

Ciao

"D" <s_nudds@hotmail.com> wrote in news:a3lhlb$rap$1@digitaldaemon.com:


> You can get the same benefits of operator overlaying by defining new operatores rather than foolishly altering the meaning of existing ones.
> 
> 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?


One of objectives of D is have many distinc compilation fases :

1. ascii vs unicode
2. lexical
3. sintax
4. semantic
5. optimization
6. code generation

The language is buid for easy implementation, and simplicity.
If we include `new operators` instead of `overloaded operators` we are
mixing two fases (3 & 4).

The sintatical fase will be very simple and semantical very #%÷µ=¦¥¬ßÃ.

For example :

What are variable and what are operators ? (compiler view)

x = y plus variable - yav - iseq rest varx;

You will see in every one of my examples, that I have prefixed new operators
with a period.
Other symbols would be just as acceptable.

If the period is used, the compiler would look at any whitespace period
nonwhitespace combination
that follows a variable or constant to be an operator label and try to match
it against the operators it has on file.

> "D" <s_nudds@hotmail.com> wrote in news:a3lhlb$rap$1@digitaldaemon.com:
>
>
> > You can get the same benefits of operator overlaying by defining new operatores rather than foolishly altering the meaning of existing ones.
> >
> > 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?


Juarez Rudsatz <juarez@correio.com> wrote in message news:Xns910FCC6F35219juarezcorreio@63.105.9.61...
> One of objectives of D is have many distinc compilation fases :
>
> 1. ascii vs unicode
> 2. lexical
> 3. sintax
> 4. semantic
> 5. optimization
> 6. code generation
>
> The language is buid for easy implementation, and simplicity.
> If we include `new operators` instead of `overloaded operators` we are
> mixing two fases (3 & 4).
>
> The sintatical fase will be very simple and semantical very #%÷µ=¦¥¬ßÃ.
>
> For example :
>
> What are variable and what are operators ? (compiler view)
>
> x = y plus variable - yav - iseq rest varx;
>
>

"D" <s_nudds@hotmail.com> wrote in message news:a3vhqj$19tc$1@digitaldaemon.com...
>
> > > Strings are basic operators in D, so I presume the above syntax is supported.
>
> OddesE <OddesE_XYZ@hotmail.com> wrote in message news:a3ulb6$1s2p$1@digitaldaemon.com...
> > 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?
>
>   Clearly not.  Since all new datatypes that can be defined within the
> language are aggregate.
>
>
> Odesse writes::
> > 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.
>
>   Then you must use an aggregate datatype to simulate them, and only the
> equality operators
> would apply to them.
>

I would like to be able to add my int256's...


>   For other operations new operators would need to be defined.  .+ .- .*
and
> ./ look reasonable to me.
>

Why the dot? Where did the colon go? Why .+ instead of :+: ?
If you can't make up your mind on this why do you presume hundreds
of programmers from different companies will all agree on it and come
up with the same solution? What if I define a int512? Use .+ and .-
as well?  Is this supposed to be possible in your solution? Where is
the advantage then?
What with vectors and strings?
I know from earlier posts you propose :$+: for strings and :V+: for
vecors, but what if I disagree? I live in the Netherlands, and the
dollar sign has absolutely nothing to do with strings in Dutch. How
am I supposed to know it signifies a string operation? I know you
will tell me I should learn English, but why if math is universal and
very clear?

>
> > > 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.
>
> Odesse writes:
> > Just like you could do with a normal function. So what is the point?
>
>    Your statement is completely false.  Are you just being childish or are
> you
> as ignorant as a door?
>

Excuse me, what is false about my statement?

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

Why can't you consult your documentation to find out what a certain
normal function does? I was hoping for a way to avoid having to rely
on documentation for so many things. I know what the plus operation
signifies, I don't have to consult any documentation for that. I learned
that years ago in math class.


>     With your inferior concept of operator overloading, you can not simply
> consult a table
> to find which operation an operator is performing because with your method
> the same operator
> is used to perform a multitude of operations.
>

Read:
With 'my' superior concept of operator overloading, you don't need to
go to all the trouble of consulting lengthy tables to find which operation
an operator is performing because with 'my' method the same operator
is used to perform the *same* operation on a multitude of operands,
just like in math, coincidentally...


>   When new operators are defined however, there is a 1 to 1 correspondance
> between operators
> and function.
>
>
> Odesse writes:
> > To me the whole point of operator overloading is that you know
> > what operation is performed without having to consult documentation.
>
>   And you have already admitted that you don't.   So your support for
> operator
> overloading is based on an irrational religious dogma rather than fact.
>

Where did I admit that?
Support such claims with facts, or don't make them.
I *do* know what the normal math operations are *supposed* to do.
+ adds entities, - subtracts them, * multiplies them...
Strange that you don't know that....


>
> Odesse writes:
> > I don't know what <+- does. At least with a normal function I can read it from it's name. Table.Add (Record);
>
> True enough, but you always know exactly what the standard operators "+-*/
> etc.} do.
> And they constitute the vast bulk of operators used.
>


"True enough, but you always know exactly what the standard operators "+-*/ etc.} do."

Mmmm....Strange...
I just spent a bunch of posts saying exactly this, and you replied to all
of them in a very inflamatory mannor saying that this was not the case.
+ could be used to add web pages to web servers?
At last we agree. It is vey clear what + should do, hence it is not
necessary and indeed undersirable to obscure its obvious meaning
with strange and arbitrary characters not normally used in operators.


>
> Odesse:
> > These new operators are actually a step back.
>
>   As new operators provide all of the functionality of the old operators,
> and also
> provide substantial advantage, and remove the flaws inherent in operator
> overloading,
> the ability to provide new operators is clearly superior.
>

They provide the technical functionality of the old operators, agreed,
but so do normal named functions, so why bother with operators at
all? Are you saying that it is worth all the fuss to be able to say
mat1 :MtxMul mat2
instead of mat1.MtxMul (mat2) ?
Where is the big advantage in that? As I am very bad in English, or
at least *might* be :), I have no idea what mul stands for...
With * I know this is the computer representation of a math
multiplicication, or "vermenigvuldiging" in Dutch, in this case
applied to two matrices.
New operators might be very useful for defining operators that
are new to the language. I would love to see a square root
operator, or an operator for powers. What I would not like to
see is all kinds of new operators defined for doing things that we
already have perfectly suitable operators for, such as addition or
multiplication. In such cases they provide the substantial
disadvantage that their meaning is not immediately clear. That
means without consulting documentation, operator tables or
doing a web search, just looking at the source code. The fact
that 10 different programmers might define all kinds of different
new operators for string addition or the same operators for
different operations just obscures the meaning of the code, making
it much *less* self-documenting.

What about  :$+:   .$+   :+$:   .+$    :$+    :+$  all defined (by
different programmers ofcourse) for adding strings? In most
languages $ has nothing to do with strings, and people from
countries with such languages might choose s or S instead of the
$ sign, immediately tripling the amount of operators for the
*same* operation to a whopping EIGHTEEN! And one
can easily imagine this number rising even further!
Or how about :+ for adding strings defined by programmers
from company A, but for adding vectors by programmers
from company B and for matrices by programmers from
company C? Where is the "substantial advantage" in that?
Are you really telling me you don't see how this might
cause confusion? Isn't the main purpose of operator
overloading to write code that closely resembles the problem
domain, thus making it easier to understand what is happening?
Or do you think that it's main purpose is saving a few characters
to type?


>
> > > 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.
> > >
>
> Odesse writes:
> > Cool, memorizing tables for every program. Sounds practical.
>
>    Eminently more practical than having to remember the alternate meanings
> of
> existing operators that are overloaded.
>

As I keep saying, the meaning of the operations does not change. * means multiplication, + addition. The overloaded operators just enable new types to be multiplied or added.


>   In fact, you lose on this point as well, for while + may be redefined to
> mean
> add a  script segment to the end of a *.mpg file,  I have no such
> requirement.
>

"True enough, but you always know exactly what the standard operators "+-*/ etc.} do."


You keep contradicting yourself don't you?


>   I could just as easily define the operator for the function to be
> .addscript.
>

Why could .addscript not be defined to do something
unexpected? Your new operators are more descriptive, granted,
but so are function names, so why bother with strange new
operators? Operator plus has a very defined meaning in math.
You can implement operator + to do a whole bunch of strange
things, but how does that proof anything? You can also implement
.addscript to do strange and unexpeced things, such as deleting
the .mpg file. Not difficult at all, so your solution does not solve
the problem you keep insisting it does.


> The function then transforms from
>
> a + b               (your inferior solution)
> a .addscript b  (my superior solution)

I wouldn't use a operator at all in this case. I would
use a.AddScript(b)  (my even more superior solution)
Do you see that it looks almost the same? And there
is no need to add any functionality to the language at
all. You are just using (long) names as operators, then
proudly suggesting that their meaning is clear because
you created a new operator. Maybe the meaning of
the operator is clear because it isn't an operator at
all, just a function name thinly disguised as an operator?


>
>
>
> > > My analogy  stands in fact, your observation strengthens my argument.
> > >
>
> Odesse writes:
> > No it does not. The meaning of the operation + is defined. It means
adding
> > two entities.
>
> Unless it's applied to strings, in which case it means append the second string with the first.
>

I wonder how you define adding two strings in any other way than
concatenating the second string of characters to the first? Are you
going to add the ASCII values? Are you really suggesting it is
difficult to understand what "Hello " + "World!" means? I am adding
two entities, strings, and I can readily conclude from my knowledge
of the math operator +, combined with my knowledge of the
data types of the operands, strings, what is going to happen.
Why would :$+: be more clear? What is the append operator
in math? Or is there none?
What about matrices? Is operator + doing something fundamentally
different when adding matrices? The operation is performed in a
different matter, but the same thing is happening, two matrices are
being *added*.
I wonder why you say in a previous post:

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

about adding strings with plus, but are now claiming that the use of
operator + with strings is ambiguous in some way.
Apart from the fact that strings are operands not operators, and that
they are not basic types in D, you seem to think or want strings to be
added (oh sorry, concatenated) with a standard operator + in this
previous post.
But now that you find out that you were wrong, and that strings
are not basic types in D, you suddenly claim that adding them
with plus would be ambiguous, that the meaning of that operation
would not be defined and that we need a new operator for it.
Do you propose we define different operators + for all basic types?
i+ for ints, f+ for floats, e+ for extended floats and $+ for strings?
Why is it okay to overload operators for built-in types but not for
new types?
D (or C/C++ for that matter) does not include strings as a basic
type, but at least with operator overloading you can add such
types to the language, with minimal bloat.


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

"D" <s_nudds@hotmail.com> schrieb im Newsbeitrag news:a3tvlc$rco$1@digitaldaemon.com...
> Lets get some unicode keyboards first.
> Better yet.  Scrap this unicode nonsense while there is still a chance.

Ihk! All those american or english bastards who do
not care that other languages do not fit in 127 chars.
;-)

What it is a s**t already with öäüß in german...

Imi

"OddesE" <OddesE_XYZ@hotmail.com> schrieb im Newsbeitrag
news:a3ulb6$1s2p$1@digitaldaemon.com...
...
> 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.

By the way: What about a big-integer built in data type for all those cryptographes in us?

(I think 256 bit are not enough)

Imi

"Immanuel Scholz" <digital-mars@kutzsche.net> wrote in message news:a66hu7$1kti$1@digitaldaemon.com...

> By the way: What about a big-integer built in data type for all those cryptographes in us?
>
> (I think 256 bit are not enough)

Just how big? I guess the bignum library would be a better solution. Of course, we don't have operator overloading yet, but it could be done with functions for now.

"Pavel Minayev" <evilone@omen.ru> schrieb im Newsbeitrag news:a66rfi$1p9o$1@digitaldaemon.com...
> "Immanuel Scholz" <digital-mars@kutzsche.net> wrote in message news:a66hu7$1kti$1@digitaldaemon.com...
>
> > By the way: What about a big-integer built in data type for all those cryptographes in us?
> >
> > (I think 256 bit are not enough)
>
> Just how big? I guess the bignum library would be a better solution. Of course, we don't have operator overloading yet, but it could be done with functions for now.

especally cryptologic functions tend to be very mathematical, so infix-Notation is a REQUIREMENT!

I think without it, I will write a preprocessor for D to define my own infix notation ;)

(This is the reason, I do not use Java for cryptology - they do not
let you overwrite operator+, and BigInteger.add(..) is too
difficult to read (when used in chains).

Imi

"Immanuel Scholz" <digital-mars@kutzsche.net> wrote in message news:a66hpd$1koj$1@digitaldaemon.com...
>
> "D" <s_nudds@hotmail.com> schrieb im Newsbeitrag news:a3tvlc$rco$1@digitaldaemon.com...
> > Lets get some unicode keyboards first.
> > Better yet.  Scrap this unicode nonsense while there is still a chance.
>
> Ihk! All those american or english bastards who do
> not care that other languages do not fit in 127 chars.
> ;-)
>
> What it is a s**t already with öäüß in german...
>
> Imi
>

LOL!
I guess D was expressing his open mind, calling Unicode
nonsense, therefore banning Japanese, Chinese, Russian,
Turkish etc. etc. etc. users to use paper and pen for ever!
:)


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