#276 Proposal: isnot

brian Sun 6 Jul 2008

Something that I've been meaning to bring up is the notion of an isnot operator. It seems that I check that an instance is not a type as often as it is. Because of operator precedence you have to wrap the is expression in parens which I've always found annoying:

// what you do today
if (!(x is Foo)) doSomething

// proposed isnot keyword
if (x isnot Foo) doSomething

I've also seen the keyword isnt used. I don't really have a preference between the two.

Comments?

cbeust Sun 6 Jul 2008

I'm a bit hesitant reserving and entire keyword just for a negative operator. I agree that the extra parentheses are a bit annoying, but not to the extent that you should burn your keyword allowance for this.

How about making this more general and introducing "unless", which you could extend to all boolean expressions and not only instanceof ones?

unless (x is Foo) doSomething unless (x == 0) {

...

}

cbeust Sun 6 Jul 2008

One more time, with the correct formatting:

unless (x is Foo) doSomething()

unless (x == 0)
{
  // ...
}

brian Sun 6 Jul 2008

Regarding the patent - that patent is for comparing two memory references, so it doesn't apply. That fact that the US Patent Office granted a patent for what is effectively the "!=" C operator which has been use for three decades illustrates how broken the patent system is.

PLEASE DO NOT POST PATENT LINKS ON THIS SITE! It is fundamentally impossible to develop software which doesn't infringe on patents - so assume that Fan infringes someone's patents. But by posting in public all you are going to do is complicate a legal case and bring up the potential for treble damages.

How about making this more general and introducing "unless", which you could extend to all boolean expressions and not only instanceof ones?

Well I don't think burning isnot as a keyword would ever really bother someone.

But I kind like the idea of unless or ifnot - more general purpose.

andy Sun 6 Jul 2008

isnot would be nice, and seems a harmless keyword to take. I used unless alot in Ruby, might be nice to have as well (or instead).

thatguydrinksbeer Mon 7 Jul 2008

ifnot/unless is brilliant.

else unless is confusing, I'd prefer else ifnot.

What about not as a keyword?

if not (x)

else if not (y)

while not (x)

tompalmer Mon 7 Jul 2008

I like unless best for the reverse syntax in Ruby (as in, doSomething unless (x is Foo)). I'm not sure if I'd use it as much otherwise.

I think isnot might be OK.

andy Mon 7 Jul 2008

Yeah, I agree with tom - unless you allow unless to follow the expression, then I vote to have ifnot instead.

Though the other problem with unless is it makes if-else branches awkward:

doFoo unless (x is Foo)
else doBar

I think ifnot is more natural in that scenario:

ifnot (x is Foo) doFoo
else doBar

tompalmer Tue 8 Jul 2008

I'm actually not a fan of ifnot and probably not unless (because I only like the reverse form). I don't think either sounds clear with else.

I think my context caused some confusion. I was referring to being OK with isnot, the original question on this thread. I think I like it better than isnt, just for fear that isnt might look alien to a new learner who didn't get the point.

cbeust Tue 8 Jul 2008

Especially since "isnt" looks like "is NT" :-)

-- Cedric

alexlamsl Tue 8 Jul 2008

Random thought of the day:

if (x is Foo) doSomething;
nah! doSomethingElse;

helium Tue 8 Jul 2008

I vote for aint. ;)

brian Tue 8 Jul 2008

My current thoughts are that isnot seems pretty useful and no likely to be used as a identifier - so I'm thinking we should do that feature.

I'm not quite sure about unless or other forms of "inversed statements". I like unless in Ruby, but not sure how it work with Fan.

brian Wed 9 Jul 2008

I implemented the isnot operator as just the inverse of the is operator. This is a really simple enhancement which doesn't raise any thorny issues (like a general purpose unless solution does). I was using (!(x is Foo)) quite a few places in the code base.

So there is now a new isnot keyword which is semantically equivalent to !(x is Type). If x is null, then it evaluates to true (opposite of what is evaluates to when x is null). Examples:

fansh> 3 is Num
true
fansh> 3 isnot Num
false
fansh> null is Num
false
fansh> null isnot Num
true

jodastephen Wed 9 Jul 2008

Reading through the options here, I like the ifnot option.

ifnot (x is Foo) doFoo
else doBar

For example consider an API that defines an isEmpty() method:

if (obj.isEmpty()) {
  doStuff();
}

The not empty scenario is messy:

if (obj.isEmpty() == false) {
  doStuff();
}
if (!obj.isEmpty()) {
  doStuff();
}

Neither option is particularly clear. As a result I sometimes code the reverse method:

if (obj.isNotEmpty()) {
  doStuff();
}

The ifnot keyword would avoid the need for that:

ifnot (obj.isEmpty()) {
  doStuff();
}

mike Wed 9 Jul 2008

I'd like to second aint

Login or Signup to reply.