www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - In expression for array

reply kede <nobody gmail.com> writes:
Hi All,

How about adding In expressions for general arrays in addition to assoc arrays:

 if ('i' in eyes)
 ...

as a simple replacement for the more verbose
 foreach(c; eyes)
   if (c == 'i')
     ...

I think its a common enough pattern to warrant inclusion?

Have fun,
kede
Jan 23 2008
next sibling parent reply BCS <ao pathlink.com> writes:
Reply to kede,


 Hi All,
 
 How about adding In expressions for general arrays in addition to
 assoc arrays:
 
 if ('i' in eyes)
 ...
 as a simple replacement for the more verbose
 foreach(c; eyes)
 if (c == 'i')
 ...
 I think its a common enough pattern to warrant inclusion?
 
 Have fun,
 kede


this suggestion comes up about every other month, gets thrashed about (pros, 
cons, etc.) until everyone losses interest and then dies the same (un
implemented) 
death.
Jan 23 2008
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
BCS wrote:

 Reply to kede,
 

 Hi All,

 How about adding In expressions for general arrays in addition to
 assoc arrays:

 if ('i' in eyes)
 ...
 as a simple replacement for the more verbose
 foreach(c; eyes)
 if (c == 'i')
 ...
 I think its a common enough pattern to warrant inclusion?

 Have fun,
 kede


 
 this suggestion comes up about every other month, gets thrashed about 
 (pros, cons, etc.) until everyone losses interest and then dies the same 
 (un implemented) death.



But the last discussion was archived in bugzilla:

http://d.puremagic.com/issues/show_bug.cgi?id=1323

Summary: some people (including Walter, I believe) think that, if 
implemented at all,  "x in some_array" should be equivalent to "x>=0 && 
x<some_array.length".

--bb
Jan 23 2008
parent reply Michiel Helvensteijn <nomail please.com> writes:
Bill Baxter wrote:


 Summary: some people (including Walter, I believe) think that, if
 implemented at all,  "x in some_array" should be equivalent to "x>=0 &&
 x<some_array.length".


I understand that that is more efficient, but that's not the point.

If you ask me, there are 'collections' of items. A set is unordered. A map
can find them based on a key. An array can find them based on an index. But
the focus should be on the items. So the in-operator should look for an
item, not a key (or index).

Well, I'm sure this argument isn't new either. :-)

-- 
Michiel
Jan 25 2008
parent reply "Janice Caron" <caron800 googlemail.com> writes:
On Jan 25, 2008 12:10 PM, Michiel Helvensteijn <nomail please.com> wrote:

 So the in-operator should look for an
 item, not a key


Except that aa[key] will crash if key is not in aa, so you /really/
want to be able to test for the presence of a key in an AA.
Jan 25 2008
parent Michiel Helvensteijn <nomail please.com> writes:
Janice Caron wrote:


 So the in-operator should look for an
 item, not a key


 
 Except that aa[key] will crash if key is not in aa, so you /really/
 want to be able to test for the presence of a key in an AA.


Of course! Just not with the in-operator.

-- 
Michiel
Jan 25 2008
prev sibling parent kede <nobody gmail.com> writes:
ah well, could be worse... could be stabbed... 

same time, next month it is then :)

BCS Wrote:


 Reply to kede,
 

 Hi All,
 
 How about adding In expressions for general arrays in addition to
 assoc arrays:
 
 if ('i' in eyes)
 ...
 as a simple replacement for the more verbose
 foreach(c; eyes)
 if (c == 'i')
 ...
 I think its a common enough pattern to warrant inclusion?
 
 Have fun,
 kede


 
 this suggestion comes up about every other month, gets thrashed about (pros, 
 cons, etc.) until everyone losses interest and then dies the same (un
implemented) 
 death.
Jan 23 2008
prev sibling next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
kede wrote:

 Hi All,
 
 How about adding In expressions for general arrays in addition to assoc arrays:
 
  if ('i' in eyes)
  ...
 
 as a simple replacement for the more verbose
  foreach(c; eyes)
    if (c == 'i')
      ...
 
 I think its a common enough pattern to warrant inclusion?
 
 Have fun,
 kede


Not as it is presented there; I may have used that pattern twice in my 
whole programming career (If order doesn't matter, a hashtable is a 
better option).

If the operator returned the index (a la the standard library function 
find() ), it would be much more useful. But I'm fine with it being a 
function.
Jan 23 2008
parent bearophile <bearophileHUGS lycos.com> writes:
 How about adding In expressions for general arrays in addition to assoc arrays:
  if ('i' in eyes)




I like that, and I've said in the past.



 Not as it is presented there; I may have used that pattern twice in my 
 whole programming career (If order doesn't matter, a hashtable is a 
 better option).


For a programmer coming from Python that pattern is used all the time (even if
Python has better syntaxes to define AAs). And if you look for example:
'l' in "hello"
you can see that a linear scan is actually faster than a hash if the number of
items is small (< ~10) (and the opApply is fast enough).
That same syntax can be used to see if a substring is present in a string, and
you can't do that with an hash...
In my d libs there are isIn()/isInSub() functions that allow to search of an
element in linear structure (arrays, AA keys, iterable objects), or to search
for a subsequence. I think Tango has similar functions among its algorithms.

Bye,
bearophile
Jan 24 2008
prev sibling next sibling parent reply janderson <askme me.com> writes:
kede wrote:

 Hi All,
 
 How about adding In expressions for general arrays in addition to assoc arrays:
 
  if ('i' in eyes)
  ...
 
 as a simple replacement for the more verbose
  foreach(c; eyes)
    if (c == 'i')
      ...
 
 I think its a common enough pattern to warrant inclusion?
 
 Have fun,
 kede



I think something like:

if (contains(eyes, 'i'))

and

auto value = find(eyes, 'i');

should be in the standard library.  It seems excessive to put 'in' in 
the language.

-Joel
Jan 24 2008
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
janderson wrote:

 kede wrote:

 Hi All,

 How about adding In expressions for general arrays in addition to 
 assoc arrays:

  if ('i' in eyes)
  ...

 as a simple replacement for the more verbose
  foreach(c; eyes)
    if (c == 'i')
      ...

 I think its a common enough pattern to warrant inclusion?

 Have fun,
 kede


 
 
 I think something like:
 
 if (contains(eyes, 'i'))
 
 and
 
 auto value = find(eyes, 'i');
 
 should be in the standard library.  It seems excessive to put 'in' in 
 the language.


But 'in' is already in the language.  Are you suggesting it should be 
removed?

--bb
Jan 24 2008
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
kede wrote:

  if ('i' in eyes)
  ...
 
 as a simple replacement for the more verbose
  foreach(c; eyes)
    if (c == 'i')
      ...


I want to add few things to this discussion:
- D already has opIn and opIn_r, so it's just a matter of using it.
- If you use a language with the in built in (D has it already, but I meant for
arrays), like Python, you can quickly understand why it's very good to have it
built-in. (Generally if you come from a language that lacks something, then it
becomes less easy to see why/where it's useful. I know some things aren't good
if you put them in another language, but it's not this situation, I think).
- Using the foreach(c; eyes) if (c == 'i'){} pattern is bad because you always
use a O(n) scan regardless what that "eyes" is. But maybe "eyes" is an object
with a opIn_r method that is O(ln n) or O(1), and you miss it. Instead if you
use "in" (that is you use opIn_r) you always use the faster way of finding the
presence of an item the object allows you to (if no opIn_r is defined, but
opApply is defined, then the "in" operator must automatically call opApply to
perform a scan).
- So using "in" makes code shorter, more flexible, more type-agnostic
(generic), simpler to read, potentially faster and more standard :-)

Bye,
bearophile
Jan 24 2008
next sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
On Jan 25, 2008 7:25 AM, bearophile <bearophileHUGS lycos.com> wrote:

 - So using "in" makes code shorter, more flexible, more type-agnostic
(generic), simpler to read, potentially faster and more standard :-)


All good points. But I know that part of the reason it's a no-go is
consistency. "in" has to scan the keys, not the values, or it would be
inconsistent with AAs.

Personally I wouldn't mind dropping "in" in favor of two new infix
functions "contains" and "containsKey", which would disambiguate the
two cases (and give extra functionality for AAs). But it's probably
too late to change things now, so forget I said anything. :-)
Jan 25 2008
parent Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Janice Caron wrote:

 On Jan 25, 2008 7:25 AM, bearophile <bearophileHUGS lycos.com> wrote:
 

- So using "in" makes code shorter, more flexible, more type-agnostic
(generic), simpler to read, potentially faster and more standard :-)


 
 
 All good points. But I know that part of the reason it's a no-go is
 consistency. "in" has to scan the keys, not the values, or it would be
 inconsistent with AAs.
 


Which doesn't stop Python from doing it this way. And it makes perfect 
sense. In an AA, you are typically concerned with whether a given key 
exists in the container. With an array, you are typically concerned with 
whether a given item is somewhere in the array. Arrays and associative 
arrays are fundamentally different, and I'm not sure this consistency 
actually buys us anything.

And, obviously, using 'in' to check whether a given index is in an array 
is basically useless. Using it as a containment check is /much/ more 
useful. So what if arrays and AAs act differently? You can't assign to 
an arbitrary non-existent index in an array, or append to an AA, either. 
They are not substitutes for each other.


 Personally I wouldn't mind dropping "in" in favor of two new infix
 functions "contains" and "containsKey", which would disambiguate the
 two cases (and give extra functionality for AAs). But it's probably
 too late to change things now, so forget I said anything. :-)


These can already be done as library functions, if there's that much 
concern about it.

-- 
Kirk McDonald
http://kirkmcdonald.blogspot.com
Pyd: Connecting D and Python
http://pyd.dsource.org
Jan 25 2008
prev sibling parent Christopher Wright <dhasenan gmail.com> writes:
bearophile wrote:

 kede wrote:

  if ('i' in eyes)
  ...

 as a simple replacement for the more verbose
  foreach(c; eyes)
    if (c == 'i')
      ...


 
 I want to add few things to this discussion:
 - D already has opIn and opIn_r, so it's just a matter of using it.
 - If you use a language with the in built in (D has it already, but I meant
for arrays), like Python, you can quickly understand why it's very good to have
it built-in. (Generally if you come from a language that lacks something, then
it becomes less easy to see why/where it's useful. I know some things aren't
good if you put them in another language, but it's not this situation, I think).
 - Using the foreach(c; eyes) if (c == 'i'){} pattern is bad because you always
use a O(n) scan regardless what that "eyes" is. But maybe "eyes" is an object
with a opIn_r method that is O(ln n) or O(1), and you miss it. Instead if you
use "in" (that is you use opIn_r) you always use the faster way of finding the
presence of an item the object allows you to (if no opIn_r is defined, but
opApply is defined, then the "in" operator must automatically call opApply to
perform a scan).
 - So using "in" makes code shorter, more flexible, more type-agnostic
(generic), simpler to read, potentially faster and more standard :-)
 
 Bye,
 bearophile


bool has(T)(T[] arr, T elem) {
    foreach (a; arr) if (a == elem) return true;
    return false;
}

if (myarray.has(3)) {
    // ...
}

Just as good, imhoe. You can't avoid a linear scan unless you know 
whether the array is sorted.
Jan 25 2008