www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Please may we have an isnot?

reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
Let me add my plaintiff plea, based on current practical pain for 
lack of isnot operator.

    assert(!(field2 is field));

is just so awkward to write, and ugly to read.
Apr 30 2005
next sibling parent Derek Parnell <derek psych.ward> writes:
On Sun, 1 May 2005 15:36:35 +1000, Matthew wrote:


 Let me add my plaintiff plea, based on current practical pain for 
 lack of isnot operator.
 
     assert(!(field2 is field));
 
 is just so awkward to write, and ugly to read.


Exactly! Surely we are not so pedantic to deny the simplicity of ...

     assert(field2 isnot field);

-- 
Derek Parnell
Melbourne, Australia
1/05/2005 8:41:24 PM
May 01 2005
prev sibling next sibling parent clayasaurus <clayasaurus gmail.com> writes:
Matthew wrote:

 Let me add my plaintiff plea, based on current practical pain for 
 lack of isnot operator.
 
     assert(!(field2 is field));
 
 is just so awkward to write, and ugly to read.
 
 
 
 


I agree, we have is (which is nice btw), why not isnot?
May 01 2005
prev sibling next sibling parent reply Mike Parker <aldacron71 yahoo.com> writes:
Matthew wrote:

 Let me add my plaintiff plea, based on current practical pain for 
 lack of isnot operator.
 
     assert(!(field2 is field));
 
 is just so awkward to write, and ugly to read.
 


Count my vote for it.
May 01 2005
parent reply James Dunne <jdunne4 bradley.edu> writes:
In article <d54edn$u2h$1 digitaldaemon.com>, Mike Parker says...

Matthew wrote:

 Let me add my plaintiff plea, based on current practical pain for 
 lack of isnot operator.
 
     assert(!(field2 is field));
 
 is just so awkward to write, and ugly to read.
 


Count my vote for it.


Postin' "me too" like some braindead AOLer.  =D

Regards,
James Dunne
May 01 2005
parent reply SeeSchloss <ng seeschloss.org> writes:
 Let me add my plaintiff plea, based on current practical pain for 
 lack of isnot operator.
 
     assert(!(field2 is field));
 
 is just so awkward to write, and ugly to read.
 


Count my vote for it.


Postin' "me too" like some braindead AOLer.  =D


Just to say I agree such an operator would be nice, though "!is" would be fine
as well (and look less strange than "isnot" imho).
May 02 2005
parent reply Ant <Ant_member pathlink.com> writes:
In article <d5597d$1m7r$1 digitaldaemon.com>, SeeSchloss says...

 
     assert(!(field2 is field));




Postin' "me too" like some braindead AOLer.  =D


Just to say I agree such an operator would be nice, though "!is" would be fine
as well (and look less strange than "isnot" imho).


we could also have "!in" that would be consistent with "!is"

Ant
May 02 2005
parent reply "news.digitalmars.com" <oursland.nospam deleteme.fastmail.fm> writes:
Ant wrote:

 In article <d5597d$1m7r$1 digitaldaemon.com>, SeeSchloss says...
 

    assert(!(field2 is field));




Postin' "me too" like some braindead AOLer.  =D


Just to say I agree such an operator would be nice, though "!is" would be fine
as well (and look less strange than "isnot" imho).


 
 
 we could also have "!in" that would be consistent with "!is"
 
 Ant
 
 


Well, what about inout, hmmmm?

-Jake
May 02 2005
next sibling parent reply Jake Oursland <oursland.nospam deleteme.fastmail.fm> writes:
news.digitalmars.com wrote:

 Ant wrote:
 

 In article <d5597d$1m7r$1 digitaldaemon.com>, SeeSchloss says...


    assert(!(field2 is field));





 Postin' "me too" like some braindead AOLer.  =D



 Just to say I agree such an operator would be nice, though "!is" 
 would be fine
 as well (and look less strange than "isnot" imho).




 we could also have "!in" that would be consistent with "!is"

 Ant


 
 Well, what about inout, hmmmm?
 
 -Jake


I just love clients that "assume" things about "naming" and such.. sheesh!!!

-Jake
May 02 2005
parent Ant <Ant_member pathlink.com> writes:
In article <d55r5u$29qo$1 digitaldaemon.com>, Jake Oursland says...

news.digitalmars.com wrote:

 Ant wrote:
 

 In article <d5597d$1m7r$1 digitaldaemon.com>, SeeSchloss says...


    assert(!(field2 is field));





 Postin' "me too" like some braindead AOLer.  =D



 Just to say I agree such an operator would be nice, though "!is" 
 would be fine
 as well (and look less strange than "isnot" imho).




 we could also have "!in" that would be consistent with "!is"

 Ant


 
 Well, what about inout, hmmmm?
 




I don't understand what you mean.


I just love clients that "assume" things about "naming" and such.. sheesh!!!


I don't understand what you mean.

I was thinking 'in' AA.
Does it make sence to have '!in' AA? 

Ant
May 02 2005
prev sibling parent Derek Parnell <derek psych.ward> writes:
On Mon, 02 May 2005 09:53:16 -0600, Jake wrote:


 Ant wrote:


[snip]

 we could also have "!in" that would be consistent with "!is"




 

 Well, what about inout, hmmmm?


LOL... Yes there are not too many operators that are a combination of
letters *and* punctuation. It's usually either all punctuation characters
or all letters.

However, an single operator that indicates the negative of the 'in'
operator would be very, very, convenient. Just another thing to make code
more legible and enjoyable to write.

-- 
Derek Parnell
Melbourne, Australia
http://www.dsource.org/projects/build
3/05/2005 7:14:20 AM
May 02 2005
prev sibling next sibling parent David L. Davis <SpottedTiger yahoo.com> writes:
In article <d51pu5$1vju$1 digitaldaemon.com>, Matthew says...

Let me add my plaintiff plea, based on current practical pain for 
lack of isnot operator.

    assert(!(field2 is field));

is just so awkward to write, and ugly to read.


Count me in too, for the creation of a "isnot" operator.

David L.

-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"
-------------------------------------------------------------------

MKoD: http://spottedtiger.tripod.com/D_Language/D_Main_XP.html
May 02 2005
prev sibling next sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message 
news:d51pu5$1vju$1 digitaldaemon.com...

 Let me add my plaintiff plea, based on current practical pain for lack of 
 isnot operator.

    assert(!(field2 is field));

 is just so awkward to write, and ugly to read.


For this reason I use x !== y instead of !(x is y). The latter is too hard 
to read. In some sense it's a pity === didn't stay around since === and !== 
complement each other nicely. oh well. :-P
May 02 2005
parent reply Ant <Ant_member pathlink.com> writes:
In article <d55c5p$1pk7$1 digitaldaemon.com>, Ben Hinkle says...

 In some sense it's a pity === didn't stay around since 


What do you mean?
I think I use === every here.
Does it fails to compile? (I don't have D here)

Ant
May 02 2005
parent "Ben Hinkle" <bhinkle mathworks.com> writes:
"Ant" <Ant_member pathlink.com> wrote in message 
news:d55e56$1rs6$1 digitaldaemon.com...

 In article <d55c5p$1pk7$1 digitaldaemon.com>, Ben Hinkle says...

 In some sense it's a pity === didn't stay around since


 What do you mean?
 I think I use === every here.
 Does it fails to compile? (I don't have D here)


I had the feeling it was going to fail to compile at some point but maybe 
not. I can't remember the details. I notice the spec doesn't mention === or 
!== anywhere. It says to use !(x is y).
May 02 2005
prev sibling next sibling parent reply zwang <nehzgnaw gmail.com> writes:
Besides "isnot", a "notin" operator would also be nice.


Matthew wrote:

 Let me add my plaintiff plea, based on current practical pain for 
 lack of isnot operator.
 
     assert(!(field2 is field));
 
 is just so awkward to write, and ugly to read.
May 02 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
zwang wrote:


 Besides "isnot", a "notin" operator would also be nice.


What would a "notin" operator return ? The current "in"
returns a pointer to the value, or null if is not found.

Identity and not-identity are much easier to "not", as
would a "in" operator that returned a boolean value...

But with the current in operator ? I guess it would be :
((key in hash) == null)

Yes, that is == and not === since "in" uses pointers and
not references. It's a very confusing concept, in itself.

I liked the old double-lookup in operator better, myself.
(i.e. the one that returned a "bit" value, not a pointer)

--anders
May 02 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 03 May 2005 08:55:59 +0200, Anders F Björklund wrote:


 zwang wrote:
 

 Besides "isnot", a "notin" operator would also be nice.


 
 What would a "notin" operator return ? The current "in"
 returns a pointer to the value, or null if is not found.
 
 Identity and not-identity are much easier to "not", as
 would a "in" operator that returned a boolean value...
 
 But with the current in operator ? I guess it would be :
 ((key in hash) == null)
 
 Yes, that is == and not === since "in" uses pointers and
 not references. It's a very confusing concept, in itself.
 
 I liked the old double-lookup in operator better, myself.
 (i.e. the one that returned a "bit" value, not a pointer)


I must admit that I never use the pointer returned by 'in' except to see if
it is null or not. I seem to always use this idiom ...

   if (X in Y)
       Z = Y[X];
   else
       Z = whatever;

and

   if (X in Y != null)
      Y[X] = value;

Am I doing this the hard way? Am I over cautious?
-- 
Derek Parnell
Melbourne, Australia
3/05/2005 7:23:57 PM
May 03 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Derek Parnell wrote:


I liked the old double-lookup in operator better, myself.
(i.e. the one that returned a "bit" value, not a pointer)


 
 I must admit that I never use the pointer returned by 'in' except to see if
 it is null or not. I seem to always use this idiom ...
 
    if (X in Y)
        Z = Y[X];
    else
        Z = whatever;
 
 and
 
    if (X in Y != null)
       Y[X] = value;
 
 Am I doing this the hard way? Am I over cautious?


No, I use the very same approach myself...


It just "feels" better to me, than this:

if ((pZ = X in Y) != null)
     Z = *pZ;

Even if it causes two lookups to happen ?


But everyone seems to hate the short form of:
Z = Y[X]; // where Z gets the .init if missing

Currently unusable in D, since it will create
a brand new X key - if it was missing before...

--anders
May 03 2005
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 03 May 2005 11:56:18 +0200, Anders F Björklund wrote:


[snip]
 

 But everyone seems to hate the short form of:
 Z = Y[X]; // where Z gets the .init if missing
 
 Currently unusable in D, since it will create
 a brand new X key - if it was missing before...


Exactly! If X isn't there its because of a very good reason (or a bug),
otherwise I want to know that it's not there. Sneaking it in seems just
plain stupid.

-- 
Derek Parnell
Melbourne, Australia
http://www.dsource.org/projects/build v2.05 is now available. 02/May/2005
3/May/2005 8:16:51 PM
May 03 2005
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Derek Parnell wrote:


 Exactly! If X isn't there its because of a very good reason (or a bug),
 otherwise I want to know that it's not there. Sneaking it in seems just
 plain stupid.


I thought it was similar to using an "uninitialized" X ?
(which is always initialized to a default .init value)

But like I said, most everyone else disagreed :-)

And throwing an exception or creating a new key doesn't
matter to me, I guess either of is "logical" to someone.

I'll just use the "Z = (X in Y) ? Y[X] : whatever;" form.

--anders
May 03 2005
prev sibling parent Ant <Ant_member pathlink.com> writes:
In article <wtnge4kxj6zb$.hraa9mj820mh.dlg 40tude.net>, Derek Parnell says...

On Tue, 03 May 2005 11:56:18 +0200, Anders F Björklund wrote:


[snip]
 

 But everyone seems to hate the short form of:
 Z = Y[X]; // where Z gets the .init if missing
 
 Currently unusable in D, since it will create
 a brand new X key - if it was missing before...


Exactly! If X isn't there its because of a very good reason (or a bug),
otherwise I want to know that it's not there. Sneaking it in seems just
plain stupid.


Yes, it is.
Now, you need to explain it to Walter.

Ant
May 03 2005
prev sibling parent reply Kevin Bealer <Kevin_member pathlink.com> writes:
In article <d57hs1$1jnv$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...

Derek Parnell wrote:


I liked the old double-lookup in operator better, myself.
(i.e. the one that returned a "bit" value, not a pointer)


 
 I must admit that I never use the pointer returned by 'in' except to see if
 it is null or not. I seem to always use this idiom ...
 
    if (X in Y)
        Z = Y[X];
    else
        Z = whatever;
 
 and
 
    if (X in Y != null)
       Y[X] = value;
 
 Am I doing this the hard way? Am I over cautious?


No, I use the very same approach myself...


It just "feels" better to me, than this:

if ((pZ = X in Y) != null)
     Z = *pZ;

Even if it causes two lookups to happen ?


How about this:

: if (X in Y)
:     Z = *(X in Y);

If the compiler is clever enough, it should be able to optimize to one lookup,
as long as it can assume the value wasn't added between the "in"s.

--> So... is it, or could it be, smart enough to do one lookup?

P.S. This is another advantage of built-in containers if it can do so, because
a C++ compiler would (probably) never be able to make assumptions like "the
value of operator[] can be cached" but D probably CAN.

In C++, the compiler (in general) has no idea whether it is working with a
container or something that *requires* two checks, like a spinlock
implementation.  I think it has to assume the "X in Y" operations are
potentially seperate stages and check twice;  a current or future version of D
could avoid that by checking once.

Kevin
May 04 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Kevin Bealer wrote:


It just "feels" better to me, than this:

if ((pZ = X in Y) != null)
    Z = *pZ;

Even if it causes two lookups to happen ?


 
 How about this:
 
 : if (X in Y)
 :     Z = *(X in Y);
 
 If the compiler is clever enough, it should be able to optimize to one lookup,
 as long as it can assume the value wasn't added between the "in"s.
 
 --> So... is it, or could it be, smart enough to do one lookup?


You mean that a clever compiler could make
the second example into the first example :-)

That's great, but it is still rather ugly...

Like in the first line, "in" is a pretend-boolean
but in the second it's one of those hated pointers ?

Z = Y[X]; // this is still the shortest/cleanest.

But I think we hijacked this thread long enough now.

--anders
May 04 2005
parent reply Kevin Bealer <Kevin_member pathlink.com> writes:
In article <d59u9i$1dj4$1 digitaldaemon.com>
..

You mean that a clever compiler could make
the second example into the first example :-)

That's great, but it is still rather ugly...

Like in the first line, "in" is a pretend-boolean
but in the second it's one of those hated pointers ?

Z = Y[X]; // this is still the shortest/cleanest.

But I think we hijacked this thread long enough now.

--anders


Okay, granted on both points -- thus, I'll change the subject of the thread.

I think this kind of relates to the opIndex() vs. opIndexAssign() dilemma.

The default AA returns (effectively) something like a C++ "T&" type.  If you
design a class, you have to write opIndex() (a T return type) or opIndexAssign()
(which essentially takes T as in "in" parameter).

If the default AA followed what classes do, it could return T for the opIndex()
method, or always-add like C++ and the current AA for opIndexAssign().

The question then, is whether to:

1. Return a mutable reference aka "lvalue", or in D terminology "inout" type,
which is assignable, ++able, or pass-able to a function's "inout" parameter.

2. Seperate opIndex() and opIndexAssign(), so that opIndex() can only fetch an
element from the class, but opIndexAssign() can write into the class.


like "create whenever we see X[key]".  And current user constructed classes do

of null (T.init maybe), but on opIndexAssign() they can still create an object.

To quote Humpty Dumpty from AIW: "The question is, who is to be the master?".
In other words, does the client code have the power, or the class?


using ++ or foo(inout T), and the container needs to return an rvalue (somehow)
as the builtin AA does.


the client is restricted to two operations: X[i] = foo, or foo = X[i].

---

I think the ideal thing, semantically, would be for D to somehow convert X[i]++
to:

X[i] = X[i]++;

And, for:

foo(inout T);
foo(X[i]);

.. to effectively be the same as:

T z = X[i];
foo(z);
X[i] = z;

---> Thus, we can keep opIndex() and opIndexAssign().  If opIndex cannot find
the object, it can return T.init, which converts the above statement to:

T z;
foo(z);
X[i] = z;

The compiler would presumably be able to produce that last snippet every time if
it knows that foo(z) is actually foo(out T).  This leads to:

foo(in x);    foo(X[i]);   // only one lookup, opIndex();
foo(out x);   foo(X[i]);   // only one lookup, opIndexAssign();
foo(inout x); foo(X[i]);   // two lookups (opIndex(); foo(); opIndexAssign();)

The last case is the issue.  It could use the design I show here; potentially
there are two lookups unless the optimizer can remove one of them.

Or it could use Ben Hinkle's suggestion in the opIndexMutable() thread, that the
indexing operator return T*, which the compiler would dereference as shown:

foo(inout x); foo(X[i]);  ---->   foo(* X.opIndexMutable(i));

Kevin
May 04 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
 Or it could use Ben Hinkle's suggestion in the opIndexMutable() thread, 
 that the
 indexing operator return T*, which the compiler would dereference as 
 shown:

 foo(inout x); foo(X[i]);  ---->   foo(* X.opIndexMutable(i));

 Kevin


You're being too generous - the opIndexMutable was your suggestion :-)
My suggestion was the use of a flag at the call site in front of X[i] to 
keep C's "bottom-up" type resolution.
May 05 2005
parent Kevin Bealer <Kevin_member pathlink.com> writes:
In article <d5d8ei$16eo$1 digitaldaemon.com>, Ben Hinkle says...

 Or it could use Ben Hinkle's suggestion in the opIndexMutable() thread, 
 that the
 indexing operator return T*, which the compiler would dereference as 
 shown:

 foo(inout x); foo(X[i]);  ---->   foo(* X.opIndexMutable(i));

 Kevin


You're being too generous - the opIndexMutable was your suggestion :-)
My suggestion was the use of a flag at the call site in front of X[i] to 
keep C's "bottom-up" type resolution. 


I was thinking that automatically using the "*" was yours, but I forgot to look
it up.  Am I guilty of brain-child abandonment?

Kevin
May 05 2005
prev sibling next sibling parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
Matthew wrote:

 Let me add my plaintiff plea, based on current practical pain for 
 lack of isnot operator.
 
     assert(!(field2 is field));
 
 is just so awkward to write, and ugly to read.
 
 
 
 


I agree, but "isnot" sounds too much like pascal, I prefer something 
like "!is" or "is!"
May 02 2005
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Matthew wrote:


 Let me add my plaintiff plea, based on current practical pain for 
 lack of isnot operator.
 
     assert(!(field2 is field));
 
 is just so awkward to write, and ugly to read.


Who is this "plea" directed to ? Walter ? Better try email, then.

The rest of us ? Already done... (as it was added to DMD 0.111)
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/14705

Or if in a tight spot I guess you could start writing "isnot"
and preprocess it ? Maybe even use cpp: #define isnot !== :-)

But I was starting to learn towards "isnt" for the token, myself...

--anders
May 02 2005