## D - Integer division.

• Ilya Minkov (31/31) Jan 21 2003 Walter, please add a new operator!
• Carlos (98/98) Jan 21 2003 Mainly because of my Basic past, I wholeheartly (sp?) support that... Ok...
• Russell Lewis (7/12) Jan 21 2003 It's a good idea, although I would say it should go the other way
• Ilya Minkov (19/36) Jan 21 2003 And how about "standard" float? In the sense of consistency, a division=...
• Sean L. Palmer (8/16) Jan 22 2003 Don't be so quick to mandate extended. Not all machines have extended (...
• Russell Lewis (3/27) Jan 23 2003 What "you get" varies based on perspective. I think that most 4th
• Ilya Minkov (9/11) Jan 21 2003 One more. D doesn't seem to have a "power of" operator. Would '**' be OK...
• Russell Lewis (6/23) Jan 23 2003 A "power of" operator would be a very good idea, but we need to stay
• Evan McClanahan (6/33) Jan 23 2003 I've always used ^ informally. ^ or ^^ would get my vote, but there
• Daniel Yokomiso (13/46) Jan 23 2003 OK?
• Sean L. Palmer (15/20) Jan 23 2003 ^ is already XOR. You could accidentally write 2^2 thinking it'll be 4,...
• Sean L. Palmer (6/13) Jan 23 2003 When applied to constants it could be computed at compile time. It shou...
• Sean L. Palmer (11/34) Jan 23 2003 ^ is also already spoken for, but ^^ would work. Unless someone wants t...
• Evan McClanahan (7/18) Jan 24 2003 right! forgot about xor... Someone mentioned ^^ could be logical xor,
• Ilya Minkov (8/11) Jan 24 2003 I'm not sure all keyboard layouts allow you to type it. Is it a part of=...
• Sean L. Palmer (12/23) Jan 24 2003 Yes, it is. Right before lowercase 'a'. It may not be on all keyboards
• Ilya Minkov (40/50) Jan 24 2003 Urrr ignorrand ammerrrikanzzzz! :>
• Ilya Minkov (5/10) Jan 27 2003 I now start to think that a tick "`" should be on every keyboard. Some
• Antti Sykari (8/9) Jan 22 2003 I'd gladly welcome "div" for integer division, and it already fits the
• Ilya Minkov (4/19) Jan 22 2003 Any sane syntax for multiple return values, which would allow
Ilya Minkov <midiclub 8ung.at> writes:
```Walter, please add a new operator!

I think '\' could make an appropriate integer division operator. '/'
should always return a result of floating-point division, even taken 2
integers as input.

me at first, but i see that it makes sense.

Look, integer division always returns a result which is *not consistent*
with floating-point division by definition, unlike addition,
subtraction, and multiplication, which generally (that is theoretically)
are. It *is* a source of bugs, even if not a major one. And '\' operator
is not taken in D, since line splicing is not there anymore.

Adding it would allow to mix integer and FP operations more freely and
in a natural manner, with no casts in the middle. And cast is always a
couple of parenthsis, or even several, always a legibility hamper for
expressions. Other languages (Wirth family) also have 3 division
operators: '/', 'div' and 'mod', which would become '/', '\', '%'
respectively.

It would make the programmer make a conscious decision, whether he wants
to preserve the FP part but change the type, or to truncate the number
and get an integer, by writing a cast or truncation around the
expression. Once he has not thought about that, he gets a compiler error
of type mismatch.

Please consider: it would in no case requiere more casts, and in most
cases less.

It would only be another consequent step in making the language more
robust. You have already decided to make keyworded casts, and got enough
incompatibility with C that something would prevent you from addding it.

It would become of even more importance, if tuples and simplified
imlicit types ever make it into the language. But then it might be too late.

Best Regards,
-i.
```
Jan 21 2003
"Carlos" <carlos8294 msn.com> writes:
```Mainly because of my Basic past, I wholeheartly (sp?) support that... Ok,
maybe that's a bit too much... ;)

"Ilya Minkov" <midiclub 8ung.at> escribió en el mensaje
news:b0k85f\$mo\$1 digitaldaemon.com...
|
| I think '\' could make an appropriate integer division operator. '/'
| should always return a result of floating-point division, even taken 2
| integers as input.
|
| You have already added a new operator for concatentation. It surprised
| me at first, but i see that it makes sense.
|
| Look, integer division always returns a result which is *not consistent*
| with floating-point division by definition, unlike addition,
| subtraction, and multiplication, which generally (that is theoretically)
| are. It *is* a source of bugs, even if not a major one. And '\' operator
| is not taken in D, since line splicing is not there anymore.
|
| Adding it would allow to mix integer and FP operations more freely and
| in a natural manner, with no casts in the middle. And cast is always a
| couple of parenthsis, or even several, always a legibility hamper for
| expressions. Other languages (Wirth family) also have 3 division
| operators: '/', 'div' and 'mod', which would become '/', '\', '%'
| respectively.
|
| It would make the programmer make a conscious decision, whether he wants
| to preserve the FP part but change the type, or to truncate the number
| and get an integer, by writing a cast or truncation around the
| expression. Once he has not thought about that, he gets a compiler error
| of type mismatch.
|
| Please consider: it would in no case requiere more casts, and in most
| cases less.
|
| It would only be another consequent step in making the language more
| robust. You have already decided to make keyworded casts, and got enough
| incompatibility with C that something would prevent you from addding it.
|
| It would become of even more importance, if tuples and simplified
| imlicit types ever make it into the language. But then it might be too
late.
|
| Best Regards,
| -i.
|

-------------------------
Carlos Santander
http://carlos3.netfirms.com/
Mainly because of my Basic past, I wholeheartly (sp?) support that... Ok,
maybe that's a bit too much... ;)

"Ilya Minkov" <midiclub 8ung.at> escribió en el mensaje
news:b0k85f\$mo\$1 digitaldaemon.com...
|
| I think '\' could make an appropriate integer division operator. '/'
| should always return a result of floating-point division, even taken 2
| integers as input.
|
| You have already added a new operator for concatentation. It surprised
| me at first, but i see that it makes sense.
|
| Look, integer division always returns a result which is *not consistent*
| with floating-point division by definition, unlike addition,
| subtraction, and multiplication, which generally (that is theoretically)
| are. It *is* a source of bugs, even if not a major one. And '\' operator
| is not taken in D, since line splicing is not there anymore.
|
| Adding it would allow to mix integer and FP operations more freely and
| in a natural manner, with no casts in the middle. And cast is always a
| couple of parenthsis, or even several, always a legibility hamper for
| expressions. Other languages (Wirth family) also have 3 division
| operators: '/', 'div' and 'mod', which would become '/', '\', '%'
| respectively.
|
| It would make the programmer make a conscious decision, whether he wants
| to preserve the FP part but change the type, or to truncate the number
| and get an integer, by writing a cast or truncation around the
| expression. Once he has not thought about that, he gets a compiler error
| of type mismatch.
|
| Please consider: it would in no case requiere more casts, and in most
| cases less.
|
| It would only be another consequent step in making the language more
| robust. You have already decided to make keyworded casts, and got enough
| incompatibility with C that something would prevent you from addding it.
|
| It would become of even more importance, if tuples and simplified
| imlicit types ever make it into the language. But then it might be too
late.
|
| Best Regards,
| -i.
|

-------------------------
Carlos Santander
http://carlos3.netfirms.com/
```
Jan 21 2003
Russell Lewis <spamhole-2001-07-16 deming-os.org> writes:
```Ilya Minkov wrote:

I think '\' could make an appropriate integer division operator. '/'
should always return a result of floating-point division, even taken 2
integers as input.

It's a good idea, although I would say it should go the other way
around.  Leave '/' for old-style C division; use '\' for auto-float
division.

Of course, I know already that some people will argue about which
floating point type the auto-cast should be to; I don't have an answer
for that.
```
Jan 21 2003
Ilya Minkov <midiclub 8ung.at> writes:
```Russell Lewis wrote:
Ilya Minkov wrote:
=20

I think '\' could make an appropriate integer division operator. '/'=20
should always return a result of floating-point division, even taken 2=

=20
integers as input.

=20
=20
It's a good idea, although I would say it should go the other way=20
around.  Leave '/' for old-style C division; use '\' for auto-float=20
division.

And how about "standard" float? In the sense of consistency, a division=20
returning FP has to be the same for either type. And I would prefer not=20
to break working FP code, where it makes no sense. Besides, inverting=20
the system breaks the whole fragile but beautiful idea of it. It=20
wouldn't prevent any bugs this way, but create new.

IMO, "integer division" is not an actual division. If you divide 2=20
apples by 4 parts, you don't get zeroes. You get halves. It also=20
corresponds to design of other languages.

BTW, can anyone think of a better operator token for integer division=20
than '\'? Maybe '\$' or '#' or '=A7' or even ' ' :>
Or maybe a composite token like '/.'? No, too confusing, but maybe=20
someone would come up with a better combination.

=20
Of course, I know already that some people will argue about which=20
floating point type the auto-cast should be to; I don't have an answer =

for that.
=20

Extended, of course, because it's the format of FP machine registers. It =

would get downcasted on the exit out of the function, or at assignment =

to a typed FP. I bet this would also be Walter's decision. All=20
well-known compilers follow this same convention.

-i.
```
Jan 21 2003
"Sean L. Palmer" <seanpalmer directvinternet.com> writes:
```"Ilya Minkov" <midiclub 8ung.at> wrote in message
news:b0kc41\$3bl\$1 digitaldaemon.com...
Of course, I know already that some people will argue about which
floating point type the auto-cast should be to; I don't have an answer
for that.

Extended, of course, because it's the format of FP machine registers. It
would get downcasted on the exit out of the function, or at assignment
to a typed FP. I bet this would also be Walter's decision. All
well-known compilers follow this same convention.

Don't be so quick to mandate extended.  Not all machines have extended (or
even double) precision.  The PS2's Vector Units, for example, only support
single precision.

It'd be nice if the compiler could look at the type of the result and use
that.  But implicit typing doesn't seem to have a strong following here.

Sean
```
Jan 22 2003
Russell Lewis <spamhole-2001-07-16 deming-os.org> writes:
```Ilya Minkov wrote:
Russell Lewis wrote:

Ilya Minkov wrote:

I think '\' could make an appropriate integer division operator. '/'
should always return a result of floating-point division, even taken
2 integers as input.

It's a good idea, although I would say it should go the other way
around.  Leave '/' for old-style C division; use '\' for auto-float
division.

And how about "standard" float? In the sense of consistency, a division
returning FP has to be the same for either type. And I would prefer not
to break working FP code, where it makes no sense. Besides, inverting
the system breaks the whole fragile but beautiful idea of it. It
wouldn't prevent any bugs this way, but create new.

IMO, "integer division" is not an actual division. If you divide 2
apples by 4 parts, you don't get zeroes. You get halves. It also
corresponds to design of other languages.

What "you get" varies based on perspective.  I think that most 4th
graders would say that 2/4 gives you 0 remainder 2...
```
Jan 23 2003
Ilya Minkov <midiclub 8ung.at> writes:
```Ilya Minkov wrote:

One more. D doesn't seem to have a "power of" operator. Would '**' be OK?

BTW, OCaml defines a set of symbols, of which operator tokens can be
constructed, to which belong /*-+<>| for example. What do you think,
overloadable operators which consist of a free combination of a certain
set of characters?

'//' would make a good integer division, if it just wasn't already a
comment!

-i.
```
Jan 21 2003
Russell Lewis <spamhole-2001-07-16 deming-os.org> writes:
```Ilya Minkov wrote:
Ilya Minkov wrote:

One more. D doesn't seem to have a "power of" operator. Would '**' be OK?

BTW, OCaml defines a set of symbols, of which operator tokens can be
constructed, to which belong /*-+<>| for example. What do you think,
overloadable operators which consist of a free combination of a certain
set of characters?

'//' would make a good integer division, if it just wasn't already a
comment!

-i.

A "power of" operator would be a very good idea, but we need to stay
away from **, IMHO.  The expression:

a ** b

would then have to be interpreted as "a to the power of b" even though
people coming from C would say that b was a pointer being dereferenced...
```
Jan 23 2003
Evan McClanahan <evan dontSPAMaltarinteractive.com> writes:
```Russell Lewis wrote:
Ilya Minkov wrote:

Ilya Minkov wrote:

One more. D doesn't seem to have a "power of" operator. Would '**' be OK?

BTW, OCaml defines a set of symbols, of which operator tokens can be
constructed, to which belong /*-+<>| for example. What do you think,
overloadable operators which consist of a free combination of a
certain set of characters?

'//' would make a good integer division, if it just wasn't already a
comment!

-i.

A "power of" operator would be a very good idea, but we need to stay
away from **, IMHO.  The expression:

a ** b

would then have to be interpreted as "a to the power of b" even though
people coming from C would say that b was a pointer being dereferenced...

I've always used ^ informally. ^ or ^^ would get my vote, but there
doesn't seem to me to be all that much reason for it, unless the
compiler can use intrinsics to speed it up a lot more than a library
function.

Evan
```
Jan 23 2003
"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
```"Evan McClanahan" <evan dontSPAMaltarinteractive.com> escreveu na mensagem
news:b0p2ab\$2p7f\$1 digitaldaemon.com...
Russell Lewis wrote:
Ilya Minkov wrote:

Ilya Minkov wrote:

One more. D doesn't seem to have a "power of" operator. Would '**' be

OK?
BTW, OCaml defines a set of symbols, of which operator tokens can be
constructed, to which belong /*-+<>| for example. What do you think,
overloadable operators which consist of a free combination of a
certain set of characters?

'//' would make a good integer division, if it just wasn't already a
comment!

-i.

A "power of" operator would be a very good idea, but we need to stay
away from **, IMHO.  The expression:

a ** b

would then have to be interpreted as "a to the power of b" even though
people coming from C would say that b was a pointer being

dereferenced...
I've always used ^ informally. ^ or ^^ would get my vote, but there
doesn't seem to me to be all that much reason for it, unless the
compiler can use intrinsics to speed it up a lot more than a library
function.

Evan

Defining a "pow" operator would be good for writing templates. Also it would
properly dispatched in templates without using type specialization tricks.
But IMO the "pow" operator should be defined for floats, so we can write "2
^ 2" and "16 ^ 0.5" without problems.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.443 / Virus Database: 248 - Release Date: 10/1/2003
```
Jan 23 2003
"Sean L. Palmer" <seanpalmer directvinternet.com> writes:
```^ is already XOR.  You could accidentally write 2^2 thinking it'll be 4, but
it'll produce 0.

2^^2 is unambiguous.

We need to be able to overload this because complex and quaternion can be
raised to powers;  they have exp and ln defined for them.  Ok, so we could
wouldn't mind having another operator or seven.  ;)  Need a few more with
higher precedence than multiply, but lower precedence than exponentiation,
so we can overload an operator for dot and cross product (aka inner and
outer product).

Sean

"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
news:b0purq\$948\$1 digitaldaemon.com...
Defining a "pow" operator would be good for writing templates. Also it

would
properly dispatched in templates without using type specialization tricks.
But IMO the "pow" operator should be defined for floats, so we can write

"2
^ 2" and "16 ^ 0.5" without problems.

```
Jan 23 2003
"Sean L. Palmer" <seanpalmer directvinternet.com> writes:
```When applied to constants it could be computed at compile time.  It should
at very least be an intrinsic, if not an actual operator.

Sean

"Evan McClanahan" <evan dontSPAMaltarinteractive.com> wrote in message
news:b0p2ab\$2p7f\$1 digitaldaemon.com...

would then have to be interpreted as "a to the power of b" even though
people coming from C would say that b was a pointer being

dereferenced...
I've always used ^ informally. ^ or ^^ would get my vote, but there
doesn't seem to me to be all that much reason for it, unless the
compiler can use intrinsics to speed it up a lot more than a library
function.

Evan

```
Jan 23 2003
"Sean L. Palmer" <seanpalmer directvinternet.com> writes:
```^ is also already spoken for, but ^^ would work.  Unless someone wants to
introduce a logical XOR, which does in fact have a certain amount of
support.

a ^^ b;   // a raised to the b'th power

Maybe back quote?

a ` b;

nah, looks wierd.  Anyone?

Sean

"Russell Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3E30085D.7090002 deming-os.org...
Ilya Minkov wrote:
Ilya Minkov wrote:

One more. D doesn't seem to have a "power of" operator. Would '**' be

OK?
BTW, OCaml defines a set of symbols, of which operator tokens can be
constructed, to which belong /*-+<>| for example. What do you think,
overloadable operators which consist of a free combination of a certain
set of characters?

'//' would make a good integer division, if it just wasn't already a
comment!

-i.

A "power of" operator would be a very good idea, but we need to stay
away from **, IMHO.  The expression:

a ** b

would then have to be interpreted as "a to the power of b" even though
people coming from C would say that b was a pointer being dereferenced...

```
Jan 23 2003
Evan McClanahan <evan dontSPAMaltarinteractive.com> writes:
```Sean L. Palmer wrote:
^ is also already spoken for, but ^^ would work.  Unless someone wants to
introduce a logical XOR, which does in fact have a certain amount of
support.

a ^^ b;   // a raised to the b'th power

Maybe back quote?

a ` b;

nah, looks wierd.  Anyone?

right!  forgot about xor...  Someone mentioned ^^ could be logical xor,
but I think that exponentiantion would be used more often for most
people than logical xor (which can be worked around with the standard
notation in any case).  I would support ^^ more readily than any of the
other notations that I can think of.

Evan
```
Jan 24 2003
Ilya Minkov <midiclub 8ung.at> writes:
```Sean L. Palmer wrote:
a ` b;
=20
nah, looks wierd.  Anyone?

I'm not sure all keyboard layouts allow you to type it. Is it a part of=20
original "one step for a man, a leap for a mankind" ASCII?

Let's take a look a the keyboard. These seem to be untaken, if i=20
remember right:

\=A7\$# :

',' and '?' are taken, but i question them.

-i.
```
Jan 24 2003
"Sean L. Palmer" <seanpalmer directvinternet.com> writes:
```"Ilya Minkov" <midiclub 8ung.at> wrote in message

news:b0rkpc\$1493\$1 digitaldaemon.com...
Sean L. Palmer wrote:
a ` b;

nah, looks wierd.  Anyone?

I'm not sure all keyboard layouts allow you to type it. Is it a part of
original "one step for a man, a leap for a mankind" ASCII?

Yes, it is.  Right before lowercase 'a'.  It may not be on all keyboards
though.

Let's take a look a the keyboard. These seem to be untaken, if i
remember right:

\§\$# :

That's a foreign keyboard.  In the US we don't have the '§' key.

',' and '?' are taken, but i question them.

Comma seems necessary.  The comma operator seems fraught with potential for
obscurity.  I never found a real legitimate use for it except during
operator overloading, you can use it to construct lists.  Which is opposite
of its natural use in the C language.  I'd rather ',' always form lists of
things, the way it does in a parameter list.

?:  is useful.  So useful in fact that one starts to wonder if we really
need that pesky longwinded 'if' keyword at all.  ;)

Sean
```
Jan 24 2003
Ilya Minkov <midiclub 8ung.at> writes:
```Sean L. Palmer wrote:
That's a foreign keyboard.  In the US we don't have the '=A7' key.

Urrr ignorrand ammerrrikanzzzz! :>
There are thousands of ways to identify me as not being american. My=20
broken language, the e-mail adress, and so on. I have never been=20
identified as not being an american by a keyboard though. One can also=20
identify me as being non-german and non-austrian and and non-finnish=20
non-noone-knows what. Although i doubt the last. But i'm pretty much=20
sure i'm european since else i'd probably love C and hate Pascal.

It's a german keyboard. All 3 of mine have mutated to german lately. A=20
look at the US keyboard has approved that it's not there. Well, who=20
wants no law, needs no paragraph sign. :>

',' and '?' are taken, but i question them.

=20
Comma seems necessary.  The comma operator seems fraught with potential=

for
obscurity.  I never found a real legitimate use for it except during
operator overloading, you can use it to construct lists.  Which is oppo=

site
of its natural use in the C language.  I'd rather ',' always form lists=

of
things, the way it does in a parameter list.

Right, parameter lists. I couldn't understand before, why the function=20
parameters are separated with ',', and struct members with ';'? Why are=20
these enclosed () and these in {}?

Why do the uses of "()" vs.  "{}" and ',' vs. ';' have to be so subtly=20
different? Here this, there that. Cook the soup after the most stupid=20
recipy.

But what is the (expession1, expression2, expression3) comma operator=20
for? I think it primarily has a value in conjunction with a=20
preprocessor, which is now gone. For reason.

The result of a comma extression is assigned to another expression, or=20
used in expressions. Why can't you write:

int param1 =3D { expression1; espression2; expression3}

This would make expressions-in-expression more legible, also allowing=20
some parenthesis to alternate:

(1+{({x+1}*2)+1}*3)

And why can't:

struct SomeStruct (
Mem1: int,
Mem2: float
)

??? puzzle!

I still catch myself at finding out that "for(,,){}" is not exactly corre=
ct.

?:  is useful.  So useful in fact that one starts to wonder if we reall=

y
need that pesky longwinded 'if' keyword at all.  ;)

Right. But Pascal feels OK without it. It contacts code in rare cases,=20
doesn't make it more readable though. And it uses up that ':' too! Grr.
```
Jan 24 2003
Ilya Minkov <midiclub tiscali.de> writes:
```Sean L. Palmer wrote:
Maybe back quote?

a ` b;

nah, looks wierd.  Anyone?

I now start to think that a tick "`" should be on every keyboard. Some
languages, notably Lisp and Tick C make use of it. But maybe it should
be kept for the same purpose as in these languages: dynamic code generation.

-i.
```
Jan 27 2003
Antti Sykari <jsykari gamma.hut.fi> writes:
```Ilya Minkov <midiclub 8ung.at> writes:

I'd gladly welcome "div" for integer division, and it already fits the
bill in Pascal.

In C99, "div" returns a div_t structure which contains the quotient
and the remainder.  Which will both be produced by most sane processor
architectures as a result of a single division anyway.  If multiple
return values were allowed, D could do the same more naturally.

-Antti
```
Jan 22 2003
Ilya Minkov <midiclub 8ung.at> writes:
```Antti Sykari wrote:
Ilya Minkov <midiclub 8ung.at> writes:

I'd gladly welcome "div" for integer division, and it already fits the
bill in Pascal.

In C99, "div" returns a div_t structure which contains the quotient

infix ?????

and the remainder.  Which will both be produced by most sane processor
architectures as a result of a single division anyway.  If multiple
return values were allowed, D could do the same more naturally.

Any sane syntax for multiple return values, which would allow
selectivity middle in the expression without driving crazy?

-Antti

```
Jan 22 2003