antonio wrote:
> Kristian Kilpi wrote:
>> On Thu, 16 Nov 2006 13:46:08 +0200, Mariano <rotoshi@yahoo.com> wrote:
>>
>>> == Quote from Stewart Gordon (smjg_1998@yahoo.com)'s article
>>>> Hasan Aljudy wrote:
>>>> > Mariano wrote:
>>>> <snip>
>>>> >> but the implication makes it far more clear for common day speach
>>>> >>
>>>> >>   if( check_boundaries -> a.length <= max_int )
>>>> >>       process(a);
>>>> >>
>>>> >> makes more sence than
>>>> >>
>>>> >>   if( !check_boundaries || a.length <= max_int )
>>>> >>       process(a);
>>>> </snip>
>>>> What this notation is saying is: If check_boundaries is true, then we
>>>> need to check whether a.length <= max_int - otherwise we needn't bother.
>>>> But still, it isn't exactly the clearest notation.
>>> Yes, it was just an example out of the blue. I think it is clearer, and I can't think of a better way.
>>>
>>>> <snip>
>>>> > Yea, it's easy, sure .. but -> has another totally different 
>>>> meaning in
>>>> > C++. Not that I care about C++ anymore, but D, being a C-family
>>>> > language, IMHO, shouldn't do this.
>>>> <snip>
>>>
>>> The notation was just a suggestion. I would prefer =>, but it might be confused with >=. Other options are
>>> ==>, -->, and since we have UTF-8 support, why not &#8594; or &#8658;!
>>>
>>> I understand most people don't have the notion of 'implicance' so fresh in their heads as with other logical
>>> operators, but I believe this is a consecuence of the imposed operators by languages. Having an extra logical
>>> operator would give an edge for the programmer used to it, and won't hurt the one who doesn't whant to use it.
>>>
>>> What's more, this operator is far more coherent with the behaviour of not revising the second condition if not
>>> needed.
>>>
>>> Who knows, if implemented, it might even become widely used one day.
>>>
>>> Mariano.
>>
>> I haven't used implication anywhere; I'm not 'able' to think x implies y.. But that's probably because there is no implication operator.
>>
>> Now when I think about it, I have to say that 'x implies y' is a lot easier to understand than '!x || y'.
>>
>> I cannot say how much I would use it, if there was one. (I'm still not used to such an operator.)
> 
> The most common example is the null check...
> 
> if( a!=null && a[5]==2 ) {
> }
> 
> we assume "&&" operator is optimized and evaluates left to right... but it's really "dirty" because we use a compiler optimization as a logic functionality.
> 
> for this example, I really will prefer to write
> 
> if( a!=null -> a[5]==2 ) {
> }
> 
> that uses left to right optimized evaluation, but it's more "clean"
> 
> following this, why not
> 
> if( a[5]==2 <- a!=null ) {
> }
> 
> ( "<-" optimized evaluation is right to left )
> 
> 
> 
> One question about && and || optimization:
> 
> Is there some way to specify that I need to evaluate the 2 sides of the comparer?
> 
> (something like &&& or ||| )
> 
> note:  "if( And( left() , right() ) )" or similar is not a solution :-)
> 
> Thanks
> 
> 
> 
> 
SORRY...

"a!=null -> a[5]==2"

is not the same than

"a!=null && a[5]==2"...

my fault :-(

Does that mean this isn't an option either?

int r = right();
if (left() && r)
   ...

-[Unknown]



> One question about && and || optimization:
> 
> Is there some way to specify that I need to evaluate the 2 sides of the comparer?
> 
> (something like &&& or ||| )
> 
> note:  "if( And( left() , right() ) )" or similar is not a solution :-)
> 
> Thanks
> 
> 
> 
> 

Mariano wrote:

> The notation was just a suggestion. I would prefer =>, but it might be confused with >=. Other options are
> ==>, -->, and since we have UTF-8 support, why not → or ⇒!

We don't have Unicode *operator* "support" in D, they must all be ASCII (and they can only have one name each, so you can't have both at once)

It has been suggested before for other operators, and always ignored:
http://www.prowiki.org/wiki4d/wiki.cgi?FeatureRequestList/UnicodeOperators

I don't think it has any technical reasons, just a matter of preference.
(using non-ascii for variables and functions doesn't always work either)


It should probably be in the D FAQ:

Q: Can we have unicode operators ?
A: No, you can't. US-ASCII only.

We need a list of "features rejected"...

--anders

PS.
Yes, I know that the spec says that all Universal Alphas are allowed
for identifiers. Let's just say that it doesn't *always* work, since
the assembler does choke on the names in some implementations of D...
(but I write my own code with ASCII identifiers and English comments)

> One question about && and || optimization:
> 
> Is there some way to specify that I need to evaluate the 2 sides of the comparer?
> 
> (something like &&& or ||| )
> 
> note:  "if( And( left() , right() ) )" or similar is not a solution :-)

& and | should do the trick :)

xs0

== Quote from antonio (antonio@abrevia.net)'s article
> Kristian Kilpi wrote:
> > Now when I think about it, I have to say that 'x implies y' is a lot easier to understand than '!x || y'.

Yeap, it only takes a minute or two to get use to it.

> antonio wrote:
> The most common example is the null check...

Yes, both -> and <- could be used.

For instances, in order to decide weather to show an error or not regarding its level and the user-option of showing mild errors or not, we could decide to write it one way or the other considering which on is ''cheaper'' to do first.

if( hideMildErrors -> GetErrorLevelFromFarAway() > 3 ) writefln(err);

and

if( error.level>3 <- readLongConfigFile("hideMildErrors") ) writefln(err);

Of course, all this could be again used with only ! and || (or &&).

I see only answers regarding the notation instead of the matter of having such operator or not. As I said, there are several ways to write it, be it ->, --> or ==>, none of which represent any comflict with the lexic of current version of the language.

Mariano.

== Quote from xs0 (xs0@xs0.com)'s article
> > One question about && and || optimization:
> >
> > Is there some way to specify that I need to evaluate the 2 sides of the comparer?
> >
> > (something like &&& or ||| )
> >
> > note:  "if( And( left() , right() ) )" or similar is not a solution :-)
> & and | should do the trick :)
> xs0

Well, the '&' doesn't always work, considering the ambibalence between integers and booleans. For instance:

cmp(a,b) & cmp(b,c)

will be considered false even if the 3 strings are different, if they return values (for example) 1 and 2; 1 & 2 is 0
(01 & 10). Same thing with XOR. Nevertheless, the OR would work, and you could use !(!a | !b) instead if &.

Mariano.

Mariano wrote:
> == Quote from antonio (antonio@abrevia.net)'s article
> 
>>Kristian Kilpi wrote:
>>
>>>Now when I think about it, I have to say that 'x implies y' is a lot
>>>easier to understand than '!x || y'.
> 
> Yeap, it only takes a minute or two to get use to it.
> 
>>antonio wrote:
>>The most common example is the null check...
> 
> Yes, both -> and <- could be used.

Implication is no harder to implement in software than bitwise and logic operators, which have been around from the start of computing languages. Likewise, they have been implemented in hardware right from the start.

Computers have existed for the last half century. New architectures and new programming languages have been under development, by the best of minds, every single day of this time.

Now, since implication is not a genuine part of any significant programming language, or any well-known processor architecture, doesn't that make you wonder?

Mariano wrote:
> == Quote from xs0 (xs0@xs0.com)'s article
>>> One question about && and || optimization:
>>>
>>> Is there some way to specify that I need to evaluate the 2 sides of the
>>> comparer?
>>>
>>> (something like &&& or ||| )
>>>
>>> note:  "if( And( left() , right() ) )" or similar is not a solution :-)
>> & and | should do the trick :)
>> xs0
> 
> Well, the '&' doesn't always work, considering the ambibalence between integers and booleans.
> For instance:
> 
> cmp(a,b) & cmp(b,c)
> 
> will be considered false even if the 3 strings are different, if they return values (for example) 1 and 2; 1 & 2 is 0
> (01 & 10). Same thing with XOR. Nevertheless, the OR would work, and you could use !(!a | !b) instead if &.

Yup. I just assumed the operands were bools in the first place..

Other workarounds include

cast(bool)a & cast(bool)b
!!a & !!b
a?b?1:0:b?0:0 // just kidding

Though, I think that if I wanted to always execute both sides, I'd put that execution outside the if expression, it makes it far more obvious what's going on.

auto a = something();
auto b = somethingElse();
if (a && b) {
   ...
}


xs0

> Yup. I just assumed the operands were bools in the first place..
> 
> Other workarounds include
> 
> cast(bool)a & cast(bool)b
> !!a & !!b
> a?b?1:0:b?0:0 // just kidding
> 
> Though, I think that if I wanted to always execute both sides, I'd put that execution outside the if expression, it makes it far more obvious what's going on.
> 
> auto a = something();
> auto b = somethingElse();
> if (a && b) {
>    ...
> }
> 
> 
> xs0

It's true:  the "correct" way is not to put "process" into "decission blocks".

But there is some cases where I prefer to do something like

   Recordset rd = new Recordset()
   Recordset rd2 = new Recordset()
   while( rd.Read() &&& rd2.Read() ) {
     doSomething( rd, rd2 );
   }
   // at this point, the number of Read()'s MUST BE the same
   // in rd and rd2


it's equivalent to:

   RecordSet rd = new RecordSet()
   RecordSet rd2 = new RecordSet()

   bool exists = rd.Read();
   bool exists2 = rd2.Read();
   while( exists && exists2 ) {
     doSomething( rd, rd2 );
     exists = rd.Read();
     exists2 = rd2.Read();
   }


Ok... you say it could be wrote as

   while( rd.Read() & rd2.Read() ) {

But & is "bit" tester, not a Logic evaluator... We are talking about a hight level programming language... we can use "invariants" "preconditions" "postconditions" and.... SURPRISSE... I have to use a "bit test" for "logic comparations"... no thanks..

Otherwhise... bit test could be "optimized" (if left side is 0, "&" allways evaluates to 0).

Sorry... I continue with my very poor english :-(.

Antonio wrote:
> 
>> Yup. I just assumed the operands were bools in the first place..
>>
>> Other workarounds include
>>
>> cast(bool)a & cast(bool)b
>> !!a & !!b
>> a?b?1:0:b?0:0 // just kidding

Actually, for the "follows" operation, isn't that the same as:

auto x = a; // evaluate a
if(x ? b : !x){
  // do something
}

It makes me wonder if the '?' could be granted a shorthand to cover this?

Something like:
  a ? b

Which would be the same as:
  a ? b : !a

Only without the redundant evaluation of a.

-- 
- EricAnderton at yahoo