January 25, 2005
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 &gte; b   // HTML entity version

Identity
  a == b      // ASCII version
  a ≡ b       // Unicode version
  a &equiv; b // HTML entity version

Assignment - single version
  a :- b     // ASCII version
  a ← b      // Unicode version (left arrow - single)
  a &larr; b // HTML entity version

Assignment - double version
  a := b     // ASCII version
  a ⇐ b      // Unicode version (left arrow - double)
  a &lArr; 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
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
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
(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 &gte; b   // HTML entity version
> 
> Identity
>   a == b      // ASCII version
>   a ≡ b       // Unicode version
>   a &equiv; b // HTML entity version
> 
> Assignment - single version
>   a :- b     // ASCII version
>   a ← b      // Unicode version (left arrow - single)
>   a &larr; b // HTML entity version
> 
> Assignment - double version
>   a := b     // ASCII version
>   a ⇐ b      // Unicode version (left arrow - double)
>   a &lArr; 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
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.
1 2 3 4 5 6 7 8
Next ›   Last »