• Kari Salminen (28/28) Oct 08 2004 Hi,
• Stewart Gordon (5/17) Oct 08 2004 I guess so....
• Olaf (9/29) Nov 07 2004 x=>y is equivalent to !x||y:

Kari Salminen <Kari_member pathlink.com> writes:

Hi,
here are a few thoughts on an implication operator and shift operators:

- Implication operator:

I suggest an implication operator to the language (Taken straight
from the Eiffel language):

(x implies y) == (x ? y : true)

So this would be similar to the AndAnd i.e. && and OrOr i.e. ||
operators in the way that it wouldn't necessarily always evaluate
both of its parameters.

Probably implies wouldn't be the most logical choice seeing that
in D And, Xor, Or etc are not named And, Xor, Or but &, ^ and |
so maybe using => for meaning implication would suffice? (I know,
I know, probably not because it would make it more errorprone to
write => when meaning >= for an example when comparing some values).
And I also know that the implication operator would be mostly just
syntactical sugar but it would help readability if used when needed.

Does anyone have any good ideas what to name the implication-operator -
I mean what characters to choose for it in the D language, should it
ever be taken into it?

- Shift operators:

There's a point about shift operators I don't get yet, but it's
probably just me :). Please enlighten me...

We have << (left shift) and >> (signed right shift) and >>>
(unsigned right shift). Then why don't we have <<< (unsigned left shift)?

---
Kari Salminen
kaasalm NOSPAM at utu dot fi
To email me take out the spaces, NOSPAM and replace at with ' ' and dot with '.'

Stewart Gordon <smjg_1998 yahoo.com> writes:

Kari Salminen wrote:

<snip>
 Probably implies wouldn't be the most logical choice seeing that
 in D And, Xor, Or etc are not named And, Xor, Or but &, ^ and |
 so maybe using => for meaning implication would suffice? (I know,
 I know, probably not because it would make it more errorprone to
 write => when meaning >= for an example when comparing some values).
 And I also know that the implication operator would be mostly just
 syntactical sugar but it would help readability if used when needed.

I guess so....

 There's a point about shift operators I don't get yet, but it's
 probably just me :). Please enlighten me...
 
 We have << (left shift) and >> (signed right shift) and >>>
 (unsigned right shift). Then why don't we have <<< (unsigned left shift)?

Because the sign bit just falls off the end regardless.

Stewart.

"Olaf" <nobody nowhere.nowhere> writes:

"Kari Salminen" <Kari_member pathlink.com> wrote in message
news:ck69v8$1luh$1 digitaldaemon.com...
 Hi,
 here are a few thoughts on an implication operator and shift operators:

 - Implication operator:

 I suggest an implication operator to the language (Taken straight
 from the Eiffel language):

 (x implies y) == (x ? y : true)

 So this would be similar to the AndAnd i.e. && and OrOr i.e. ||
 operators in the way that it wouldn't necessarily always evaluate
 both of its parameters.

 Probably implies wouldn't be the most logical choice seeing that
 in D And, Xor, Or etc are not named And, Xor, Or but &, ^ and |
 so maybe using => for meaning implication would suffice? (I know,
 I know, probably not because it would make it more errorprone to
 write => when meaning >= for an example when comparing some values).
 And I also know that the implication operator would be mostly just
 syntactical sugar but it would help readability if used when needed.

 Does anyone have any good ideas what to name the implication-operator -
 I mean what characters to choose for it in the D language, should it
 ever be taken into it?
 <cut>

x=>y is equivalent to !x||y:
      x y x=>y !x||y
      FALSE FALSE TRUE TRUE
      FALSE TRUE TRUE TRUE
      TRUE FALSE FALSE FALSE
      TRUE TRUE TRUE TRUE

Whether that would merit an operator of its own? Dunno...