www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What is the difference between 'is' and '==='?

reply nail <nail_member pathlink.com> writes:
subj

I coldn't find this in docs.
Jan 20 2005
next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
nail wrote:
 subj
 
 I coldn't find this in docs.

AIUI none - one's just syntactic sugar for the other (whichever way you look at it). Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Jan 20 2005
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
1 character ? :-)

--anders

PS.
I still think that we need 'isnt' for '!=='
Jan 20 2005
next sibling parent reply nail <nail_member pathlink.com> writes:
PS.
I still think that we need 'isnt' for '!=='

In this case isnt must be :) What about future? Does === will become deprecated?
Jan 20 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"nail" <nail_member pathlink.com> wrote in message
news:cson1b$5f6$1 digitaldaemon.com...
PS.
I still think that we need 'isnt' for '!=='

In this case isnt must be :) What about future? Does === will become deprecated?

Yes, use "is" from now on. The === turned out to be a problem distinguishing from == with some fonts.
Jan 20 2005
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:cspa3k$v95$2 digitaldaemon.com...
 "nail" <nail_member pathlink.com> wrote in message
 news:cson1b$5f6$1 digitaldaemon.com...
PS.
I still think that we need 'isnt' for '!=='

In this case isnt must be :) What about future? Does === will become deprecated?

Yes, use "is" from now on. The === turned out to be a problem distinguishing from == with some fonts.

So're we getting an 'isnt'? if(!(x is null)) is never going to be an attractive form
Jan 21 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Matthew wrote:

     if(!(x is null))
 
 is never going to be an attractive form 

Until there are booleans in D, you can use: if(x) --anders
Jan 21 2005
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"Anders F Bjrklund" <afb algonet.se> wrote in message
news:csqnjr$2hv2$1 digitaldaemon.com...
 Matthew wrote:

     if(!(x is null))

 is never going to be an attractive form

Until there are booleans in D, you can use: if(x)

I'm afraid I never write a non-boolean conditional (sub-)expression, so you won't catch me doing that. ;)
Jan 21 2005
parent reply Georg Wrede <georg.wrede nospam.org> writes:
    if(!(x is null))

is never going to be an attractive form

Until there are booleans in D, you can use: if(x)

I'm afraid I never write a non-boolean conditional (sub-)expression, so you won't catch me doing that. ;)

IMO if(x) should be made the official form of this idiom, in D. And documented as such. Every language has its preferred idioms, and every idiom can be attacked as unobvious, dangerous, etc. But having these idioms is what makes the language more fluent and usable. The standard idioms make source code much more readable. I understand that C or C++ users may feel uncomfortable with it. Heck, in the old days nothing forced the C compiler writer to use the all-zeros bit pattern to represent the null pointer. (Anybody wanna flame check it out first.) I seem to remember that in D it is guaranteed that a null pointer is considered false in boolean contexts, but I couldn't find it now. And it seemed to be written in stone. Therefore, in D if(x) will stay valid.
Jan 24 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Georg Wrede wrote:

 IMO if(x) should be made the official form of this idiom, in D.

 I understand that C or C++ users may feel uncomfortable with it. Heck, 
 in the old days nothing forced the C compiler writer to use the 
 all-zeros bit pattern to represent the null pointer. (Anybody wanna 
 flame check it out first.)

Old-school C or C++ users feel right at home with it, since that's where it comes from. Java users do not, or people from type-fascist languages such as Ada...
 I seem to remember that in D it is guaranteed that a null pointer is 
 considered false in boolean contexts, but I couldn't find it now. And it 
 seemed to be written in stone. Therefore, in D if(x) will stay valid.

The current D specification is not very clear on this. :-( http://www.digitalmars.com/d/statement.html#if:
 Expression is evaluated and must have a type that can be converted to
 a boolean. If it's true the if statement is transferred to, else the
 else statement is transferred to.

(other parts of the specification talk about "bool") But http://www.digitalmars.com/d/expression.html:
 true, false
 These are of type bit and resolve to values 1 and 0, respectively.

But in practice, D follows the C and C++ tradition: zero and null are false and non-zero/null are true:
 void main()
 {
   assert(true);
   assert(!false);
   assert(new Object());
   assert(!null);
   assert(1);
   assert(!0);
 }

In Java, for instance, the last four are semantic errors:
 The type of this expression, "java.lang.Object", is not "boolean".
 The type of this expression, "null", is not "boolean".
 The type of this expression, "int", is not "boolean".
 The type of this expression, "int", is not "boolean".

However, in D you still cannot copy such values without a cast:
   bit a,b,c;
   Object o = new Object();
   int i = 2;
 
   a = true;
   b = o;
   c = i;

Gives errors:
 cannot implicitly convert expression o of type Object to bit
 cannot implicitly convert expression i of type int to bit

If the proper "cast(bit)" is inserted, all three are "true". Which means that "bool/boolean conversion" refers to the operation of comparing integers with 0, and pointers/references with null... This should probably be mentioned explicitly in the D specification. (probably along with "some think this automatic conversion is a bug") --anders
Jan 24 2005
parent agent.smith archvillain.com writes:
In article <ct3f7c$1s4g$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
Georg Wrede wrote:

 IMO if(x) should be made the official form of this idiom, in D.

 I understand that C or C++ users may feel uncomfortable with it. Heck, 
 in the old days nothing forced the C compiler writer to use the 
 all-zeros bit pattern to represent the null pointer. (Anybody wanna 
 flame check it out first.)

Old-school C or C++ users feel right at home with it, since that's where it comes from. Java users do not, or people from type-fascist languages such as Ada...

can use something else for null ptr, but then when a pointer appears in a boolean context, the code has to test for that pattern. Also, when you assign constant int 0 to a pointer, it has to convert to that. I.e. "p=0" would work on such a machine, but "int x=0; p=(char*)x" would not. And "p=1" is an error even if the null pattern is binary 1. Likewise, when comparing a pointer to a int constant, the int must be zero and you are really comparing to null. So all of this is handled at the semantic level. FWIW, I don't know of a machine that doesn't use 0. I did use -1 once on a DSP for a link-list endpoint, because testing the MSB of an address reg was much cheaper than comparing the whole thing to zero (and I could blow off 1/2 the address space) but that was in assembler.
Jan 24 2005
prev sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"Georg Wrede" <georg.wrede nospam.org> wrote in message
news:41F52972.4040208 nospam.org...
    if(!(x is null))

is never going to be an attractive form

Until there are booleans in D, you can use: if(x)

I'm afraid I never write a non-boolean conditional (sub-)expression, so you won't catch me doing that. ;)

IMO if(x) should be made the official form of this idiom, in D. And documented as such. Every language has its preferred idioms, and every idiom can be attacked as unobvious, dangerous, etc. But having these idioms is what makes the language more fluent and usable. The standard idioms make source code much more readable.

That's nice, and in almost all other ways I've fallen into line with the D way of things - no more whinges about boolean, using dCaseMethods, etc. etc. But there's no way I'm writing non-boolean conditional (sub-)expressions. Sorry.
 I understand that C or C++ users may feel uncomfortable with it. Heck, in the
old days nothing forced the C compiler 
 writer to use the all-zeros bit pattern to represent the null pointer.
(Anybody wanna flame check it out first.)

 I seem to remember that in D it is guaranteed that a null pointer is
considered false in boolean contexts, but I 
 couldn't find it now. And it seemed to be written in stone. Therefore, in D
if(x) will stay valid. 

Jan 24 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Tue, 25 Jan 2005 08:08:27 +1100, Matthew <admin.hat stlsoft.dot.org>  
wrote:
 "Georg Wrede" <georg.wrede nospam.org> wrote in message
 IMO if(x) should be made the official form of this idiom, in D.

 And documented as such.

 Every language has its preferred idioms, and every idiom can be  
 attacked as unobvious, dangerous, etc. But having
 these idioms is what makes the language more fluent and usable.

 The standard idioms make source code much more readable.

That's nice, and in almost all other ways I've fallen into line with the D way of things - no more whinges about boolean, using dCaseMethods, etc. etc. But there's no way I'm writing non-boolean conditional (sub-)expressions. Sorry.

Now I'm curious. Why not? Regan
Jan 24 2005
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opsk4lnexa23k2f5 ally...
 On Tue, 25 Jan 2005 08:08:27 +1100, Matthew <admin.hat stlsoft.dot.org>  wrote:
 "Georg Wrede" <georg.wrede nospam.org> wrote in message
 IMO if(x) should be made the official form of this idiom, in D.

 And documented as such.

 Every language has its preferred idioms, and every idiom can be  attacked as
unobvious, dangerous, etc. But having
 these idioms is what makes the language more fluent and usable.

 The standard idioms make source code much more readable.

That's nice, and in almost all other ways I've fallen into line with the D way of things - no more whinges about boolean, using dCaseMethods, etc. etc. But there's no way I'm writing non-boolean conditional (sub-)expressions. Sorry.

Now I'm curious. Why not?

Just experience over these long years. Explicit boolean conditional (sub-)expressions never cause problems. Implicit ones sometimes do. Therefore I adopt a habit of always doing it to avoid the occasional cases. QED
Jan 24 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Tue, 25 Jan 2005 12:56:53 +1100, Matthew <admin.hat stlsoft.dot.org>  
wrote:
 "Regan Heath" <regan netwin.co.nz> wrote in message  
 news:opsk4lnexa23k2f5 ally...
 On Tue, 25 Jan 2005 08:08:27 +1100, Matthew  
 <admin.hat stlsoft.dot.org>  wrote:
 "Georg Wrede" <georg.wrede nospam.org> wrote in message
 IMO if(x) should be made the official form of this idiom, in D.

 And documented as such.

 Every language has its preferred idioms, and every idiom can be   
 attacked as unobvious, dangerous, etc. But having
 these idioms is what makes the language more fluent and usable.

 The standard idioms make source code much more readable.

That's nice, and in almost all other ways I've fallen into line with the D way of things - no more whinges about boolean, using dCaseMethods, etc. etc. But there's no way I'm writing non-boolean conditional (sub-)expressions. Sorry.

Now I'm curious. Why not?

Just experience over these long years. Explicit boolean conditional (sub-)expressions never cause problems. Implicit ones sometimes do. Therefore I adopt a habit of always doing it to avoid the occasional cases. QED

I use them all the time.. I've never had any trouble (that I can remember), can you give me an example you've run into (I might want/need to scan my recent code for it). Regan
Jan 24 2005
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opsk4y49nq23k2f5 ally...
 On Tue, 25 Jan 2005 12:56:53 +1100, Matthew <admin.hat stlsoft.dot.org>  wrote:
 "Regan Heath" <regan netwin.co.nz> wrote in message 
news:opsk4lnexa23k2f5 ally...
 On Tue, 25 Jan 2005 08:08:27 +1100, Matthew  <admin.hat stlsoft.dot.org> 
wrote:
 "Georg Wrede" <georg.wrede nospam.org> wrote in message
 IMO if(x) should be made the official form of this idiom, in D.

 And documented as such.

 Every language has its preferred idioms, and every idiom can be   attacked as
unobvious, dangerous, etc. But 
 having
 these idioms is what makes the language more fluent and usable.

 The standard idioms make source code much more readable.

That's nice, and in almost all other ways I've fallen into line with the D way of things - no more whinges about boolean, using dCaseMethods, etc. etc. But there's no way I'm writing non-boolean conditional (sub-)expressions. Sorry.

Now I'm curious. Why not?

Just experience over these long years. Explicit boolean conditional (sub-)expressions never cause problems. Implicit ones sometimes do. Therefore I adopt a habit of always doing it to avoid the occasional cases. QED

I use them all the time.. I've never had any trouble (that I can remember), can you give me an example you've run into (I might want/need to scan my recent code for it).

Well, naturally not. Since I have been doing it this way for about 5 years, I don't have any real ones to offer up. :-)
Jan 24 2005
parent "Regan Heath" <regan netwin.co.nz> writes:
On Tue, 25 Jan 2005 15:16:46 +1100, Matthew <admin.hat stlsoft.dot.org>  
wrote:
 "Regan Heath" <regan netwin.co.nz> wrote in message  
 news:opsk4y49nq23k2f5 ally...
 On Tue, 25 Jan 2005 12:56:53 +1100, Matthew  
 <admin.hat stlsoft.dot.org>  wrote:
 "Regan Heath" <regan netwin.co.nz> wrote in message   
 news:opsk4lnexa23k2f5 ally...
 On Tue, 25 Jan 2005 08:08:27 +1100, Matthew   
 <admin.hat stlsoft.dot.org>  wrote:
 "Georg Wrede" <georg.wrede nospam.org> wrote in message
 IMO if(x) should be made the official form of this idiom, in D.

 And documented as such.

 Every language has its preferred idioms, and every idiom can be    
 attacked as unobvious, dangerous, etc. But
 having
 these idioms is what makes the language more fluent and usable.

 The standard idioms make source code much more readable.

That's nice, and in almost all other ways I've fallen into line with the D way of things - no more whinges about boolean, using dCaseMethods, etc. etc. But there's no way I'm writing non-boolean conditional (sub-)expressions. Sorry.

Now I'm curious. Why not?

Just experience over these long years. Explicit boolean conditional (sub-)expressions never cause problems. Implicit ones sometimes do. Therefore I adopt a habit of always doing it to avoid the occasional cases. QED

I use them all the time.. I've never had any trouble (that I can remember), can you give me an example you've run into (I might want/need to scan my recent code for it).

Well, naturally not. Since I have been doing it this way for about 5 years, I don't have any real ones to offer up. :-)

Oh... maybe someone else can come up with one? anyone? Regan
Jan 24 2005
prev sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Matthew wrote:
 "Walter" <newshound digitalmars.com> wrote in message
news:cspa3k$v95$2 digitaldaemon.com...
 
"nail" <nail_member pathlink.com> wrote in message
news:cson1b$5f6$1 digitaldaemon.com...

PS.
I still think that we need 'isnt' for '!=='

In this case isnt must be :) What about future? Does === will become deprecated?

Yes, use "is" from now on. The === turned out to be a problem distinguishing from == with some fonts.

So're we getting an 'isnt'? if(!(x is null)) is never going to be an attractive form

I find this form quite appealing. So sue me. Lars Ivar Igesund PS Welcome back to the NG (Your book looks great, although I've just looked at the TOC :)
Jan 22 2005
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"Lars Ivar Igesund" <larsivar igesund.net> wrote in message
news:cstu97$mqj$1 digitaldaemon.com...
 Matthew wrote:
 "Walter" <newshound digitalmars.com> wrote in message
news:cspa3k$v95$2 digitaldaemon.com...

"nail" <nail_member pathlink.com> wrote in message
news:cson1b$5f6$1 digitaldaemon.com...

PS.
I still think that we need 'isnt' for '!=='

In this case isnt must be :) What about future? Does === will become deprecated?

Yes, use "is" from now on. The === turned out to be a problem distinguishing from == with some fonts.

So're we getting an 'isnt'? if(!(x is null)) is never going to be an attractive form

I find this form quite appealing. So sue me. Lars Ivar Igesund PS Welcome back to the NG (Your book looks great, although I've just looked at the TOC :)

Thanks! <g>
Jan 23 2005
parent reply agent.smith archvillain.com writes:
"Lars Ivar Igesund" <larsivar igesund.net> wrote in message
news:cstu97$mqj$1 digitaldaemon.com...
 Matthew wrote:
 So're we getting an 'isnt'?

     if(!(x is null))

 is never going to be an attractive form

I find this form quite appealing. So sue me.


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 followed by something you only do with a valid 'x'. What you are conceptually saying is: "if x isn't not really there, then do this stuff with it". For such a very common operation, why should a negative be needed? Why not something which reads as "if x is there, then ..." So, in C, I prefer " if (ptr) { ... }". Some folks don't like this at all, because of the implicit conversion from pointer to bool. I can see that when p is a complex expression, but for a simple variable, avoiding a double negative overrides this, IMHO. The problem still exists if you bury the ! in the if (e.g. 'unless' in perl). How about eliminating both negatives by adding an explicit conversion from pointer to boolean. i.e. instead of if( !(x is null)) or if( x isnt null ) // worse than before, IMHO how about if( x.valid ) // new property of pointers or if( isvalid(x)) // already possible by defining isvalid, no? if( cast(bit)x ) // kind of clumsy.
Jan 24 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
agent.smith archvillain.com wrote:

 i.e. instead of
 
 if( !(x is null)) 
 
 or
 
 if(  x isnt null ) // worse than before, IMHO
 
 
 how about
 
 if( x.valid )   // new property of pointers

What if x is null, though ? Does null have any properties ?
 or
 
 if( isvalid(x))  // already possible by defining isvalid, no?

Yes, although specifying the argument type could be tricky...
 if( cast(bit)x ) // kind of clumsy.

You can say that again... "cast(bool)" is not better at all. No, the current solution that D already has is the shortest by far: if (x) Although I don't think "assert (pointer isnot null);" is all bad ? Not very much better than the old "(pointer !== null)" one, though --anders
Jan 24 2005
parent reply agent.smith archvillain.com writes:
In article <ct3fi4$1s4g$2 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
agent.smith archvillain.com wrote:

 how about
 
 if( x.valid )   // new property of pointers

What if x is null, though ? Does null have any properties ?'

variable x has properties, since it has a type. Nullness or non-nullness is a run-time condition. The existence of the property is determined at compile-time; the value is determined at run-time.
 or
 
 if( isvalid(x))  // already possible by defining isvalid, no?

Yes, although specifying the argument type could be tricky...

I had 'void *' in mind. Don't know enough D to be sure.
No, the current solution that D already has is the shortest by far:

if (x)

--anders

yup.
Jan 24 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
agent.smith archvillain.com wrote:

if( x.valid )   // new property of pointers

What if x is null, though ? Does null have any properties ?'

variable x has properties, since it has a type. Nullness or non-nullness is a run-time condition. The existence of the property is determined at compile-time; the value is determined at run-time.

Right, properties work even on null objects. Such as length on char[], which returns 0 for null strings. (comes in handy when comparing them) It's just things such as equality that fails to check on null objects. As in: if (null == x), which works for pointers but fails for objects. Forgot that, thanks. --anders
Jan 24 2005
prev sibling parent reply parabolis <parabolis softhome.net> writes:
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?
Jan 24 2005
parent reply agent.smith archvillain.com writes:
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.
Jan 25 2005
parent Jason Jasmin <zod269-d yahoo.com> writes:
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
Jan 25 2005
prev sibling next sibling parent reply Paul Bonser <misterpib gmail.com> writes:
Anders F wor wrote:
 1 character ? :-)
 
 --anders
 
 PS.
 I still think that we need 'isnt' for '!=='

Gah! It makes me cringe without an apostrophe, though :(. I must have had a good English teacher in high school, because such things pain me. (As well as its-it's their-there-they're to-too and a lot (the only proper way is a lot, two separate words, not one)...but I guess I'm a bit obsessive compulsive, too...) -PIB
Jan 20 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Paul Bonser wrote:

 I must have had a good English teacher in high school, because such 
 things pain me. (As well as its-it's their-there-they're to-too and a 
 lot (the only proper way is a lot, two separate words, not one)...but I 
 guess I'm a bit obsessive compulsive, too...)

I guess you're not in favor of an "aint" keyword then ? :-) Or maybe it should use "p is not null", just like in SQL... Oh, well: !(p is null) --anders
Jan 20 2005
next sibling parent Paul Bonser <misterpib gmail.com> writes:
Anders F Bjrklund wrote:
 Paul Bonser wrote:
 
 I must have had a good English teacher in high school, because such 
 things pain me. (As well as its-it's their-there-they're to-too and a 
 lot (the only proper way is a lot, two separate words, not one)...but 
 I guess I'm a bit obsessive compulsive, too...)

I guess you're not in favor of an "aint" keyword then ? :-) Or maybe it should use "p is not null", just like in SQL... Oh, well: !(p is null) --anders

aint would be awesome... though I think ain't is the right way...innit? Well, it's a made up word so you can spell it however you want :P -PIB
Jan 20 2005
prev sibling parent reply Vathix <vathix dprogramming.com> writes:
On Thu, 20 Jan 2005 23:50:43 +0100, Anders F Bjrklund <afb algonet.se>  
wrote:

 Paul Bonser wrote:

 I must have had a good English teacher in high school, because such  
 things pain me. (As well as its-it's their-there-they're to-too and a  
 lot (the only proper way is a lot, two separate words, not one)...but I  
 guess I'm a bit obsessive compulsive, too...)

I guess you're not in favor of an "aint" keyword then ? :-) Or maybe it should use "p is not null", just like in SQL... Oh, well: !(p is null) --anders

I like the previously mentioned "p !is null". Would also work with "in", "key !in aa".
Jan 20 2005
parent reply Paul Bonser <misterpib gmail.com> writes:
Vathix wrote:
 On Thu, 20 Jan 2005 23:50:43 +0100, Anders F Bjrklund <afb algonet.se>  
 wrote:
 
 Paul Bonser wrote:

 I must have had a good English teacher in high school, because such  
 things pain me. (As well as its-it's their-there-they're to-too and 
 a  lot (the only proper way is a lot, two separate words, not 
 one)...but I  guess I'm a bit obsessive compulsive, too...)

I guess you're not in favor of an "aint" keyword then ? :-) Or maybe it should use "p is not null", just like in SQL... Oh, well: !(p is null) --anders

I like the previously mentioned "p !is null". Would also work with "in", "key !in aa".

I'm not actually opposed to using isnt, I'd just have a hard time for a while typing it without the "'"...isnot would work, too. -PIB
Jan 20 2005
next sibling parent reply agent.smith archvillain.com writes:
I'm not actually opposed to using isnt, I'd just have a hard time for a 
while typing it without the "'"...isnot would work, too.

Microsoft has applied to patent the IsNot operator. I have the link somewhere. Amusing as that is, I have another point. I just recently encountered the D language (Dr Dobbs article got me here) and I really really like what I see. I could go on about why, but it's all the same reasons that are in the D blurb. I have one issue though - is anyone concerned about having too many keywords in the language ? There's a long list of them, and more than 20 are types. And discussion of adding more. So I'm thinking, one of the goals of D is to eliminate the interdependence between compiler passes. My understanding of the issue is this: in order to parse C or C++, you need feedback from the symbol table to the lexer. The two assignments below have different grammatic composition, but you can't know that unless you know that 'foo' is a type name and 'bar' is not: typdef float foo; a= (foo)(i); /* a cast */ b= (bar)(i); /* a function call */ This really stinks, and one of the stated goals of D is to eliminate this problem by adjusting the grammar. Great! So, given that, is there any reason why int, uint, wchar, ubyte and all those guys need to be keywords? In many languages, type names are predefined identifiers. For instance, Python, Pascal, VHDL, and, I think, Ada (python doesn't have type declarations in any form, so that hardly counts, but it does have predefined variables for type objects). In fact, 'true' and 'false' could be predefined identifiers corresponding to constants of type bit. Two more keywords down. Of course, you could argue that they should be keywords not because they *need* to be, but because redefining them would be a Bad Thing, and can't ever be useful. The problem is, if a new type is added in the future, it *should* be added as an identifier, so that it won't mess up existing code where the same name is used as a local variable, or struct member name, for instance. So why not start as you mean to go on, so that the langauge definition stays consistent. Years ago I was helping someone move some code from C to C++; we couldn't understand how a struct decl would work in C and fail in C++, until we noticed a member named 'this'. Now, really, C++ 'this' is conceptually a local variable, and struct member names are in a separate space, so given a different implementation of C++, it would have worked. But you make something a keyword, you reserve its meaning in all possible contexts. Like #define. #define is not in D, because it's ugly, but mainly because defining meaning to a word regardless of context is a Bad Thing, so why not extend the same argument to keywords that don't really need to be keywords? In C++, 'this' didn't need to be a keyword, it could be an implicitly declared const pointer parameter in all member funcs. One less keyword, and it wouldn't have broken that C code (hey, that could probably work for D too). In D, the properties (like int.max, array.length, double.nan, x.size) are not keywords, and they shouldn't be - otherwise you couldn't have a variable called 'length'. I think this philosophy could extend to type names too. I have kind of a vague bias against too many keywords. My favorite language, Python, has relatively few keywords. It forms some operatore using pairs of keywords like 'is not' and 'not in', eliminating the need for extra keywords - I can't see any reason not to do this, as long as is doesn't break the grammar ('is not' barely works in python - the alternate interpretation "a is (not b)" *is* legal, but useless in practice) Conversely, one of the most awful languages I've used -- Dec PDP11 compiled BASIC (for RSTS or something) -- had four full manual pages listing the reserved words, including pretty much any word that had anything do with computers or data processing. So you had to write your code with everything spelled wrong, as in REKORD=REKORD+1.
Jan 20 2005
next sibling parent reply parabolis <parabolis softhome.net> writes:
agent.smith archvillain.com wrote:

 to the lexer. The two assignments below have different grammatic
 composition, but you can't know that unless you know that 'foo'
 is a type name and 'bar' is not:
 
 typdef float foo;
 a= (foo)(i);   /* a cast */
 b= (bar)(i);   /* a function call */

Check the D spec on casting. Especially Unary Expressions: http://www.digitalmars.com/d/expression.html#UnaryExpression So the above should be: ---------------------------------------------------------------- a= cast(foo)(i); /* a cast */ b= (bar)(i); /* a function call */ ----------------------------------------------------------------
Jan 20 2005
parent reply agent.smith archvillain.com writes:
My example was C code, I was making a point which
everybody here probably already knows (sorry for any confusion)
as a step towards my real point that typenames in D don't
need to be reserved words. Precisely because the D language,
unlike C/C++, does *not* need them to be so in order to direct parsing.
And making too many things keywords has some bad side-effects.


In article <csq0ml$1nh8$1 digitaldaemon.com>, parabolis says...
agent.smith archvillain.com wrote:
 typedef float foo;
 a= (foo)(i);   /* a cast */
 b= (bar)(i);   /* a function call */>Check the D spec on casting. Especially
Unary Expressions:

So the above should be: ---------------------------------------------------------------- a= cast(foo)(i); /* a cast */ b= (bar)(i); /* a function call */ ----------------------------------------------------------------

Jan 21 2005
parent reply parabolis <parabolis softhome.net> writes:
agent.smith archvillain.com wrote:
 My example was C code, I was making a point which
 everybody here probably already knows (sorry for any confusion)
 as a step towards my real point that typenames in D don't
 need to be reserved words. Precisely because the D language,
 unlike C/C++, does *not* need them to be so in order to direct parsing.
 And making too many things keywords has some bad side-effects.

My point was that cast, one of the "long list of keywords", serves the purpose of allowing all casts to be identified by the lexer.
Jan 21 2005
parent agent.smith archvillain.com writes:
In article <csrmji$or4$1 digitaldaemon.com>, parabolis says...
agent.smith archvillain.com wrote:
 My example was C code, I was making a point which
 everybody here probably already knows (sorry for any confusion)
 as a step towards my real point that typenames in D don't
 need to be reserved words. Precisely because the D language,
 unlike C/C++, does *not* need them to be so in order to direct parsing.
 And making too many things keywords has some bad side-effects.

My point was that cast, one of the "long list of keywords", serves the purpose of allowing all casts to be identified by the lexer.

[Well, by the parser, but without help from the symbol table]. But, yes, exactly right. And thus, in cast(wchar), 'wchar' doesn't need to be a keyword. Not like C. Thus that *one* word 'cast' (well, maybe not *just* that), means you could take 20+ other words out of the list. I wish I'd made that exact point before, thanks. So why not take them out? The work has been done, why not reap the benefits? I know I'm missing a really compelling argument why it's a Bad Thing to have too many keywords. All I can say is, take all the languages you know and love or hate, and place them on a scale according to the number of keywords they have, and decide in what neighborhood you'd like to be. Maybe a language isn't good or bad because of how many keywords it has; maybe it tends to be the other way around; but there just seems to be a correlation. It seems that well designed languages don't need a lot of keywords, and many keywords are often used as a crutch to help parse a poorly designed language (one could argue that C typedefs are dynamically defined keywords, for the precise purpose of crutching the parser). Of course, you can go too far in the other direction and have Lisp or APL (not to impune anything but their appearance). D has been well-designed to the point where it doesn't need keywords for all the built-in types, or for 'true' and 'false' (these could be predefined const values like in Pascal). So why are they still in the list??
Jan 21 2005
prev sibling next sibling parent reply Kris <Kris_member pathlink.com> writes:
In article <csps3e$1jcu$1 digitaldaemon.com>, agent.smith archvillain.com
says...
In D, the properties (like int.max, array.length, double.nan, x.size)
are not keywords, and they shouldn't be - otherwise you couldn't
have a variable called 'length'. I think this philosophy could extend
to type names too.

Good points. Unfortunately, you cannot have a variable called 'length' in D. Well ... you can ... but there's that sneaky issue where you can't use it within an array reference: # int length = 0; # char x[], y[20]; # # // what do you think will happen here? # x = y[0 .. length]; Believe it or not, 'length' is a pseudo-reserved keyword when used in this manner (within the braces), although the compiler says nothing about the 'collision'. This is one of several insideously sneaky things that have been introduced to D recently -- an overload of a rather common variable name, /particularly/ so when used with arrays. It's a great way to piss-off both novices and experts alike - Kris
Jan 20 2005
parent reply agent.smith archvillain.com writes:
In article <csq18r$1o7t$1 digitaldaemon.com>, Kris says...
In article <csps3e$1jcu$1 digitaldaemon.com>, agent.smith archvillain.com
says...
 Unfortunately, you cannot have a variable called 'length' in D.
Well ... you can ... but there's that sneaky issue where you can't use it within
an array reference:

# int length = 0;
# char x[], y[20];
#
# // what do you think will happen here?  
# x = y[0 .. length];

Believe it or not, 'length' is a pseudo-reserved keyword when used in this
manner (within the braces), although the compiler says nothing about the
'collision'.

myfunc() { int x; ... { int x; ... } ... } .. shouldn't the same philosophy make your example an error? That would be a Good Thing, IMHO. I.e. I can use 'length' if I want, but the compiler will keep me from loading it and pointing it at my foot. I can still do x.length. So somebody wanting to add the last statement to my code later would either have to add int ylength= y.length; x = y[ 0..ylength]; or int tlength = length; x = y[ 0..tlength]; .. whilst cursing me in the comments. or just s/length/len/ first. I'm not so sure that this should be disallowed: myfunc() { {int x; ...} { int x; ... } ... } I've an awful lot of C++ code where ... for( int irow=0; irow < h ; irow ++ )... .. appears several times in a function, and I'm less convinced that's dangerous. I'm making it explicit that these are independent uses of the same conceptual variable; in D i'd have to give each one a different name, or make them all the same variable, neither of which accomplishes this. Another issue: years ago I read something on a language newsgroup which really surprised me... that every Pascal 'with .. do' was a bug waiting to happen; but the author was right; what is even more scary is that the exact same issue exists in every C++ member func; these inherit scopes in basically the same way as a with ..do. It's actually worse in C++, because of class inheritance. This problem, which could result in bugs that take days to find, is commonly avoided by lexical conventions (e.g. starting member names with m_). Here's the problem in C++: ---- static int table[] = {1,2,3}; int MyClass::memberfunc(int i) { return table[i]; } --- OK. Now imagine 'MyClass' is based on 'JoesClass', and next week Joe adds a member 'table' to his function. My memberfunc() function will now reference that member variable instead of the static local! If I'm really lucky, I'll get a compile error, if not, I'll get different runtime behaviour, despite the fact that I didn't touch my code, and Joe's change was done in such a way as not to change the existing class interface (other than by adding this name...) This could take ages to figure out. The reason this doesn't happen much is because most variable naming conventions avoid it (e.g m_); but I suspect few programmers realize that this can happen. I only realized recently that the Pascal problem applies to C++ too. This can be avoided, of course, by putting :: in front of table, but that's a lot of ::'s to use. Some languages (e.g. Python) require explicit this->, (or self.) which is also rather a pain, but at least avoids this problem. Is there is a similar issue in D? Fundamentally, the problem is that a name introduced into a distant scope (inherited class) can hide a variable in a scope which is in some sense much closer (file scope of the function); it can be argued that the derived class and the file scope are under control of the author of the derived class, whereas the base class is not; and therefore this should not work this way. Maybe it's even more dangerous, somehow, to insert the file scope between the base class and derived class. In any case, it seems to me that this is a detectable case of ambiguity, and it's not unreasonable to flag it as such, and require the :: to be used. The problem will also be avoided if Joe's member 'table' is private. It might not compile, but that's better than compiling with the wrong meaning. I apologize for not stating this in D terms, and I apologize profusely if this is discussed in the D docs somewhere, but I haven't had time to read it all yet... will do so before further ramblings.. I did see just now that there is a with(){ } in D, which may suffer from the same problem, but this time accidentally hiding local vars instead of file-scope? This is more dangerous, if only because naming conventions are much less likely to protect you.
Jan 21 2005
parent "Regan Heath" <regan netwin.co.nz> writes:
On Fri, 21 Jan 2005 17:36:01 +0000 (UTC), <agent.smith archvillain.com>  
wrote:

<snip>

 Another issue:  years ago I read something on a language newsgroup which  
 really
 surprised me... that every Pascal 'with .. do' was a bug waiting to  
 happen; but
 the author was right; what is even more scary is that the exact same  
 issue
 exists in  every C++ member func; these inherit scopes in basically the  
 same way
 as a with ..do.  It's actually worse in C++, because of class  
 inheritance.
 This problem, which could result in bugs that take days to find, is
 commonly avoided by lexical conventions (e.g. starting member names with  
 m_).

 Here's the problem in C++:
 ----
 static int table[] = {1,2,3};

 int MyClass::memberfunc(int i)
 {
 return table[i];
 }
 ---
 OK. Now imagine 'MyClass' is based on 'JoesClass', and next week Joe
 adds a member 'table' to his function. My memberfunc() function will now
 reference that member variable instead of the static local! If I'm really
 lucky, I'll get a compile error, if not, I'll get different runtime  
 behaviour,
 despite the fact that I didn't touch my code, and Joe's change was done  
 in
 such a way as not to change the existing class interface (other than by
 adding this name...) This could take ages to figure out. The reason
 this doesn't happen much is because most variable naming conventions
 avoid it (e.g m_); but I suspect few programmers realize that this can  
 happen.
 I only realized recently that the Pascal problem applies to C++ too.

 This can be avoided, of course, by putting :: in front of table, but  
 that's
 a lot of ::'s to use. Some languages (e.g. Python) require explicit  
 this->,
 (or self.) which is also rather a pain, but at least avoids this problem.

 Is there is a similar issue in D?

Yes. # static int table[] = [1,2,3]; # # class A { # //adding this line causes output of '4' # //static int table[] = [4,5,6]; # } # # class B : A { # int test(int x) { return table[x]; } # } # # void main() { # B b = new B(); # int x = 0; # # //outputs '1' unless above line is un-commented # printf("table[%d] = %d\n",x,b.test(x)); # }
 Fundamentally, the problem is that
 a name introduced into a distant scope (inherited class) can hide a  
 variable
 in a scope which is in some sense much closer (file scope of the  
 function);

The key phrase being "in some sense". I believe, either could be argued to be 'closer'. eg. the external is closer as it's in the same file. the parent class is closer to the child than external things are.
 it can be argued that the derived class and the file scope are under  
 control
 of the author of the derived class, whereas the base class is not; and  
 therefore
 this should not work this way.

Unfortunately we cannot "have our cake and eat it too", if classes did not inherit there would be little point in them. Fortunately I have a reasonably nice solution (depends on your opinion I suppose) The way I see it: 1. Either 'table' is part of your class and should thus be included in it eg. # class B : A { # static int table[] = [1,2,3]; # int test(int x) { return table[x]; } # } 2. 'table' is some data from an external source i.e. lib.foobar and you should refer to it by it's full name, now, I agree it's somewhat ugly to have to say: # class B : A { # int test(int x) { return lib.foobar.table[x]; } # } if you have to use it in several places, so.. what about: # class B : A { # alias table lib.foobar.table; # int test(int x) { return table[x]; } # }
 Maybe it's even more dangerous, somehow,
 to insert the file scope between the base class and derived class.

That at least increases the distance in terms of seeing the class and it's parent at the same time, so would make it harder to spot the bug.
 In any case, it seems to me that this is a detectable case of ambiguity,  
 and it's not unreasonable to flag it as such, and require the :: to be  
 used.

The way name resolution works IIRC is to start in the current scope and keep stepping up till it finds a name match, then it does implicit conversions to make the type match. So, once the parent class definition has been added, there is no ambiguity (according to the name resolution system). We could force people to refer to global variables by their full name (allowing aliasing as I have shown)
 The problem will also be avoided if Joe's member 'table' is private. It
 might not compile, but that's better than compiling with the wrong  
 meaning.

Given the name resolution rules I'd expect an error.
 I apologize for not stating this in D terms, and I apologize profusely if
 this is discussed in the D docs somewhere, but I haven't had time to read
 it all yet... will do so before further ramblings..
 I did see just now that there is a with(){ } in D, which may suffer from  
 the
 same problem, but this time accidentally hiding local vars instead of
 file-scope? This is more dangerous, if only because naming conventions  
 are much
 less likely to protect you.

It seems "with" does have the same set of problems. It seems to me that there are 2 solutions to this problem: 1. change name resolution to continue searching for a match after finding one, allowing it to highlight the ambiguity with an error, which would in some (many?) cases cause... 2. require the complete explicit specification of everything. IIRC C# uses 2 above? Which itself causes more typing for you and I, larger source files, slower parsing/compile times, etc. So, are the benefits worth the costs? As with everything it depends where you want to draw the line. Regan
Jan 23 2005
prev sibling next sibling parent "Lionello Lunesu" <lionello.lunesu crystalinter.remove.com> writes:
<agent.smith archvillain.com> wrote in message 
news:csps3e$1jcu$1 digitaldaemon.com...
 [...]

I totally agree with you. So much in fact, that I refer to a thread I started a month or so ago: http://www.digitalmars.com/d/archives/digitalmars/D/12260.html Lionello.
Jan 21 2005
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
agent.smith archvillain.com wrote:

 For instance, Python, Pascal, VHDL, and, I think, Ada (python
 doesn't have type declarations in any form, so that hardly counts,
 but it does have predefined variables for type objects).

You should try Perl then, for a refreshing look on operators and vars :)
 In fact, 'true' and 'false' could be predefined identifiers corresponding
 to constants of type bit. Two more keywords down.

They already are, if you look at the code. But I would rather add bool. --anders
Jan 21 2005
prev sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"Paul Bonser" <misterpib gmail.com> wrote in message
news:cspjj1$1agb$1 digitaldaemon.com...
 Vathix wrote:
 On Thu, 20 Jan 2005 23:50:43 +0100, Anders F Bjrklund <afb algonet.se>  wrote:

 Paul Bonser wrote:

 I must have had a good English teacher in high school, because such  things
pain me. (As well as its-it's 
 their-there-they're to-too and a  lot (the only proper way is a lot, two
separate words, not one)...but I  guess 
 I'm a bit obsessive compulsive, too...)

I guess you're not in favor of an "aint" keyword then ? :-) Or maybe it should use "p is not null", just like in SQL... Oh, well: !(p is null) --anders

I like the previously mentioned "p !is null". Would also work with "in", "key !in aa".

I'm not actually opposed to using isnt, I'd just have a hard time for a while typing it without the "'"...isnot would work, too.

isnot is better
Jan 21 2005
parent reply "Lionello Lunesu" <lionello.lunesu crystalinter.remove.com> writes:
 isnot is better

and "notin"? L.
Jan 21 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Lionello Lunesu wrote:

isnot is better

and "notin"?

Since the "InExpression" is not boolean anymore, http://www.digitalmars.com/d/expression.html#InExpression there is no need for any "notin" or "out" version ? See http://www.digitalmars.com/d/arrays.html#associative :
  The InExpression yields a pointer to the value if
  the key is in the associative array, or null if not:
 
 	int* p;
 	p = ("hello" in b);
 	if (p != null)

And since p is a pointer, it can use == and != checks... (had p been a reference, that would call opEquals(null)) You can still use the non-boolean shorthand versions: if ("key" in hashtable) and if (!("key" in hashtable)) But the return type is now a pointer, and not an int. http://www.digitalmars.com/d/changelog.html#new0107 --anders
Jan 21 2005
prev sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Anders F Bjrklund wrote:
 1 character ? :-)
 
 --anders
 
 PS.
 I still think that we need 'isnt' for '!=='

We should start using a word for >= and <=, too. There are perfect words for them in non-computer literature, and in the spoken language as well. They are "at least" and "at most", respectively. Reading "greater than or equal to" instead of "at least" is like reading "!==" as "Bang equal equal". As a matter of fact, "at least" and "at most" have direct translations to most human languages in the world. This only shows how intuitive and commonly needed the concept itself is.
Jan 20 2005
next sibling parent reply parabolis <parabolis softhome.net> writes:
Georg Wrede wrote:
 Anders F Bjrklund wrote:
 I still think that we need 'isnt' for '!=='

We should start using a word for >= and <=, too. There are perfect words for them in non-computer literature, and in the spoken language as well. They are "at least" and "at most", respectively.

I think you missed the larger point that "isnt" is better than nothing which is what we have since "is not" is not a single word. The phrases "at least" and "at most" suffer from the same problem that keeps "is not" from being possible while lacking a contractable form.
 Reading "greater than or equal to" instead of "at least" is like reading 
 "!==" as "Bang equal equal".

Reading ">=" as "greater than equal" is analogous to "bang equal equal." Reading ">=" as "greater than *or* equal *to*" is like reading "!==" as "is not equivalent to."
Jan 20 2005
next sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
 I still think that we need 'isnt' for '!=='


which is what we have since "is not" is not a single word. The phrases "at least" and "at most" suffer from the same problem that keeps "is not" from being possible while lacking a contractable form.

I ignored it, since the main point was kind of obvious. :-) In my mother tongue "at most" is just one word, as is "at least". My gripe is actually the pronunciation of "<=" as "less than or equal to", in all spoken languages. It sounds clumsy and overly technical, especially as it refers to a single operator, or concept, more than a combination of two. Back to the original point, I like "isnt". It should be perfectly ok since nobody seems to have a problem with "endif". We might use "isnot", but "isnt" feels nicer.
Jan 21 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Georg Wrede wrote:

 In my mother tongue "at most" is just one word, as is "at least". My 
 gripe is actually the pronunciation of "<=" as "less than or equal to", 
 in all spoken languages. It sounds clumsy and overly technical, 
 especially as it refers to a single operator, or concept, more than a 
 combination of two.

Do you actually read your programs out loud ? Haven't done that since I went to school and had program (implement) the whole thing on paper. But maybe I should get the speech synthesizer to read my D code now... That would be good for a laugh or two, I think. (wonder where it's at) --anders PS: Being an assembly and Perl nerd, I just think "le" :-) http://www.perldoc.com/perl5.8.0/pod/perlop.html#Relational-Operators
Jan 21 2005
parent reply Georg Wrede <georg.wrede nospam.org> writes:
Anders F Bjrklund wrote:
 Do you actually read your programs out loud ? Haven't done that since
 I went to school

It's not just the students. Teachers have to speak too.
Jan 21 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Georg Wrede wrote:

 Do you actually read your programs out loud ?
 Haven't done that since I went to school

It's not just the students. Teachers have to speak too.

Guess I have been at the computer for too long then, nowadays I mostly communicate through email. Or CVS ;-) But usually we spoke about design, and then coded the details. I don't recall long sessions or reading/writing such signs, or maybe it was just because I skipped those. Or maybe because they were in a different language anyway ? Seems I'll still have trouble coding in my native tongue:
 void anders() {}
 void bjrklund() {}
 
 void main()
 {
   anders();
   bjrklund();
 }

dmd anders.d [8]
 /var/tmp//cclIBzkT.s:44:Invalid mnemonic 'rklundFZv'

So I think I will stick with abstract math symbols, thank you. :) And using English for communication such as this, and comments. But if '!==' is now deprecated, then TOKnotidentity should have some kind of new token shouldn't it ? Then again there is no TOKnotin... (in dmd/src/dmd/lexer.c and lexer.h, that is; The DMD source code) Could be since "in" returns a pointer and not a bit, these days ? But this construct is pretty common: "assert (foo !== null);" If that is soon deprecated, it needs some kind of replacement ? I know that Walter will suggest "assert(foo)", so I'll drop it. --anders PS. Had the computer read it to me. It *was* funny! (App > Services > Speech > Start Speaking Text)
Jan 21 2005
prev sibling parent reply John Reimer <brk_6502 yahoo.com> writes:
Georg Wrede wrote:

 I ignored it, since the main point was kind of obvious.  :-)
 
 In my mother tongue "at most" is just one word, as is "at least". My 
 gripe is actually the pronunciation of "<=" as "less than or equal to", 
 in all spoken languages. It sounds clumsy and overly technical, 
 especially as it refers to a single operator, or concept, more than a 
 combination of two.
 
 Back to the original point, I like "isnt". It should be perfectly ok 
 since nobody seems to have a problem with "endif". We might use "isnot", 
 but "isnt" feels nicer.

As an English speaker, "isnt" feels very informal. I doesn't (!) quite feel correct to use informal English contractions in a computer language.
Jan 21 2005
parent reply John Reimer <brk_6502 yahoo.com> writes:
John Reimer wrote:
 Georg Wrede wrote:
 
 I ignored it, since the main point was kind of obvious.  :-)

 In my mother tongue "at most" is just one word, as is "at least". My 
 gripe is actually the pronunciation of "<=" as "less than or equal 
 to", in all spoken languages. It sounds clumsy and overly technical, 
 especially as it refers to a single operator, or concept, more than a 
 combination of two.

 Back to the original point, I like "isnt". It should be perfectly ok 
 since nobody seems to have a problem with "endif". We might use 
 "isnot", but "isnt" feels nicer.

As an English speaker, "isnt" feels very informal. I doesn't (!) quite feel correct to use informal English contractions in a computer language.

Heh, obviously I meant to say "It doesn't."
Jan 21 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
John Reimer wrote:

 As an English speaker, "isnt" feels very informal.  I doesn't (!) 
 quite feel correct to use informal English contractions in a computer 
 language.

Heh, obviously I meant to say "It doesn't."

Or: "Not that I do", as in current D syntax. :-) (p isnot null) => (!(p is null)) --anders PS. I take it that's another one against "aint" ?
Jan 21 2005
parent reply John Reimer <brk_6502 yahoo.com> writes:
Anders F Bjrklund wrote:

 
 Or: "Not that I do", as in current D syntax. :-)
 
 (p isnot null) => (!(p is null))
 
 --anders
 
 PS. I take it that's another one against "aint" ?

Heh, "aint" just doesn't cut it. :-)
Jan 21 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
John Reimer wrote:

 PS. I take it that's another one against "aint" ?

Heh, "aint" just doesn't cut it. :-)

The two most likely outcomes are "isnot", or nothing. I mean, since "(p)" works and booleans are unwanted, then shortening "(!(p is null))" is not a priority ? Hopefully, "===" and "!==" will continue to work when using the "-d" flag (for deprecated features)... --anders
Jan 21 2005
next sibling parent John Reimer <brk_6502 yahoo.com> writes:
Anders F Bjrklund wrote:
 John Reimer wrote:
 
 PS. I take it that's another one against "aint" ?

Heh, "aint" just doesn't cut it. :-)

The two most likely outcomes are "isnot", or nothing. I mean, since "(p)" works and booleans are unwanted, then shortening "(!(p is null))" is not a priority ? Hopefully, "===" and "!==" will continue to work when using the "-d" flag (for deprecated features)... --anders

If it is anything, then "isnot" it is; otherwise "nothing" is it. :-) - John
Jan 21 2005
prev sibling parent "Lionello Lunesu" <lionello.lunesu crystalinter.remove.com> writes:
 Hopefully, "===" and "!==" will continue to work
 when using the "-d" flag (for deprecated features)...

They shouldn't be supported. Walter'd better add a hint to the error messages which they'll generate when they are removed. old.d(25): I did not expect another = after == (did you mean "is"?) old.d(26): either use != or == but not both (did you mean "isnot"?) L.
Jan 21 2005
prev sibling parent reply Brian Chapman <nospam-for-brian see-post-for-address.net> writes:
On 2005-01-21 08:14:02 -0600, John Reimer <brk_6502 yahoo.com> said:

 Anders F Bjrklund wrote:
 
 PS. I take it that's another one against "aint" ?

Heh, "aint" just doesn't cut it. :-)

I think 'aint' would be great! if (p aint null) ill_be_damed (); if (you aint good) goto hell; Now as a Texan, that's speaking my language. ;-)
Jan 25 2005
parent parabolis <parabolis softhome.net> writes:
Brian Chapman wrote:

  if (p aint null) ill_be_damed ();

I don't generally correct spelling errors but I think you meant 'ahl_be_dahmned();' ; )
Jan 25 2005
prev sibling parent reply agent.smith archvillain.com writes:
In article <cspmau$1e2o$1 digitaldaemon.com>, parabolis says...
I think you missed the larger point that "isnt" is better than nothing 
which is what we have since "is not" is not a single word. The phrases 
"at least" and "at most" suffer from the same problem that keeps "is 
not" from being possible while lacking a contractable form.

Is there a reason why an operator has to be a single token? Using 'is not' requires the addition of an extra keyword 'not', which might be useful to combine with other keywords elsewhere, whereas 'isnt' adds a keyword with a single use. Parsers shouldn't have any trouble with this sort of thing (long int and unsigned long in C/C++, for instance). It should be a trivial transformation in the grammar, like combining adjacent string constants into one. I could see why one might want each operator to be a single lextoken, for reasons of style or cleanliness rather than technical reasons. Personally I think that minimizing the number of keywords is also important for cleanliness.
Jan 21 2005
parent reply parabolis <parabolis softhome.net> writes:
agent.smith archvillain.com wrote:
 In article <cspmau$1e2o$1 digitaldaemon.com>, parabolis says...
 
I think you missed the larger point that "isnt" is better than nothing 
which is what we have since "is not" is not a single word. The phrases 
"at least" and "at most" suffer from the same problem that keeps "is 
not" from being possible while lacking a contractable form.

What problem?

The problem that D supports Unicode to make it internationally usable but still has only English keywords. Just using "is" is bad enough but to take that a step farther and assume all languages have a copula, an individual word for negation and that the negation word follows the copula is rather dangerous. Of course you may very well fluently speak all the languages spoken on the planet but I do not and so it seems like a problem to me.
Jan 21 2005
parent reply agent.smith archvillain.com writes:
In article <csrlnk$npm$1 digitaldaemon.com>, parabolis says...
agent.smith archvillain.com wrote:
 In article <cspmau$1e2o$1 digitaldaemon.com>, parabolis says...
 
I think you missed the larger point that "isnt" is better than nothing 
which is what we have since "is not" is not a single word. The phrases 
"at least" and "at most" suffer from the same problem that keeps "is 
not" from being possible while lacking a contractable form.

What problem?

The problem that D supports Unicode to make it internationally usable but still has only English keywords. Just using "is" is bad enough but to take that a step farther and assume all languages have a copula, an individual word for negation and that the negation word follows the copula is rather dangerous. Of course you may very well fluently speak all the languages spoken on the planet but I do not and so it seems like a problem to me.

This is a point which had not occurred to me; but I'm trying to understand how it affects the question of whether 'is not' is any worse than 'isnt'. You are referring I think, about the difficulty of understanding 'is not' vs. 'isnt', or 'isnot', or vs. some arrangement of punctuation marks, for a non-anglophone-- this is an interesting point. I've never programmed in a language in which the 'words' aren't those of my native tongue, so I can only guess at the difficulties involved. I would suspect the concepts of programming easily transcend (or overwhelm) the difficulties of a few characters or a few syllables that aren't in the language or order you are used to -- I would be glad to hear from someone who can speak to this. I have worked with many Russian and French-speaking programmers and the topic just never came up. I took two years of high school mathematics (which wound up covering most of my 1st year engineering math and much of the 2nd year) completely in French, and although I always fared quite poorly at actual French, I had no difficulty learning the verbs and adjectives, and different methods of pronouncing mathematical constructs in French. Or, at least, it was almost always less difficult than the math itself. I admit there is something compelling about the idea of a language where all expressions are in symbolic form, so it transcends language. But you'll still have (a) things like .length; (b) all the "bigger" keywords like 'while' and 'public'; (c) libraries and APIs full of words. And aren't we there already, to a large degree? Consider all the nonsense words we deal with, wchar, typedef, frexp, cdecl, ... yacc, http... it never occurred to me until right now how little meaning they derive from language as opposed to just being glued together from other computer words. And, consider APL. Was that really a good idea? I guess what I'm saying is, if you choose to do 'is' and 'isnt' as 'ek' and 'nis ek', it wouldn't slow me down much. Maybe I'm wrong. I am completely missing the point? If a language doesn't have a separate 'is' word, speakers of the language will still grasp the concept easily. If the language is so unusual that it hasn't introduced them to the concept, they may need more help than a few letters can give them -- see "Seeing Voices" by Oliver Sacks, there is a discussion of how failure to be introduced, as a toddler, to basic abstract notions (e.g. a 'person', as opposed to 'Bob' or 'Mary') severely impairs learning. These concepts are universal.
Jan 21 2005
next sibling parent reply parabolis <parabolis softhome.net> writes:
agent.smith archvillain.com wrote:
 In article <csrlnk$npm$1 digitaldaemon.com>, parabolis says...
 
agent.smith archvillain.com wrote:

In article <cspmau$1e2o$1 digitaldaemon.com>, parabolis says...


I think you missed the larger point that "isnt" is better than nothing 
which is what we have since "is not" is not a single word. The phrases 
"at least" and "at most" suffer from the same problem that keeps "is 
not" from being possible while lacking a contractable form.

What problem?

The problem that D supports Unicode to make it internationally usable but still has only English keywords. Just using "is" is bad enough but to take that a step farther and assume all languages have a copula, an individual word for negation and that the negation word follows the copula is rather dangerous. Of course you may very well fluently speak all the languages spoken on the planet but I do not and so it seems like a problem to me.

This is a point which had not occurred to me; but I'm trying to understand how it affects the question of whether 'is not' is any worse than 'isnt'.

You mentioned learning french which is a good example. Negation in french involves 3 words ne, est and pas. The french contradiction solution would give is=nest and not=pas. However we would be expecting is to remain unchanged in the affirmative or the negative. So you could probably get by assigning is=est and not=pas. However isnt is a whole new keyword which would allow nestpas. So without going very far away from the roots of English (and the only other language I have really studied) we are already having trouble getting everything to work out if we use is not.
 I've never programmed in a language in which the
 'words' aren't those of my native tongue, so I can only guess at
 the difficulties involved. I would suspect the concepts of programming
 easily transcend (or overwhelm) the difficulties of a few characters or a
 few syllables that aren't in the language or order you are used to

I would largely agree but with the caveat that it speeds learning the language if you already have an intuitive feel for how the various parts work. I know almost no Russian or Norse but I am pretty confident I could pick up is, if, else, do, while, etc in a day or so. However it would not be without some difficulty that I adjusted to actually reading and writing these things from day to day.
 I admit there is something compelling about the idea of a language where all
 expressions are in symbolic form, so it transcends language. But you'll
 still have (a) things like .length; (b) all the "bigger" keywords like 'while'
 and 'public'; (c) libraries and APIs full of words. 

I am pretty sure (c) is beyond the scope of D's language spec. It is mostly (a) and (b) that concern me.
 And aren't we there already, to a large degree? Consider all the
 nonsense words we deal with, wchar, typedef, frexp,
 cdecl, ... yacc, http... it never occurred to me until right now how
 little meaning they derive from language as opposed to just being
 glued together from other computer words.

I think I may be the wrong person to ask. I am rather abnormal in that they all contain a great deal of meaning for me. Just recently I found myself wondering about GNU's relation to Unix but quickly solved the problem by rephrasing the question as "Is GNU Unix?".
 And, consider APL. Was that really a good idea?

Actually I imagine APL's symbols seem more familiar to an anglo reader than if clauses would to a mandarin reader. However I am not suggesting a pure symbolic language. I want to see if clauses in mandarin and english.
Jan 21 2005
parent reply agent.smith archvillain.com writes:
In article <css7cg$1c78$1 digitaldaemon.com>, parabolis says...
You mentioned learning french which is a good example. Negation 
in french involves 3 words ne, est and pas. The french 
contradiction solution would give is=nest and not=pas. However we 
would be expecting is to remain unchanged in the affirmative or 
the negative. So you could probably get by assigning is=est and 
not=pas. However isnt is a whole new keyword which would allow 
nestpas. So without going very far away from the roots of English 
(and the only other language I have really studied) we are 
already having trouble getting everything to work out if we use 
is not.

I may have missed the point. Are we talking about creating variants of D where keywords are spelled in other languages? Wow. For what it's worth, I think that "nest pas" (without the ') could be less palatable to a francophone than a simple foreign phrase like 'is not'. Even with my few years of high school French, I found that reading the language without the proper punctuation and accents is like reding weth rong spelyng. So you'd probably want to deal with that somehow. If this is the plan, then, yes, you probably want to stick to one token per operator. I don't see why you can't define token combining rules, so that the two keywords 'is' 'not' in english D combine to the same token which is generated by a single Hebrew word, but I also can see why this might not a good idea.
 I've never programmed in a language in which the
 'words' aren't those of my native tongue, so I can only guess at
 the difficulties involved. I would suspect the concepts of programming
 easily transcend (or overwhelm) the difficulties of a few characters or a
 few syllables that aren't in the language or order you are used to

I would largely agree but with the caveat that it speeds learning the language if you already have an intuitive feel for how the various parts work. I know almost no Russian or Norse but I am pretty confident I could pick up is, if, else, do, while, etc in a day or so. However it would not be without some difficulty that I adjusted to actually reading and writing these things from day to day.

I tend to agree but - and again I'm trying to imagine what it's like- if I could write variable and function names in my native language (and not just comments) complete with diacritical marks, etc. then it probably makes a bigger difference. I.e. if I have to adjust to latin alphabet for all my identifiers, then reading a few keywords in latin would be no big deal. Is the plan to support unicode identifiers, with all that implies for linking, etc? I don't see why not - there's a lot of messy practical issues though. For instance, error messages from ld would need to be in unicode, or else they could list undefined symbols as gibberish mangled ASCII.
 I admit there is something compelling about the idea of a language where all
 expressions are in symbolic form, so it transcends language. But you'll
 still have (a) things like .length; (b) all the "bigger" keywords like 'while'
 and 'public'; (c) libraries and APIs full of words. 

I am pretty sure (c) is beyond the scope of D's language spec. It is mostly (a) and (b) that concern me.

libc was beyond the C language spec initially; it still is, in some sense, but it's hard to separate the two in practice. As in my previous point, unless you translate the standard libraries, you aren't covering much of the actual namespace. But the core language should be dealt with ahead of the libraries, I guess.
 And aren't we there already, to a large degree? Consider all the
 nonsense words we deal with, wchar, typedef, frexp,
 cdecl, ... yacc, http... it never occurred to me until right now how
 little meaning they derive from language as opposed to just being
 glued together from other computer words.

I think I may be the wrong person to ask. I am rather abnormal in that they all contain a great deal of meaning for me. Just recently I found myself wondering about GNU's relation to Unix but quickly solved the problem by rephrasing the question as "Is GNU Unix?".

That's Gnot the point. Do you think about that every time you read it, or do you just associate the term with the entity? If you had no idea what 'GNU' stood for, but had come to understand its important non-relation to Unix through the same years of experience you have already have, would that hinder you much? I don't mean to sound humourless, but my point exactly is that you *didn't* solve the problem that way; in fact, you need to understand the relationship in order to get the joke. It's conceptually recursive, as well as lexically recursive. So, the roots of the term 'gnu' continue to be a source of amusement, (which in itself has excellent mnemonic value), but you can't claim it's descriptive, in the sense that, say, "Statten Island Ferry" is. When you look at a while loop, do you usually pause to consider that the word is also a noun, meaning 'a period of time'? If you do, then I concede your strangeness. I've noticed that a lot of magazines, due presumably to editorial policy, won't print the term "ASCII" without following the first occurrence by the usual clumsy phrase (Amer... ...change). Does that clarify anything for anyone? If someone doesn't know what ASCII is, I doubt that having the mnemonic spelled out will help them much. They might, for instance, suspect that there could be a European or Canadian SCII. "The way computers code symbols as numbers" takes less ink and is probably much more helpful. My point is, ASCII in everyday use is really just a symbol, it roots faded from its meaning. Another excellent example is RS-232. That's a standard I've never seen; it stopped being followed as a standard long ago, and the term kept on being used to describe things that vaguely conformed to a small part of the standard. Everybody knows what you're referring to, nobody knows what the term means, and we get on fine. Just let me find that 9-pin adapter.
Jan 21 2005
parent parabolis <parabolis softhome.net> writes:
agent.smith archvillain.com wrote:
 In article <css7cg$1c78$1 digitaldaemon.com>, parabolis says...
 
You mentioned learning french which is a good example. Negation 
in french involves 3 words ne, est and pas. The french 
contradiction solution would give is=nest and not=pas. However we 
would be expecting is to remain unchanged in the affirmative or 
the negative. So you could probably get by assigning is=est and 
not=pas. However isnt is a whole new keyword which would allow 
nestpas. So without going very far away from the roots of English 
(and the only other language I have really studied) we are 
already having trouble getting everything to work out if we use 
is not.

I may have missed the point. Are we talking about creating variants of D where keywords are spelled in other languages? Wow.

It is more of an intellectual inquisition into the possibility and ramifications of creating one international D.
 For what it's worth, I think that "nest pas" (without the ')
 could be less palatable to a francophone than a simple
 foreign phrase like 'is not'. Even with my few years of high
 school French, I found that reading the language without the
 proper punctuation and accents is like reding weth rong spelyng.
 So you'd probably want to deal with that somehow.
 
 If this is the plan, then, yes, you probably want to stick
 to one token per operator. I don't see why you can't define
 token combining rules, so that the two keywords 'is' 'not'
 in english D combine to the same token which is generated
 by a single Hebrew word, but I also can see why this might
 not a good idea.

That is an interesting idea but then you have three tokens involved in the english affirmative and negative and two of them are identical - is, is and not.
 I tend to agree but - and again I'm trying to imagine what it's like-
 if I could write variable and function names in my native language
 (and not just comments) complete with diacritical marks, etc. then
 it probably makes a bigger difference. I.e. if I have to adjust to
 latin alphabet for all my identifiers, then reading a few keywords
 in latin would be no big deal. Is the plan to support unicode identifiers,
 with all that implies for linking, etc? I don't see why not - there's

http://www.digitalmars.com/d/lex.html "Identifiers start with a letter, _, or unicode alpha, and are followed by any number of letters, _, digits, or universal alphas. Universal alphas are as defined in ISO/IEC 9899:1999(E) Appendix D. (This is the C99 Standard.)"
I admit there is something compelling about the idea of a language where all
expressions are in symbolic form, so it transcends language. But you'll
still have (a) things like .length; (b) all the "bigger" keywords like 'while'
and 'public'; (c) libraries and APIs full of words. 

I am pretty sure (c) is beyond the scope of D's language spec. It is mostly (a) and (b) that concern me.

libc was beyond the C language spec initially; it still is, in some sense, but it's hard to separate the two in practice. As in my previous point, unless you translate the standard libraries, you aren't covering much of the actual namespace. But the core language should be dealt with ahead of the libraries, I guess.

Let me rephrase my concern. In the future compilers will be multi-lingual. That raises questions like how did they get that way and what does multi-lingual really mean? Are Arabic Numerals international enough or is there a need to support Roman Numerals?
And aren't we there already, to a large degree? Consider all the
nonsense words we deal with, wchar, typedef, frexp,
cdecl, ... yacc, http... it never occurred to me until right now how
little meaning they derive from language as opposed to just being
glued together from other computer words.

I think I may be the wrong person to ask. I am rather abnormal in that they all contain a great deal of meaning for me. Just recently I found myself wondering about GNU's relation to Unix but quickly solved the problem by rephrasing the question as "Is GNU Unix?".

That's Gnot the point. Do you think about that every time you read it, or do you just associate the term with the entity?

I apologize for misrepresenting what I was saying so horribly. I implied wrongly in my paraphrasing of the event that understanding this thing was GNU came before my understanding it was not Unix. I was going to share some clearer examples with you but I think I will just make the point that acronyms are useful as learning devices. Try to memorize the letters on the list (but not the order): I, A, F, N, S, B, C, A, I Knowing I made the list by scrambling the letters in fbi, cia and nsa should make learning the list simple. So then what makes for a better mnemonic than calling an statement that is executed only when the expression it comes with evaluates to a non-zero value? Well calling it an if statement is quite helpful unless you are French in which case replacing si with if aids the clarity.
Jan 21 2005
prev sibling parent "Carlos Santander B." <csantander619 gmail.com> writes:
agent.smith archvillain.com wrote:
 
 I've never programmed in a language in which the
 'words' aren't those of my native tongue, so I can only guess at
 the difficulties involved. I would suspect the concepts of programming
 easily transcend (or overwhelm) the difficulties of a few characters or a
 few syllables that aren't in the language or order you are used to -- I
 would be glad to hear from someone who can speak to this. I have worked with
 many Russian and French-speaking programmers and the topic just never came up. 
 

Only once (I mean exactly once) I had a problem with programming in language that isn't mine. I started programming when I was about 8 when my dad taught me Basic (GW-Basic). Now, Basic has (or had) the "input" keyword, but in Spanish, p's and b's can't be preceded by n's, but m's instead. So in one of my first programs I wrote "imput" (I'm also some kind of freak with grammar, at least in Spanish), and Basic obviously complained. It took me a while to know what was going on, but it's never bit me again. But if you search in old posts in the old D newsgroup, you'll find a post by me asking to have the ability to specify in what language (meaning English, Spanish, French, etc.) we wanted to code. You can laugh if you want. I do. _______________________ Carlos Santander Bernal
Jan 21 2005
prev sibling parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Georg Wrede wrote:

 We should start using a word for >= and <=, too.

No, those relate to the equality comparisons, not the identity. The identity comparators need a word to separate them from equality, since people were confusing '==' and '===' as well as '!=' and '!==' But if you really like some new words, then I suggest ≥ and ≤ ? Might as well put all that Unicode UTF-8 to some use, right :-) (☺) But "is" and "in" are plenty. Perhaps "is!" and "!in" could work. --anders
Jan 21 2005
next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Anders F Björklund wrote:
<snip>
 But "is" and "in" are plenty. Perhaps "is!" and "!in" could work.

"is!" would potentially break existing code. Stewart. -- My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Jan 21 2005
prev sibling parent reply parabolis <parabolis softhome.net> writes:
Anders F Björklund wrote:
 Georg Wrede wrote:
 
 We should start using a word for >= and <=, too.

But if you really like some new words, then I suggest ≥ and ≤ ?

I absolutely agree with this suggestion. I would further it by suggesting "≡≡" and "!≡" replace the current "is" and the proposed "isnt". After all I suspect D 2.0 will struggle with all the english based keywords in the future since Unicode support really suggests supporting multiple languages.
Jan 21 2005
parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
parabolis wrote:

 But if you really like some new words, then I suggest ≥ and ≤ ?

I absolutely agree with this suggestion. I would further it by suggesting "≡≡" and "!≡" replace the current "is"

No, not replace. As an *alternative* to the US-ASCII syntax. And that should be ≡ for '===', and ≢ for '!==' by the way. http://www.prowiki.org/wiki4d/wiki.cgi?FeatureRequestList/UnicodeOperators --anders
Jan 21 2005
parent reply Brian Chapman <nospam-for-brian see-post-for-address.net> writes:
On 2005-01-21 09:14:11 -0600, =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= 
<afb algonet.se> said:

 parabolis wrote:
 
 But if you really like some new words, then I suggest ≥ and ≤ ?

I absolutely agree with this suggestion. I would further it by suggesting "≡≡" and "!≡" replace the current "is"

No, not replace. As an *alternative* to the US-ASCII syntax. And that should be ≡ for '===', and ≢ for '!==' by the way. http://www.prowiki.org/wiki4d/wiki.cgi?FeatureRequestList/UnicodeOperators --anders

Yes I agree! I think it makes for more easily readable and compact looking code. I would love to see this.
Jan 25 2005
parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Brian Chapman wrote:

 No, not replace. As an *alternative* to the US-ASCII syntax.
 And that should be ≡ for '===', and ≢ for '!==' by the way.

 http://www.prowiki.org/wiki4d/wiki.cgi?FeatureRequestList/UnicodeOperators 

Yes I agree! I think it makes for more easily readable and compact looking code. I would love to see this.

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     ||

(printed using the following D program:)
 void main()
 {
    printf("\u225F     may be used instead of     ==\n");
    printf("\u2260     may be used instead of     !=\n");
    printf("\u2264     may be used instead of     <=\n");
    printf("\u2265     may be used instead of     >=\n");
    printf("\u2261     may be used instead of     ===\n");
    printf("\u2262     may be used instead of     !==\n");
    printf("\u2227     may be used instead of     &&\n");
    printf("\u2228     may be used instead of     ||\n");
 }

It's one way to put the UTF-8 to some use... --anders PS. Here's images, if your browser is Unicode-challenged: http://www.fileformat.info/info/unicode/char/225F/index.htm http://www.fileformat.info/info/unicode/char/2260/index.htm http://www.fileformat.info/info/unicode/char/2264/index.htm http://www.fileformat.info/info/unicode/char/2265/index.htm http://www.fileformat.info/info/unicode/char/2261/index.htm http://www.fileformat.info/info/unicode/char/2262/index.htm http://www.fileformat.info/info/unicode/char/2227/index.htm http://www.fileformat.info/info/unicode/char/2228/index.htm
Jan 25 2005
parent reply parabolis <parabolis softhome.net> writes:
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.
Jan 25 2005
parent reply Georg Wrede <georg.wrede nospam.org> writes:
(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.

Jan 26 2005
parent =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
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.
Jan 27 2005