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

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.

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

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)

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

"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

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

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

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/

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