• Matthew (16/16) Jul 22 2004 While I like the use of is - for one thing, I can reorder the expression...
• Sean Kelly (4/12) Jul 22 2004 I agree. Having to add an extra layer of perens just to use 'is' in
• Andy Friesen (6/18) Jul 22 2004 Please! 'not in' and unary 'not' would be nice too.
• Derek Parnell (10/39) Jul 22 2004 Too obvious!
• Arcane Jill (6/8) Jul 23 2004 No-one's mentioned the word isn't yet. (Without the apostrophe: isnt).
• Kris (14/30) Jul 22 2004 Know wot' u mean guv', but "is not" seems a tad verbose, whereas:
• James McComb (6/8) Jul 22 2004 You are forgiven. ;)
• Ben Hinkle (4/58) Jul 22 2004 I don't think that was me... but I like it, too ;-)
• Sean Kelly (3/12) Jul 22 2004 That's pure genius :)
• James McComb (10/11) Jul 22 2004 +1 for the isnot keyword as a direct replacement for !==.
• Andy Friesen (5/22) Jul 22 2004 I highly doubt this would be an issue. Almost everybody is going to do
• James McComb (5/16) Jul 22 2004 Unless with Visual Basic they code:
• Berin Loritsch (9/14) Jul 23 2004 Hmmm. Then if like Yoda they talk, example here it is:
• Matthew (4/15) Jul 22 2004 Only this one. If not is a separate word, and is a keyword modifier, it'...
• Berin Loritsch (5/9) Jul 23 2004 I personally like the is and not being separate, but not combinable,
• Paolo Invernizzi (13/23) Jul 22 2004 One of the most important python goal is readability...
• Matthew (3/26) Jul 23 2004 I agree that "is not" is the most desirable form. I don't think anyone w...
• Kris (7/9) Jul 23 2004 would (seriously) disagree with that. But D is
• J C Calvarese (7/22) Jul 23 2004 Actually, "isnuttin" is the best!
• Kris (5/8) Jul 23 2004 James ought to get some kind of medal for that one ~ it's priceless
• J C Calvarese (5/20) Jul 23 2004 I think in Ebonics it's either "benot" or "beaint", but I'm not certain.
• Berin Loritsch (5/26) Jul 26 2004 You can't keep up with ebonics, it changes to fast. The last
• Russ Lewis (11/13) Jul 23 2004 If we were writing a brand-new language from scratch, then I would agree...
• Andy Friesen (12/33) Jul 23 2004 The C-like way is !==. :)
• Berin Loritsch (39/53) Jul 23 2004 Well, the C-like way is simply !=, but D uses !== and ===. So is there
• Andy Friesen (16/42) Jul 23 2004 If you want to be mathematical, = should always be about testing for
• Matthew (2/55) Jul 23 2004
• Russ Lewis (9/21) Jul 23 2004 Sure, the lexer can handle it. It's not an issue of memory, or compiler...
• Andy Friesen (14/38) Jul 23 2004 IF hkey were an integral type, (hkey is (!reference)) would compile, and...
• Russ Lewis (6/10) Jul 23 2004 Isn't the phrase "has to deduce" proof positive that the code is not
• Andy Friesen (16/29) Jul 23 2004 Not at all.
• Matthew (7/20) Jul 23 2004 Walter.
• Hauke Duden (5/38) Jul 23 2004 I agree that !(a is b) is cumbersome.
• Kris (12/50) Jul 23 2004 Leading on from that Hauke, what about this:
• Matthew (3/57) Jul 23 2004 No
• Matthew (4/42) Jul 23 2004 inconsistent
• Ilya Minkov (2/8) Jul 23 2004 I'd vote for !is!
• Ben Hinkle (9/25) Jul 23 2004 to read more naturally, i.e. "hkey is null"
• James McComb (4/6) Jul 23 2004 The word "typedef" isn't a word either. I don't suppose you want Walter
• Ben Hinkle (8/13) Jul 23 2004 no, I don't. There isn't a contraction of "type" and "definition" so
• Regan Heath (11/16) Jul 24 2004 To be fair, you're commiting the "Strawman" here:
• Arcane Jill (5/7) Jul 25 2004 So how come no-one's mentioned the possibility of "isNot" yet?
• J C Calvarese (9/22) Jul 25 2004 Capitalization of the second word never even occurred to me.
• h3r3tic (3/7) Jul 25 2004 isnot is faster to type than isNot
• Matthew (2/40) Jul 23 2004 If you want to be pedantic, the word "isnt" doesn't exist.
• Sha Chancellor (6/40) Jul 23 2004 Why don't i see === on the expressions page? What would be the
• J C Calvarese (52/61) Jul 23 2004 The documentation is incomplete. Basically, "====" has the same purpose

"Matthew" <admin.hat stlsoft.dot.org> writes:

While I like the use of is - for one thing, I can reorder the expression to
read more naturally, i.e. "hkey is null"
rather than "null === hkey" - I don't like the need to ! the expression.

Presumably the reason for preferring "is" over "===" is that it reads better,
which it does in the === case.

    "hkey is null"

is better than

    "hkey === null"

But it seems a starkyl retrograde step to have write "!(hkey is null)" instead
of "hkey !== null"

    "hkey !== null"

is (much!) better than

    "!(hkey is null)"

So, if "!(hkey is null)" is not to people's tastes, as I suggest is the case,
then we might end up with an inconsistent
use of "is" for null, and "!==" for not null. That is not good.

I suggest that, either:

(i) we have the keyword modifier "not", as in "hkey is not null", or have an
isnot keyword, as in "hkey isnot null", or

(ii) forget about is for testing null-ness.

Thoughts?

Sean Kelly <sean f4.ca> writes:

Matthew wrote:

 I suggest that, either:
 
 (i) we have the keyword modifier "not", as in "hkey is not null", or have an
isnot keyword, as in "hkey isnot null", or
 
 (ii) forget about is for testing null-ness.
 
 Thoughts?

I agree.  Having to add an extra layer of perens just to use 'is' in 
these situations seems silly.  Whichever of the above would be easier to 
parse has my vote.


Sean

Andy Friesen <andy ikagames.com> writes:

Matthew wrote:

 While I like the use of is - for one thing, I can reorder the expression to
read more naturally, i.e. "hkey is null"
 rather than "null === hkey" - I don't like the need to ! the expression.
 
 Presumably the reason for preferring "is" over "===" is that it reads better,
which it does in the === case.
 
 I suggest that, either:
 
 (i) we have the keyword modifier "not", as in "hkey is not null", or have an
isnot keyword, as in "hkey isnot null", or
 
 (ii) forget about is for testing null-ness.
 
 Thoughts?

Please!  'not in' and unary 'not' would be nice too.

The price we pay, having an operator with embedded whitespace, seems 
well worth the trouble for having syntax which is self-evident to 
anybody, whether or not they have even heard of the language.

  -- andy

Derek Parnell <derek psych.ward> writes:

On Fri, 23 Jul 2004 11:27:44 +1000, Matthew wrote:

 While I like the use of is - for one thing, I can reorder the expression to
read more naturally, i.e. "hkey is null"
 rather than "null === hkey" - I don't like the need to ! the expression.
 
 Presumably the reason for preferring "is" over "===" is that it reads better,
which it does in the === case.
 
     "hkey is null"
 
 is better than
 
     "hkey === null"
 
 But it seems a starkyl retrograde step to have write "!(hkey is null)" instead
of "hkey !== null"
 
     "hkey !== null"
 
 is (much!) better than
 
     "!(hkey is null)"
 
 So, if "!(hkey is null)" is not to people's tastes, as I suggest is the case,
then we might end up with an inconsistent
 use of "is" for null, and "!==" for not null. That is not good.
 
 I suggest that, either:
 
 (i) we have the keyword modifier "not", as in "hkey is not null", or have an
isnot keyword, as in "hkey isnot null", or
 
 (ii) forget about is for testing null-ness.
 
 Thoughts?

Too obvious! 

For our younger coders this really should be "(hkey is null) not!" ;-)

Joking aside, this is a reasonable suggestion, if only for consistancy
sake. I think I prefer the "is not" over "isnot". Readability should be one
of the goals for a programming language.

-- 
Derek
Melbourne, Australia
23/Jul/04 11:52:58 AM

Arcane Jill <Arcane_member pathlink.com> writes:

In article <cdprbu$1av0$1 digitaldaemon.com>, Derek Parnell says...

I think I prefer the "is not" over "isnot". Readability should be one
of the goals for a programming language.

No-one's mentioned the word isn't yet. (Without the apostrophe: isnt).



I don't like "isnot". My somewhat overindulged in toilet humor brain puts the
word-break in the wrong place.

Arcane Jill

"Kris" <someidiot earthlink.dot.dot.dot.net> writes:

Know wot' u mean guv', but "is not" seems a tad verbose, whereas:

if (x not null)

sounds fine to me (D "is not" COBOL :~)

However, I think the best suggestion was put forward by Ben:

if (x AINT null)

<g>

(forgive me if I attributed that beauty to the wrong person)


"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:cdppih$1ab1$1 digitaldaemon.com...
 While I like the use of is - for one thing, I can reorder the expression

to read more naturally, i.e. "hkey is null"
 rather than "null === hkey" - I don't like the need to ! the expression.

 Presumably the reason for preferring "is" over "===" is that it reads

better, which it does in the === case.
     "hkey is null"

 is better than

     "hkey === null"

 But it seems a starkyl retrograde step to have write "!(hkey is null)"

instead of "hkey !== null"
     "hkey !== null"

 is (much!) better than

     "!(hkey is null)"

 So, if "!(hkey is null)" is not to people's tastes, as I suggest is the

case, then we might end up with an inconsistent
 use of "is" for null, and "!==" for not null. That is not good.

 I suggest that, either:

 (i) we have the keyword modifier "not", as in "hkey is not null", or have

an isnot keyword, as in "hkey isnot null", or
 (ii) forget about is for testing null-ness.

 Thoughts?

James McComb <alan jamesmccomb.id.au> writes:

Kris wrote:

 if (x AINT null)

Hey! I already made that suggestion!

 (forgive me if I attributed that beauty to the wrong person)

You are forgiven. ;)

Just to confuse the parser even more, my suggested ain't keyword has an 
apostrophe in it.

James McComb

Ben Hinkle <bhinkle4 juno.com> writes:

Kris wrote:

 Know wot' u mean guv', but "is not" seems a tad verbose, whereas:
 
 if (x not null)
 
 sounds fine to me (D "is not" COBOL :~)
 
 However, I think the best suggestion was put forward by Ben:
 
 if (x AINT null)
 
 <g>
 
 (forgive me if I attributed that beauty to the wrong person)

I don't think that was me... but I like it, too ;-)

 
 
 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
 news:cdppih$1ab1$1 digitaldaemon.com...
 While I like the use of is - for one thing, I can reorder the expression

 to read more naturally, i.e. "hkey is null"
 rather than "null === hkey" - I don't like the need to ! the expression.

 Presumably the reason for preferring "is" over "===" is that it reads

 better, which it does in the === case.
     "hkey is null"

 is better than

     "hkey === null"

 But it seems a starkyl retrograde step to have write "!(hkey is null)"

 instead of "hkey !== null"
     "hkey !== null"

 is (much!) better than

     "!(hkey is null)"

 So, if "!(hkey is null)" is not to people's tastes, as I suggest is the

 case, then we might end up with an inconsistent
 use of "is" for null, and "!==" for not null. That is not good.

 I suggest that, either:

 (i) we have the keyword modifier "not", as in "hkey is not null", or have

 an isnot keyword, as in "hkey isnot null", or

isnot, yousnot, we all snot for isnot

 (ii) forget about is for testing null-ness.

 Thoughts?

Sean Kelly <sean f4.ca> writes:

Kris wrote:

 Know wot' u mean guv', but "is not" seems a tad verbose, whereas:
 
 if (x not null)
 
 sounds fine to me (D "is not" COBOL :~)
 
 However, I think the best suggestion was put forward by Ben:
 
 if (x AINT null)

That's pure genius :)


Sean

James McComb <alan jamesmccomb.id.au> writes:

Matthew wrote:

 (i) we have the keyword modifier "not", as in "hkey is not null", or have an
isnot keyword, as in "hkey isnot null", or

+1 for the isnot keyword as a direct replacement for !==.

Please don't introduce a separate not keyword, because newbies will be 
confused about when they should and shouldn't use it. For example, which 
of the following should be legal:

a. if (a is not null)
b. if (a not is null)
c. if not (a is null) etc.

isnot has less potential for confusion.

James McComb

Andy Friesen <andy ikagames.com> writes:

James McComb wrote:
 Matthew wrote:
 
 (i) we have the keyword modifier "not", as in "hkey is not null", or 
 have an isnot keyword, as in "hkey isnot null", or

 
 
 +1 for the isnot keyword as a direct replacement for !==.
 
 Please don't introduce a separate not keyword, because newbies will be 
 confused about when they should and shouldn't use it. For example, which 
 of the following should be legal:
 
 a. if (a is not null)
 b. if (a not is null)
 c. if not (a is null) etc.
 
 isnot has less potential for confusion.

I highly doubt this would be an issue.  Almost everybody is going to do 
the most obvious that comes to mind: write it out like plain old English.

Unless like Yoda they talk, correct will they be!

  -- andy

James McComb <alan jamesmccomb.id.au> writes:

Andy Friesen wrote:

 a. if (a is not null)
 b. if (a not is null)
 c. if not (a is null) etc.

 isnot has less potential for confusion.

 
 
 I highly doubt this would be an issue.  Almost everybody is going to do 
 the most obvious that comes to mind: write it out like plain old English.
 
 Unless like Yoda they talk, correct will they be!

Unless with Visual Basic they code:
   If Not X Is Nothing Then
   If Not IsNull(X) Then

James McComb

Berin Loritsch <bloritsch d-haven.org> writes:

Andy Friesen wrote:
 
 I highly doubt this would be an issue.  Almost everybody is going to do 
 the most obvious that comes to mind: write it out like plain old English.
 
 Unless like Yoda they talk, correct will they be!


Hmmm.  Then if like Yoda they talk, example here it is:

if ( null hkey is not )
{
}

Reminiscent of inverse polish notation...

3 4 +

= 7

It would be hard for me to program that way consistently :)

"Matthew" <admin.hat stlsoft.dot.org> writes:

"James McComb" <alan jamesmccomb.id.au> wrote in message
news:cdptfp$1but$1 digitaldaemon.com...
 Matthew wrote:

 (i) we have the keyword modifier "not", as in "hkey is not null", or have an
isnot keyword, as in "hkey isnot null",


or
 +1 for the isnot keyword as a direct replacement for !==.

 Please don't introduce a separate not keyword, because newbies will be
 confused about when they should and shouldn't use it. For example, which
 of the following should be legal:

 a. if (a is not null)

Only this one. If not is a separate word, and is a keyword modifier, it'd only
be in concert with is.

For me, though, I would rather it be isnot, as this cuts down on the parsing
hassles

 b. if (a not is null)
 c. if not (a is null) etc.

 isnot has less potential for confusion.

 James McComb

Berin Loritsch <bloritsch d-haven.org> writes:

Matthew wrote:

 
 Only this one. If not is a separate word, and is a keyword modifier, it'd only
be in concert with is.
 
 For me, though, I would rather it be isnot, as this cuts down on the parsing
hassles

I personally like the is and not being separate, but not combinable, 
keywords:

if (null not hkey)
if (null is hkey)

Paolo Invernizzi <arathorn NOSPAM_fastwebnet.it> writes:

James McComb wrote:

 a. if (a is not null)
 b. if (a not is null)
 c. if not (a is null) etc.
 
 isnot has less potential for confusion.

One of the most important python goal is readability...


win32
Type "help", "copyright", "credits" or "license" for more information.
 a = 1
 a is not None



True
 a not is None



   File "<stdin>", line 1
     a not is None
            ^
SyntaxError: invalid syntax
 not (a is None)



True



---
Paolo Invernizzi

"Matthew" <admin.hat stlsoft.dot.org> writes:

I agree that "is not" is the most desirable form. I don't think anyone would
(seriously) disagree with that. But D is
specifically designed to be easy to implement, so I am prepared to go for
"isnot" if that makes it acceptable to Walter.




"Paolo Invernizzi" <arathorn NOSPAM_fastwebnet.it> wrote in message
news:cdqcds$1j3c$1 digitaldaemon.com...
 James McComb wrote:

 a. if (a is not null)
 b. if (a not is null)
 c. if not (a is null) etc.

 isnot has less potential for confusion.

 One of the most important python goal is readability...


 win32
 Type "help", "copyright", "credits" or "license" for more information.
  >>> a = 1
  >>> a is not None
 True
  >>> a not is None
    File "<stdin>", line 1
      a not is None
             ^
 SyntaxError: invalid syntax
  >>> not (a is None)
 True
  >>>

 ---
 Paolo Invernizzi

"Kris" <someidiot earthlink.dot.dot.dot.net> writes:

"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:cdqeaj$1kjh$1 digitaldaemon.com...
 I agree that "is not" is the most desirable form. I don't think anyone

would (seriously) disagree with that. But D is
 specifically designed to be easy to implement, so I am prepared to go for

"isnot" if that makes it acceptable to Walter.

What? You don't think Walter would go for "aint" ?
D would enter the halls of notoriety overnight!

:-)

J C Calvarese <jcc7 cox.net> writes:

Kris wrote:
 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
 news:cdqeaj$1kjh$1 digitaldaemon.com...
 
I agree that "is not" is the most desirable form. I don't think anyone

 
 would (seriously) disagree with that. But D is
 
specifically designed to be easy to implement, so I am prepared to go for

 
 "isnot" if that makes it acceptable to Walter.
 
 What? You don't think Walter would go for "aint" ?
 D would enter the halls of notoriety overnight!
 
 :-)

Actually, "isnuttin" is the best!

Hmmm, on second thought, it's a tad verbose.

OK, "aint" it is!

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

"Kris" <someidiot earthlink.dot.dot.dot.net> writes:

"J C Calvarese"  wrote ...
 Actually, "isnuttin" is the best!

 Hmmm, on second thought, it's a tad verbose.

 OK, "aint" it is!

James ought to get some kind of medal for that one ~ it's priceless <g>

I'd lay a bet it's part of the Ebonics Computer Science curriculum in
Oakland ... (that's "Political Correctness Meets Lunacy" for those who ain't
familiar).

J C Calvarese <jcc7 cox.net> writes:

Kris wrote:
 "J C Calvarese"  wrote ...
 
Actually, "isnuttin" is the best!

Hmmm, on second thought, it's a tad verbose.

OK, "aint" it is!

 
 
 James ought to get some kind of medal for that one ~ it's priceless <g>
 
 I'd lay a bet it's part of the Ebonics Computer Science curriculum in
 Oakland ... (that's "Political Correctness Meets Lunacy" for those who ain't
 familiar).

I think in Ebonics it's either "benot" or "beaint", but I'm not certain.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

Berin Loritsch <bloritsch d-haven.org> writes:

J C Calvarese wrote:

 Kris wrote:
 
 "J C Calvarese"  wrote ...

 Actually, "isnuttin" is the best!

 Hmmm, on second thought, it's a tad verbose.

 OK, "aint" it is!


 James ought to get some kind of medal for that one ~ it's priceless <g>

 I'd lay a bet it's part of the Ebonics Computer Science curriculum in
 Oakland ... (that's "Political Correctness Meets Lunacy" for those who 
 ain't
 familiar).

 
 
 I think in Ebonics it's either "benot" or "beaint", but I'm not certain.

You can't keep up with ebonics, it changes to fast.  The last
approximately close way to express it I can recall is:

if ( null not_bout_it_bout_it hkey )

bout it == about it

Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:

Matthew wrote:
 I agree that "is not" is the most desirable form. I don't think anyone would
(seriously) disagree with that. But D is
 specifically designed to be easy to implement, so I am prepared to go for
"isnot" if that makes it acceptable to Walter.

If we were writing a brand-new language from scratch, then I would agree 
with you.  But "is not" violates some of the basic assumptions of 
C/C++/D (namely, that operators are a single word).  Thus, I would argue 
that in the context of this language, "is not" is one of the LEAST 
readable options.

If we want to make a language that is English readable, then we really 
need to start over from scratch.  If we want to have a language in the 
C/C++ family, then we should stick to that family's conventions.

As such, I propose the operator
	!is

Andy Friesen <andy ikagames.com> writes:

Russ Lewis wrote:
 Matthew wrote:
 
 I agree that "is not" is the most desirable form. I don't think anyone 
 would (seriously) disagree with that. But D is
 specifically designed to be easy to implement, so I am prepared to go 
 for "isnot" if that makes it acceptable to Walter.

 
 
 If we were writing a brand-new language from scratch, then I would agree 
 with you.  But "is not" violates some of the basic assumptions of 
 C/C++/D (namely, that operators are a single word).  Thus, I would argue 
 that in the context of this language, "is not" is one of the LEAST 
 readable options.
 
 If we want to make a language that is English readable, then we really 
 need to start over from scratch.  If we want to have a language in the 
 C/C++ family, then we should stick to that family's conventions.
 
 As such, I propose the operator
     !is
 

The C-like way is !==. :)

'is not' may break some traditional C ideas, but times have changed, and 
those ideas aren't necessarily as good an idea now as they were when C 
was written.  There's enough memory to hold that extra bit of code 
needed to parse 'is not' as a single operator, and I doubt there are 
many programmers who are so stuck on C-like syntax that they won't 
recognize 'is not' for what it is.

As for implementation difficulty, it wouldn't be too bad.  It can be 
handled entirely within the lexer, though it does look like the DMD 
lexer isn't at all built with the notion in mind.

  -- andy

Berin Loritsch <bloritsch d-haven.org> writes:

Andy Friesen wrote:

 
 The C-like way is !==. :)

Well, the C-like way is simply !=, but D uses !== and ===.  So is there
some difference between assignment, equality checking, and something 
else?  I've always wondered about the extra '=' sign.

 
 'is not' may break some traditional C ideas, but times have changed, and 
 those ideas aren't necessarily as good an idea now as they were when C 
 was written.  There's enough memory to hold that extra bit of code 
 needed to parse 'is not' as a single operator, and I doubt there are 
 many programmers who are so stuck on C-like syntax that they won't 
 recognize 'is not' for what it is.

There is nothing to stop anyone from doing a template like function:

//english
if (is_not(null, hkey))
if (is(null,hkey))

//spanish
if (no_es(null, hkey))
if (es(null, hkey))

//japanese (romanji)
if ( dewa_arimasen(null,hkey) )
if ( desu(null,hkey) )

The question comes, are we trying to use mathematical notation (i.e. C 


Arguing over "not", "isnot", "isnt", etc. is essentially arguing which 
is the best color for the community bikeshed.  It's all a matter of 
preference.

The only time I have seen abreviation is when words are long.  So 
arguing for "isnt" based on "typedef" is a little auspiscious to me.

What's wrong with digging back to assembly roots and use the branch
variants (without the preceding 'b'):

ne == not equal
eq == equal
gt == greater than
lt == less than
ge == greater than or equal
le == less than or equal

Of course, then you can get into a more powerful "alias" feature that 
would allow you to map any expression to a single name and use it
identically:

alias != no_es;

if ( null no_es hkey )

However, that can lead things wide open to abuse, and the need to
understand the "language" within a language.  But, it would give you
"aint" for those who like that, and possibly something internationalized
for your own shop.

 
 As for implementation difficulty, it wouldn't be too bad.  It can be 
 handled entirely within the lexer, though it does look like the DMD 
 lexer isn't at all built with the notion in mind.
 

:)  The devil is in the details.

Andy Friesen <andy ikagames.com> writes:

Berin Loritsch wrote:

 Andy Friesen wrote:
 
 The C-like way is !==. :)

 
 
 Well, the C-like way is simply !=, but D uses !== and ===.  So is there
 some difference between assignment, equality checking, and something 
 else?  I've always wondered about the extra '=' sign.

If you want to be mathematical, = should always be about testing for 
equivalence.  Functional languages take this approach, using <- (usually 
read as 'recieves') for assignment.

The extra = sign is probably just the result of Brian Kernigan thinking 
on his feet. :)

 'is not' may break some traditional C ideas, but times have changed, 
 and those ideas aren't necessarily as good an idea now as they were 
 when C was written.  There's enough memory to hold that extra bit of 
 code needed to parse 'is not' as a single operator, and I doubt there 
 are many programmers who are so stuck on C-like syntax that they won't 
 recognize 'is not' for what it is.

 
 The question comes, are we trying to use mathematical notation (i.e. C 


Object identity isn't a mathematical concept, so I don't see why we 
should be constrained to a mathematical notation.

 What's wrong with digging back to assembly roots and use the branch
 variants (without the preceding 'b'):

It's much more artificial looking.  Details like this are, I think, a 
major factor in Python's elegance. (second only to the fast pace of 
development it enables by not needing a compile phase)

As a native English speaker, I haven't the slightest clue how much of a 
problem it is for a non-English speaker to use a 'wordy' language like 
Python.

 As for implementation difficulty, it wouldn't be too bad.  It can be 
 handled entirely within the lexer, though it does look like the DMD 
 lexer isn't at all built with the notion in mind.

 
 :)  The devil is in the details.

He's also writing the compiler, so we'd best appease him. ;)

  -- andy

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

"Berin Loritsch" <bloritsch d-haven.org> wrote in message
news:cdrikd$27sq$1 digitaldaemon.com...
 Andy Friesen wrote:

 The C-like way is !==. :)

 Well, the C-like way is simply !=, but D uses !== and ===.  So is there
 some difference between assignment, equality checking, and something
 else?  I've always wondered about the extra '=' sign.

 'is not' may break some traditional C ideas, but times have changed, and
 those ideas aren't necessarily as good an idea now as they were when C
 was written.  There's enough memory to hold that extra bit of code
 needed to parse 'is not' as a single operator, and I doubt there are
 many programmers who are so stuck on C-like syntax that they won't
 recognize 'is not' for what it is.

 There is nothing to stop anyone from doing a template like function:

Yes there is: there's no implicit instantiation, and there're no macros!

 //english
 if (is_not(null, hkey))
 if (is(null,hkey))

 //spanish
 if (no_es(null, hkey))
 if (es(null, hkey))

 //japanese (romanji)
 if ( dewa_arimasen(null,hkey) )
 if ( desu(null,hkey) )

 The question comes, are we trying to use mathematical notation (i.e. C


 Arguing over "not", "isnot", "isnt", etc. is essentially arguing which
 is the best color for the community bikeshed.  It's all a matter of
 preference.

 The only time I have seen abreviation is when words are long.  So
 arguing for "isnt" based on "typedef" is a little auspiscious to me.

 What's wrong with digging back to assembly roots and use the branch
 variants (without the preceding 'b'):

 ne == not equal
 eq == equal
 gt == greater than
 lt == less than
 ge == greater than or equal
 le == less than or equal

 Of course, then you can get into a more powerful "alias" feature that
 would allow you to map any expression to a single name and use it
 identically:

 alias != no_es;

 if ( null no_es hkey )

 However, that can lead things wide open to abuse, and the need to
 understand the "language" within a language.  But, it would give you
 "aint" for those who like that, and possibly something internationalized
 for your own shop.

 As for implementation difficulty, it wouldn't be too bad.  It can be
 handled entirely within the lexer, though it does look like the DMD
 lexer isn't at all built with the notion in mind.

 :)  The devil is in the details.

Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:

Andy Friesen wrote:
 The C-like way is !==. :)
 
 'is not' may break some traditional C ideas, but times have changed, and 
 those ideas aren't necessarily as good an idea now as they were when C 
 was written.  There's enough memory to hold that extra bit of code 
 needed to parse 'is not' as a single operator, and I doubt there are 
 many programmers who are so stuck on C-like syntax that they won't 
 recognize 'is not' for what it is.
 
 As for implementation difficulty, it wouldn't be too bad.  It can be 
 handled entirely within the lexer, though it does look like the DMD 
 lexer isn't at all built with the notion in mind.

Sure, the lexer can handle it.  It's not an issue of memory, or compiler 
complexity.  I just think that many C people will see
   if(hkey is not null)
and will read it as
   if(hkey is (! null))
or
   if(hkey is (~ null))
that sort of thing does NOT improve readability.

Andy Friesen <andy ikagames.com> writes:

Russ Lewis wrote:
 Andy Friesen wrote:
 
 The C-like way is !==. :)

 'is not' may break some traditional C ideas, but times have changed, 
 and those ideas aren't necessarily as good an idea now as they were 
 when C was written.  There's enough memory to hold that extra bit of 
 code needed to parse 'is not' as a single operator, and I doubt there 
 are many programmers who are so stuck on C-like syntax that they won't 
 recognize 'is not' for what it is.

 As for implementation difficulty, it wouldn't be too bad.  It can be 
 handled entirely within the lexer, though it does look like the DMD 
 lexer isn't at all built with the notion in mind.

 
 
 Sure, the lexer can handle it.  It's not an issue of memory, or compiler 
 complexity.  I just think that many C people will see
   if(hkey is not null)
 and will read it as
   if(hkey is (! null))
 or
   if(hkey is (~ null))
 that sort of thing does NOT improve readability.

IF hkey were an integral type, (hkey is (!reference)) would compile, and 
be equivalent to (hkey == ((reference is null) ? 0 : 1)).  ('is' and == 
are synonymous if 'reference' is a value type)

The expression (hkey is (~reference)) is only even legal if 'reference' 
is also an integral type, in which case it is the same as 
(hkey==~reference).

I can't ever see any programmer ever thinking either expression the 
simplest way to express the condition.  (obfuscated D contests don't count!)

In summary, a programmer reading the statement "if (hkey is not null)" 
has to deduce whether this is an esoteric contortion of the language 
syntax, or an extremely common idiom that is used constantly in programs 
and everyday speech alike.

  -- andy

Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:

Andy Friesen wrote:
 In summary, a programmer reading the statement "if (hkey is not null)" 
 has to deduce whether this is an esoteric contortion of the language 
 syntax, or an extremely common idiom that is used constantly in programs 
 and everyday speech alike.

Isn't the phrase "has to deduce" proof positive that the code is not 
easily readable?

Things get worse if you aren't comparing against null.  What about this 
code:
   if(hkey is not other_hkey)

Andy Friesen <andy ikagames.com> writes:

Russ Lewis wrote:
 Andy Friesen wrote:
 
 In summary, a programmer reading the statement "if (hkey is not null)" 
 has to deduce whether this is an esoteric contortion of the language 
 syntax, or an extremely common idiom that is used constantly in 
 programs and everyday speech alike.

 
 
 Isn't the phrase "has to deduce" proof positive that the code is not 
 easily readable?

Not at all.

One possibility is strange, not commonly useful at all, and would, in 
almost all cases, not even make sense given context.

The other is the complete opposite in every way: it's an extremely 
common, simply understood idiom between two nouns.  Moreover, English 
uses exactly the same idiom to express exactly the same sort of 
relationship.  It seems *extremely* unlikely to me that anybody would 
interpret it any other way, especially at first glance.

Python has used this exact syntax for years now, and I have never heard 
of anybody ever having problems with it.  If it were a complication, it 
would have been removed a long, long time ago. (simplicity has always 
been one of Python's biggest selling points)

 Things get worse if you aren't comparing against null.  What about this 
 code:
   if(hkey is not other_hkey)

There's only one way to read it.  'if (hkey is (not other_hkey))' 
doesn't make enough sense to even register.

  -- andy

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:cdra0p$23n0$1 digitaldaemon.com...
 Matthew wrote:
 I agree that "is not" is the most desirable form. I don't think anyone would
(seriously) disagree with that. But D


is
 specifically designed to be easy to implement, so I am prepared to go for
"isnot" if that makes it acceptable to


Walter.
 If we were writing a brand-new language from scratch, then I would agree
 with you.  But "is not" violates some of the basic assumptions of
 C/C++/D (namely, that operators are a single word).  Thus, I would argue
 that in the context of this language, "is not" is one of the LEAST
 readable options.

 If we want to make a language that is English readable, then we really
 need to start over from scratch.  If we want to have a language in the
 C/C++ family, then we should stick to that family's conventions.

While I don't agree, I'm not particularly against what you say above.

 As such, I propose the operator
 !is

I am very much against this. This seems to me a very bad idea, i.e. mixing a
word and an operator. If we have the "!"
we're better off having the "==" as well.

But that's just my opinion

Hauke Duden <H.NS.Duden gmx.net> writes:

I agree that !(a is b) is cumbersome.

"is not" would be better. Or maybe something more similar to the normal 
D syntax?

What about a !is b ?


Matthew wrote:
 While I like the use of is - for one thing, I can reorder the expression to
read more naturally, i.e. "hkey is null"
 rather than "null === hkey" - I don't like the need to ! the expression.
 
 Presumably the reason for preferring "is" over "===" is that it reads better,
which it does in the === case.
 
     "hkey is null"
 
 is better than
 
     "hkey === null"
 
 But it seems a starkyl retrograde step to have write "!(hkey is null)" instead
of "hkey !== null"
 
     "hkey !== null"
 
 is (much!) better than
 
     "!(hkey is null)"
 
 So, if "!(hkey is null)" is not to people's tastes, as I suggest is the case,
then we might end up with an inconsistent
 use of "is" for null, and "!==" for not null. That is not good.
 
 I suggest that, either:
 
 (i) we have the keyword modifier "not", as in "hkey is not null", or have an
isnot keyword, as in "hkey isnot null", or
 
 (ii) forget about is for testing null-ness.
 
 Thoughts?
 
 
 
 

"Kris" <someidiot earthlink.dot.dot.dot.net> writes:

Leading on from that Hauke, what about this:

if (a ! b)

A bit terse perhaps? Maybe conflicts with a template identifier? Might cause
issues where an '=' was not typed by mistake?

Regardless; is this notion another candidate for an operator overload?


"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:cdqhnh$1m2l$1 digitaldaemon.com...
 I agree that !(a is b) is cumbersome.

 "is not" would be better. Or maybe something more similar to the normal
 D syntax?

 What about a !is b ?


 Matthew wrote:
 While I like the use of is - for one thing, I can reorder the expression


to read more naturally, i.e. "hkey is null"
 rather than "null === hkey" - I don't like the need to ! the expression.

 Presumably the reason for preferring "is" over "===" is that it reads


better, which it does in the === case.
     "hkey is null"

 is better than

     "hkey === null"

 But it seems a starkyl retrograde step to have write "!(hkey is null)"


instead of "hkey !== null"
     "hkey !== null"

 is (much!) better than

     "!(hkey is null)"

 So, if "!(hkey is null)" is not to people's tastes, as I suggest is the


case, then we might end up with an inconsistent
 use of "is" for null, and "!==" for not null. That is not good.

 I suggest that, either:

 (i) we have the keyword modifier "not", as in "hkey is not null", or


have an isnot keyword, as in "hkey isnot null", or
 (ii) forget about is for testing null-ness.

 Thoughts?

"Matthew" <admin.hat stlsoft.dot.org> writes:

"Kris" <someidiot earthlink.dot.dot.dot.net> wrote in message
news:cdqifu$1mcn$1 digitaldaemon.com...
 Leading on from that Hauke, what about this:

 if (a ! b)

Not obvious enough, sorry

 A bit terse perhaps? Maybe conflicts with a template identifier? Might cause
 issues where an '=' was not typed by mistake?

 Regardless; is this notion another candidate for an operator overload?

No

 "Hauke Duden" <H.NS.Duden gmx.net> wrote in message
 news:cdqhnh$1m2l$1 digitaldaemon.com...
 I agree that !(a is b) is cumbersome.

 "is not" would be better. Or maybe something more similar to the normal
 D syntax?

 What about a !is b ?


 Matthew wrote:
 While I like the use of is - for one thing, I can reorder the expression


 to read more naturally, i.e. "hkey is null"
 rather than "null === hkey" - I don't like the need to ! the expression.

 Presumably the reason for preferring "is" over "===" is that it reads


 better, which it does in the === case.
     "hkey is null"

 is better than

     "hkey === null"

 But it seems a starkyl retrograde step to have write "!(hkey is null)"


 instead of "hkey !== null"
     "hkey !== null"

 is (much!) better than

     "!(hkey is null)"

 So, if "!(hkey is null)" is not to people's tastes, as I suggest is the


 case, then we might end up with an inconsistent
 use of "is" for null, and "!==" for not null. That is not good.

 I suggest that, either:

 (i) we have the keyword modifier "not", as in "hkey is not null", or


 have an isnot keyword, as in "hkey isnot null", or
 (ii) forget about is for testing null-ness.

 Thoughts?

"Matthew" <admin.hat stlsoft.dot.org> writes:

"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:cdqhnh$1m2l$1 digitaldaemon.com...
 I agree that !(a is b) is cumbersome.

 "is not" would be better. Or maybe something more similar to the normal
 D syntax?

 What about a !is b ?

It's a mix of a word and an operator. I think one or the other is best. Just my
opinion

 Matthew wrote:
 While I like the use of is - for one thing, I can reorder the expression to
read more naturally, i.e. "hkey is null"
 rather than "null === hkey" - I don't like the need to ! the expression.

 Presumably the reason for preferring "is" over "===" is that it reads better,
which it does in the === case.

     "hkey is null"

 is better than

     "hkey === null"

 But it seems a starkyl retrograde step to have write "!(hkey is null)" instead
of "hkey !== null"

     "hkey !== null"

 is (much!) better than

     "!(hkey is null)"

 So, if "!(hkey is null)" is not to people's tastes, as I suggest is the case,
then we might end up with an


inconsistent
 use of "is" for null, and "!==" for not null. That is not good.

 I suggest that, either:

 (i) we have the keyword modifier "not", as in "hkey is not null", or have an
isnot keyword, as in "hkey isnot null",


or
 (ii) forget about is for testing null-ness.

 Thoughts?

Ilya Minkov <minkov cs.tum.edu> writes:

Hauke Duden schrieb:

 I agree that !(a is b) is cumbersome.
 
 "is not" would be better. Or maybe something more similar to the normal 
 D syntax?
 
 What about a !is b ?

I'd vote for !is!

"Ben Hinkle" <bhinkle mathworks.com> writes:

"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:cdppih$1ab1$1 digitaldaemon.com...
 While I like the use of is - for one thing, I can reorder the expression

to read more naturally, i.e. "hkey is null"
 rather than "null === hkey" - I don't like the need to ! the expression.

 Presumably the reason for preferring "is" over "===" is that it reads

better, which it does in the === case.
     "hkey is null"

 is better than

     "hkey === null"

 But it seems a starkyl retrograde step to have write "!(hkey is null)"

instead of "hkey !== null"
     "hkey !== null"

 is (much!) better than

     "!(hkey is null)"

 So, if "!(hkey is null)" is not to people's tastes, as I suggest is the

case, then we might end up with an inconsistent
 use of "is" for null, and "!==" for not null. That is not good.

 I suggest that, either:

 (i) we have the keyword modifier "not", as in "hkey is not null", or have

an isnot keyword, as in "hkey isnot null", or
 (ii) forget about is for testing null-ness.

 Thoughts?

if a single keyword is chosen I propose "isnt" since "isn't" is the
contraction of "is" and "not". The word "isnot" doesn't exist.

James McComb <alan jamesmccomb.id.au> writes:

Ben Hinkle wrote:

 if a single keyword is chosen I propose "isnt" since "isn't" is the
 contraction of "is" and "not". The word "isnot" doesn't exist.

The word "typedef" isn't a word either. I don't suppose you want Walter 
to introduce a "type definition" keyword.

James McComb

"Ben Hinkle" <bhinkle mathworks.com> writes:

"James McComb" <alan jamesmccomb.id.au> wrote in message
news:cdrg59$26p2$1 digitaldaemon.com...
 Ben Hinkle wrote:

 if a single keyword is chosen I propose "isnt" since "isn't" is the
 contraction of "is" and "not". The word "isnot" doesn't exist.

 The word "typedef" isn't a word either. I don't suppose you want Walter
 to introduce a "type definition" keyword.

no, I don't. There isn't a contraction of "type" and "definition" so
"typedef" is fine. As is "sizeof". My argument is that even though "isnt"
might seem less formal than "isnot" it has the advantage of being a word and
that makes it more readable/usable. I'd prefer "is_not" to "isnot" if "isnt"
isn't acceptable. Besides, is "isnot" a contraction for "is not" or "i
snot"...

Regan Heath <regan netwin.co.nz> writes:

On Sat, 24 Jul 2004 03:00:02 +1000, James McComb <alan jamesmccomb.id.au> 
wrote:
 Ben Hinkle wrote:

 if a single keyword is chosen I propose "isnt" since "isn't" is the
 contraction of "is" and "not". The word "isnot" doesn't exist.

 The word "typedef" isn't a word either. I don't suppose you want Walter 
 to introduce a "type definition" keyword.

To be fair, you're commiting the "Strawman" here:
   http://www.intrepidsoftware.com/fallacy/straw.php

The first argument for "isnt" is the stronger of the two, and you've 
completely ignored it. I do agree "isnot" shouldn't be ignored as an 
option just because it isn't a word.

"isnt" gets my vote BTW.

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Arcane Jill <Arcane_member pathlink.com> writes:

In article <opsbm5hylk5a2sq9 digitalmars.com>, Regan Heath says...

I do agree "isnot" shouldn't be ignored as an 
option just because it isn't a word.

So how come no-one's mentioned the possibility of "isNot" yet? 

From the style guide Naming Conventions section: "Names formed by joining
multiple works should have each word other than the first capitalized."

Arcane Jill

J C Calvarese <jcc7 cox.net> writes:

Arcane Jill wrote:
 In article <opsbm5hylk5a2sq9 digitalmars.com>, Regan Heath says...
 
 
I do agree "isnot" shouldn't be ignored as an 
option just because it isn't a word.

 
 
 So how come no-one's mentioned the possibility of "isNot" yet? 
 
 From the style guide Naming Conventions section: "Names formed by joining
 multiple works should have each word other than the first capitalized."
 
 Arcane Jill

Capitalization of the second word never even occurred to me.

It probably hasn't been brought up because the goal here is to get a new 
keyword. Since every other keyword is all lowercase (including typedef, 
typeof, ireal, ubyte, and ushort), "isNot" would stick out as a sore 
thumb as an addition to that list.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

h3r3tic <h3r3tic_member pathlink.com> writes:

In article <ce0m8n$2d6f$1 digitaldaemon.com>, Arcane Jill says...

So how come no-one's mentioned the possibility of "isNot" yet? 

From the style guide Naming Conventions section: "Names formed by joining
multiple works should have each word other than the first capitalized."

Arcane Jill

isnot is faster to type than isNot
how about aint ? even faster and looks kewl ;)

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

"Ben Hinkle" <bhinkle mathworks.com> wrote in message
news:cdravq$249h$1 digitaldaemon.com...
 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
 news:cdppih$1ab1$1 digitaldaemon.com...
 While I like the use of is - for one thing, I can reorder the expression

 to read more naturally, i.e. "hkey is null"
 rather than "null === hkey" - I don't like the need to ! the expression.

 Presumably the reason for preferring "is" over "===" is that it reads

 better, which it does in the === case.
     "hkey is null"

 is better than

     "hkey === null"

 But it seems a starkyl retrograde step to have write "!(hkey is null)"

 instead of "hkey !== null"
     "hkey !== null"

 is (much!) better than

     "!(hkey is null)"

 So, if "!(hkey is null)" is not to people's tastes, as I suggest is the

 case, then we might end up with an inconsistent
 use of "is" for null, and "!==" for not null. That is not good.

 I suggest that, either:

 (i) we have the keyword modifier "not", as in "hkey is not null", or have

 an isnot keyword, as in "hkey isnot null", or
 (ii) forget about is for testing null-ness.

 Thoughts?

 if a single keyword is chosen I propose "isnt" since "isn't" is the
 contraction of "is" and "not". The word "isnot" doesn't exist.

If you want to be pedantic, the word "isnt" doesn't exist.

Sha Chancellor <schancel pacific.net> writes:

In article <cdppih$1ab1$1 digitaldaemon.com>,
 "Matthew" <admin.hat stlsoft.dot.org> wrote:

 While I like the use of is - for one thing, I can reorder the expression to 
 read more naturally, i.e. "hkey is null"
 rather than "null === hkey" - I don't like the need to ! the expression.
 
 Presumably the reason for preferring "is" over "===" is that it reads better, 
 which it does in the === case.
 
     "hkey is null"
 
 is better than
 
     "hkey === null"
 
 But it seems a starkyl retrograde step to have write "!(hkey is null)" 
 instead of "hkey !== null"
 
     "hkey !== null"
 
 is (much!) better than
 
     "!(hkey is null)"
 
 So, if "!(hkey is null)" is not to people's tastes, as I suggest is the case, 
 then we might end up with an inconsistent
 use of "is" for null, and "!==" for not null. That is not good.
 
 I suggest that, either:
 
 (i) we have the keyword modifier "not", as in "hkey is not null", or have an 
 isnot keyword, as in "hkey isnot null", or
 
 (ii) forget about is for testing null-ness.
 
 Thoughts?



Why don't i see === on the expressions page?  What would be the 
difference between it and ==?  Is null now meaning something other than 
0 in D?  

Sorry for the stupid questions.

J C Calvarese <jcc7 cox.net> writes:

Sha Chancellor wrote:
 In article <cdppih$1ab1$1 digitaldaemon.com>,
  "Matthew" <admin.hat stlsoft.dot.org> wrote:
 
 

...
 Why don't i see === on the expressions page?  What would be the 
 difference between it and ==?  Is null now meaning something other than 
 0 in D?  

The documentation is incomplete. Basically, "====" has the same purpose 
as "is". They test to see if two object references are identical (that 
they both point to the same object).

So "==" you're comparing *values" and with "===" you're comparing 
*references*. It's a subtle difference, but it's an important one. I'm 
sure someone else can explain it better than I can.

Anyways, here's code I found lying around on my computer that might help 
explain "===" and "is" do.


void main()
{ 	
   Object o, p;
		
		
   /* o and p are instantiated as separate (different) objects. */
   o = new Object();
   p = new Object();
	
	
   if(o is p) printf("o and p are references to the same object.\n");
   else printf("o and p are different objects.\n");

   if(!(o is p)) printf("They're not the same.\n");
   else printf("Yes, o is the same reference as p!\n");

   if(o === p) printf("o and p are references to the same object.\n");
   else printf("o and p are different objects.\n");

   if(!(o === p)) printf("They're not the same.\n");
   else printf("Yes, o is the same reference as p!\n");

   if(o !== p) printf("They're not the same.\n");
   else printf("Yes, o is the same reference as p!\n");

	
   printf("\nNow I'm gong to make them the same...\n");
	
   delete p;
   o = p;  	/* Now they're the same. */
	
   if(o is p) printf("o and p are references to the same object.\n");
   else printf("o and p are different objects.\n");

   if(!(o is p)) printf("They're not the same.\n");
   else printf("Yes, o is the same referenceas p!\n");

   if(o === p) printf("o and p are references to the same object.\n");
   else printf("o and p are different objects.\n");

   if(!(o === p)) printf("They're not the same.\n");
   else printf("Yes, o is the same reference as p!\n");

   if(o !== p) printf("They're not the same.\n");
   else printf("Yes, o is the same reference as p!\n");
		
}


 
 Sorry for the stupid questions.

They're not stupid questions. I hope I answered them.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/