July 23, 2004
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 :)
July 23, 2004
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)

July 23, 2004
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



July 23, 2004
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

July 23, 2004
"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.


July 23, 2004
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
July 23, 2004
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
July 23, 2004
"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"...


July 23, 2004
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.
July 23, 2004
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.