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.


The only problem is that *there is no boolean*...
(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.


So bit is the boolean type, and conversions a bit shady.


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


In C, it doesn't matter whether all-zero pattern is used. The compiler
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:


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







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:







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


Really? but I'm not allowed to do this in D:
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.





















 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.






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:





if you have to use it in several places, so.. what about:







 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.



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 '!=='




 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.


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.


What problem?
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