January 25, 2005 Re: What is the difference between 'is' and '==='? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Anders F Björklund | Anders F Björklund wrote: > The following were suggested, as a start: > >> ≟ may be used instead of == >> ≠ may be used instead of != >> ≤ may be used instead of <= >> ≥ may be used instead of >= >> ≡ may be used instead of === >> ≢ may be used instead of !== >> ∧ may be used instead of && >> ∨ may be used instead of || Each makes sense on its own but when considered together with the current D ASCII operators the whole set seems entirely inconsistent internally. In particular having ^ and ∧ seems to be begging for trouble. Using ≟ (?=) with = works but then the ≡ should be an assignment operator or it should have a question mark to make sense. The ≠ and its triple bar version work together but would really require their non-negated versions to be their opposites which is the case for ≡ but not =. While this set is not really feasible it does show what a consistent operator set would look like: ---------------------------------------------------------------- Equivalence a = b // ASCII, Unicode and HTML version of == // only giving >=, the others should be obvious a >= b // ASCII version of >= a ≥ b // Unicode version of >= a >e; b // HTML entity version Identity a == b // ASCII version a ≡ b // Unicode version a ≡ b // HTML entity version Assignment - single version a :- b // ASCII version a ← b // Unicode version (left arrow - single) a ← b // HTML entity version Assignment - double version a := b // ASCII version a ⇐ b // Unicode version (left arrow - double) a ⇐ b // HTML entity version ---------------------------------------------------------------- The most striking thing about the operator set is that there is no negated form of equivalence or identity (or assignment for that matter!). A language with this set would require if and while to have negated versions. I think the biggest reason I do not seen this set as feasible is not the lack of negation however. What I see as a problem is a C inspired language in which (a=b) does not change a's value. |
January 25, 2005 Re: What is the difference between 'is' and '==='? | ||||
---|---|---|---|---|
| ||||
Posted in reply to parabolis | In article <ct3o55$2eiu$1@digitaldaemon.com>, parabolis says... > >agent.smith@archvillain.com wrote: > >> I've never liked this in any language, >> not just because of the two almost adjacent () (which tend >> to bury the vital "!" ), but because it's a double negative. >> 'x is null' is a negative; the 'if' is > >Would you consider if(x==0) a negative? Depending on the context, maybe. I'm talking about conceptually negative, so no matter how I try to define 'negative', it will be possible to construct a borderline example. Here's a case where (nt==0) implies something negative: int nt = count_tasks(); if (nt==0) // if nothing to do... return; // ... all done .. I wouldn't write this as !nt (even in C), because nt==0 is less confusing in the particular context. Use of !nt implies that there is no information in nt other than nt==0 or nt !=0. [BTW, this is why i think "if(boolvar==true)" and "if( boovar==false)" are seriously misguided. If you like these, then why not "if( (boolvar==false)==true)"? And "if(intvar==true)" needs no further comment.] But in general, I find that most rules about coding style have exceptions where the rule will seriously work against you if you follow it. You need to remember what the rule is for, and decide where you want to break it. Ideally, you will break the same rule in the same way throughout a body of code, so at least there's some internal consistency. For instance, I agree with Matthew that it's a bad idea to use implicit conversions to bool in the general case. Why? mainly, it can lead to misinterpretation of the intent of the code. But in the case where the expression is a pointer var, and the context is an if() test, and the pointerness of the var can be easily established by rotating your eyeballs up or down by 2 lines, and the same idiom is used consistently under these circumstances, it's pretty hard for confusion to occur. Someone who didn't know that a test could be done this way might be concerned for a while, but you can say that about a lot of language features (I once surprised someone by using a 'default:' that wasn't at the bottom of the switch). C programmers are sometimes concerned that if(ptr) won't work on machines where a null pointer isn't a zero bit pattern, when in fact it will (though this seems, somehow, like saying that cappucino machines will work on Mars). When I weigh all that against the transparency of "if(p)" vs. other forms, "if(p)" wins. You don't need to spend any time looking at it to see if it's really formed exactly the way you thought it was. To me, this is the big win with foreach(); with a for loop, there's a usual way of doing it( which is sometimes different depending on which body of code you're maintaining) and all kinds of minor variants, and in my experience, a disproportionate number of bugs are generated inside the () after 'for'. Why? because people don't look in there as carefully as they look at the code in the loop itself. Because there's a 'normal' way to do the for(), minor variations from the normal don't stand out [there's another style principle you probably won't find in a textbook: if it's unusual, it should *look* unusual]. I guess what I'm saying is that there's a real need to be able to do simple, basic, common things, in simple, clear, standard ways and to reserve more convoluted forms for the 80%-90% of lines of code which aren't so simple; because otherwise the 10%-20% of boring, obvious lines will end up contributing disproportionate numbers of bugs by not being as obvious as they seem. The 'foreach' is great, because it provides a clear, standard way of doing something very common. |
January 25, 2005 Re: What is the difference between 'is' and '==='? | ||||
---|---|---|---|---|
| ||||
Posted in reply to agent.smith | agent.smith@archvillain.com wrote: > In article <ct3o55$2eiu$1@digitaldaemon.com>, parabolis says... [there's another > style principle you probably won't find in a textbook: if it's unusual, > it should *look* unusual]. ... which is a good idea. unfortunately that also leads to the great evil known as perl.... jason |
January 27, 2005 Re: What is the difference between 'is' and '==='? | ||||
---|---|---|---|---|
| ||||
Posted in reply to parabolis | (As an ignorable contribution to an otherwise ignorable part of a thread, I'd like to state , that:)
Programming strains your carpal tunnels. The less difficult some of the most used key/character combinations are, the more time it takes for you to have to retire.
parabolis wrote:
> Anders F Björklund wrote:
>
>> The following were suggested, as a start:
>>
>>> ≟ may be used instead of ==
>>> ≠ may be used instead of !=
>>> ≤ may be used instead of <=
>>> ≥ may be used instead of >=
>>> ≡ may be used instead of ===
>>> ≢ may be used instead of !==
>>> ∧ may be used instead of &&
>>> ∨ may be used instead of ||
>
>
> Each makes sense on its own but when considered together with the current D ASCII operators the whole set seems entirely inconsistent internally. In particular having ^ and ∧ seems to be begging for trouble. Using ≟ (?=) with = works but then the ≡ should be an assignment operator or it should have a question mark to make sense. The ≠ and its triple bar version work together but would really require their non-negated versions to be their opposites which is the case for ≡ but not =.
>
> While this set is not really feasible it does show what a consistent operator set would look like:
> ----------------------------------------------------------------
> Equivalence
> a = b // ASCII, Unicode and HTML version of ==
>
> // only giving >=, the others should be obvious
> a >= b // ASCII version of >=
> a ≥ b // Unicode version of >=
> a >e; b // HTML entity version
>
> Identity
> a == b // ASCII version
> a ≡ b // Unicode version
> a ≡ b // HTML entity version
>
> Assignment - single version
> a :- b // ASCII version
> a ← b // Unicode version (left arrow - single)
> a ← b // HTML entity version
>
> Assignment - double version
> a := b // ASCII version
> a ⇐ b // Unicode version (left arrow - double)
> a ⇐ b // HTML entity version
> ----------------------------------------------------------------
>
> The most striking thing about the operator set is that there is no negated form of equivalence or identity (or assignment for that matter!). A language with this set would require if and while to have negated versions. I think the biggest reason I do not seen this set as feasible is not the lack of negation however. What I see as a problem is a C inspired language in which (a=b) does not change a's value.
|
January 27, 2005 Re: What is the difference between 'is' and '==='? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Georg Wrede | Georg Wrede wrote:
> (As an ignorable contribution to an otherwise ignorable part of a thread, I'd like to state , that:)
>
> Programming strains your carpal tunnels. The less difficult some of the most used key/character combinations are, the more time it takes for you to have to retire.
Arguably that depends on what kind of keyboard you are using...
If it's a US keyboard, sure. If not, maybe ≠ is easier than != ?
Besides, there's nothing stopping anyone from using universal
alphas for identifiers already (except they don't work on Mac)
My next variables will probably be called: α, β, γ instead.
Just because I can, like my old math teacher used to say... :-)
Or perhaps use the "logical" function naming: ⅠⅡⅢⅣⅤⅥⅦⅧⅨⅩ ?
There's no end to the confusion, ehrm, possibilities with this!
--anders
PS. But it does need a translator, for the Unicode-challenged.
Fortunately I wrote one for ISO-8859-1 -> UTF-8 already,
and writing one for UTF-8 -> US-ASCII (with \u escapes)
shouldn't be much harder. Just a pain to use, of course.
|
Copyright © 1999-2021 by the D Language Foundation