www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - !(null is hkey) ??

reply "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?
Jul 22 2004
next sibling parent 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
Jul 22 2004
prev sibling next sibling parent 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
Jul 22 2004
prev sibling next sibling parent reply 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
Jul 22 2004
parent 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). # if (x isnt null) I don't like "isnot". My somewhat overindulged in toilet humor brain puts the word-break in the wrong place. Arcane Jill
Jul 23 2004
prev sibling next sibling parent reply "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

 rather than "null === hkey" - I don't like the need to ! the expression.

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

     "hkey is null"

 is better than

     "hkey === null"

 But it seems a starkyl retrograde step to have write "!(hkey is 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

 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

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

 Thoughts?

Jul 22 2004
next sibling parent 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
Jul 22 2004
prev sibling next sibling parent 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

 rather than "null === hkey" - I don't like the need to ! the expression.

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

     "hkey is null"

 is better than

     "hkey === null"

 But it seems a starkyl retrograde step to have write "!(hkey is 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

 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


isnot, yousnot, we all snot for isnot
 (ii) forget about is for testing null-ness.

 Thoughts?


Jul 22 2004
prev sibling parent 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
Jul 22 2004
prev sibling next sibling parent reply 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
Jul 22 2004
next sibling parent reply 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
Jul 22 2004
next sibling parent 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
Jul 22 2004
prev sibling parent 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 :)
Jul 23 2004
prev sibling next sibling parent reply "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",


 +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

Jul 22 2004
parent 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)
Jul 23 2004
prev sibling parent reply 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... Python 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information.
 a = 1
 a is not None



 a not is None



a not is None ^ SyntaxError: invalid syntax
 not (a is None)






--- Paolo Invernizzi
Jul 22 2004
parent reply "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... Python 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit (Intel)] on 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

Jul 23 2004
next sibling parent reply "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

 specifically designed to be easy to implement, so I am prepared to go for

What? You don't think Walter would go for "aint" ? D would enter the halls of notoriety overnight! :-)
Jul 23 2004
parent reply 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/
Jul 23 2004
parent reply "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).
Jul 23 2004
parent reply 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/
Jul 23 2004
parent 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
Jul 26 2004
prev sibling parent reply 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
Jul 23 2004
next sibling parent reply 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
Jul 23 2004
next sibling parent reply 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 and variants) or more english like words (visual basic, 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.
Jul 23 2004
next sibling parent 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 and variants) or more english like words (visual basic, 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
Jul 23 2004
prev sibling parent "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
 and variants) or more english like words (visual basic, 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.

Jul 23 2004
prev sibling parent reply 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.
Jul 23 2004
parent reply 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
Jul 23 2004
parent reply 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)
Jul 23 2004
parent 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
Jul 23 2004
prev sibling parent "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


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


 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
Jul 23 2004
prev sibling next sibling parent reply 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?
 
 
 
 

Jul 23 2004
next sibling parent reply "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


 rather than "null === hkey" - I don't like the need to ! the expression.

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


     "hkey is null"

 is better than

     "hkey === null"

 But it seems a starkyl retrograde step to have write "!(hkey is 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


 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


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

 Thoughts?


Jul 23 2004
parent "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


 rather than "null === hkey" - I don't like the need to ! the expression.

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


     "hkey is null"

 is better than

     "hkey === null"

 But it seems a starkyl retrograde step to have write "!(hkey is 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


 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


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

 Thoughts?



Jul 23 2004
prev sibling next sibling parent "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


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


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

 Thoughts?


Jul 23 2004
prev sibling parent 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!
Jul 23 2004
prev sibling next sibling parent reply "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

 rather than "null === hkey" - I don't like the need to ! the expression.

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

     "hkey is null"

 is better than

     "hkey === null"

 But it seems a starkyl retrograde step to have write "!(hkey is 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

 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

 (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.
Jul 23 2004
next sibling parent reply 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
Jul 23 2004
next sibling parent "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"...
Jul 23 2004
prev sibling parent reply 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/
Jul 24 2004
parent reply 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
Jul 25 2004
next sibling parent 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/
Jul 25 2004
prev sibling parent 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 ;)
Jul 25 2004
prev sibling parent "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

 rather than "null === hkey" - I don't like the need to ! the expression.

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

     "hkey is null"

 is better than

     "hkey === null"

 But it seems a starkyl retrograde step to have write "!(hkey is 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

 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

 (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.
Jul 23 2004
prev sibling parent reply 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.
Jul 23 2004
parent 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/
Jul 23 2004