Denton Cockburn <diboss hotmail.com> writes:

What would be the problem in extending the 'in' syntax used for AA to
regular arrays?

I think it's rather nice syntactic sugar.

Bill Baxter <dnewsgroup billbaxter.com> writes:

Denton Cockburn wrote:
 What would be the problem in extending the 'in' syntax used for AA to
 regular arrays?
 
 I think it's rather nice syntactic sugar.

What it should mean.  See the series of arguments and counter-arguments 
in the enh request I filed:
http://d.puremagic.com/issues/show_bug.cgi?id=1323

So which meaning where you hoping it would have?

--bb

Denton Cockburn <diboss hotmail.com> writes:

On Sun, 04 Nov 2007 13:42:41 +0900, Bill Baxter wrote:

 Denton Cockburn wrote:
 What would be the problem in extending the 'in' syntax used for AA to
 regular arrays?
 
 I think it's rather nice syntactic sugar.

 
 What it should mean.  See the series of arguments and counter-arguments 
 in the enh request I filed:
 http://d.puremagic.com/issues/show_bug.cgi?id=1323
 
 So which meaning where you hoping it would have?
 
 --bb

search by values, not by index.
I wrote a contains function, and I assume everyone who comes across a
similar use-case does the same.

I just figure it's done often enough that adding it wouldn't be hard,
especially considering the keyword is already there, and with the same
general meaning.

Bill Baxter <dnewsgroup billbaxter.com> writes:

Denton Cockburn wrote:
 On Sun, 04 Nov 2007 13:42:41 +0900, Bill Baxter wrote:
 
 Denton Cockburn wrote:
 What would be the problem in extending the 'in' syntax used for AA to
 regular arrays?

 I think it's rather nice syntactic sugar.

 What it should mean.  See the series of arguments and counter-arguments 
 in the enh request I filed:
 http://d.puremagic.com/issues/show_bug.cgi?id=1323

 So which meaning where you hoping it would have?

 --bb

 
 search by values, not by index.
 I wrote a contains function, and I assume everyone who comes across a
 similar use-case does the same.
 
 I just figure it's done often enough that adding it wouldn't be hard,
 especially considering the keyword is already there, and with the same
 general meaning.

Yeh, well that's what I think it should mean, and that's what Python 
thinks it should mean.  But not everyone agrees, and Walter doesn't seem 
interested.

--bb

"Janice Caron" <caron800 googlemail.com> writes:

How coincidental. Only yesterday (on another thread) I posted my
thought that it would be cool to have a std.array module with lots of
array functions, with as much power as those of PHP (though not with
the same syntax!)

My own thought is that looking for values in arrays should have the
same syntax as strings. That is, for non-associative arrays:

V[] a;
int n = a.find(x);

should return -1 if the value is not present in the array, or the
index if it is. This is a much better idea than returning a pointer to
the element, because (a) you don't have to worry about const and
invariant, and (b) it's the same as std.string. In addition, you can
then do a[n..$].find() to find the second occurence, and so on.

For associative arrays, it's trickier to decide on the syntax. My
first thought was

V[K] a;
K n = a.find(x); // return a key whose value is x

but that doesn't really work so well. First, there's no generic
equivalent to -1, and hence no way to say "no match". Second, there's
no real way of searching for the second match, once you've found the
first. So then, my second thought was, maybe it should be

V[K] a;
K[] n = a.findAll(x); // return an array of all keys whose value is x

PHP has a function which "filps" an array, so that keys become values
and values become keys. That would be useful too.

Matti Niemenmaa <see_signature for.real.address> writes:

Janice Caron wrote:
 V[] a;
 int n = a.find(x);
 
 should return -1 if the value is not present in the array, or the
 index if it is. This is a much better idea than returning a pointer to
 the element, because (a) you don't have to worry about const and
 invariant, and (b) it's the same as std.string. In addition, you can
 then do a[n..$].find() to find the second occurence, and so on.

As an aside: Tango uses the idiom that find returns the length of the given
array if no match is found. This allows it to return a size_t (if you ever use
arrays longer than int.max...) whilst still having a clear error value.

-- 
E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi

Oskar Linde <oskar.lindeREM OVEgmail.com> writes:

Matti Niemenmaa wrote:
 Janice Caron wrote:
 V[] a;
 int n = a.find(x);

 should return -1 if the value is not present in the array, or the
 index if it is. This is a much better idea than returning a pointer to
 the element, because (a) you don't have to worry about const and
 invariant, and (b) it's the same as std.string. In addition, you can
 then do a[n..$].find() to find the second occurence, and so on.

 
 As an aside: Tango uses the idiom that find returns the length of the given
 array if no match is found. This allows it to return a size_t (if you ever use
 arrays longer than int.max...) whilst still having a clear error value.

It is also helpful that arr.length is a valid slice delimiter, so that 
you with Tango:

a[a.find(whatever)..$] and
a[0..a.find(something)]

remain valid even when no match is found.

-- 
Oskar

Regan Heath <regan netmail.co.nz> writes:

Janice Caron wrote:
 How coincidental. Only yesterday (on another thread) I posted my
 thought that it would be cool to have a std.array module with lots of
 array functions, with as much power as those of PHP (though not with
 the same syntax!)
 
 My own thought is that looking for values in arrays should have the
 same syntax as strings. That is, for non-associative arrays:
 
 V[] a;
 int n = a.find(x);
 
 should return -1 if the value is not present in the array, or the
 index if it is. This is a much better idea than returning a pointer to
 the element, because (a) you don't have to worry about const and
 invariant, and (b) it's the same as std.string. In addition, you can
 then do a[n..$].find() to find the second occurence, and so on.

You do have to remember to add the result of the 2nd call to the result 
of the first to get the index of the 2nd occurrence though.  I've 
forgotten to do it almost as many times as I've coded something using this.

Regan

"Janice Caron" <caron800 googlemail.com> writes:

On 11/4/07, Janice Caron <caron800 googlemail.com> wrote:
 My own thought is that looking for values in arrays should have the
 same syntax as strings. That is, for non-associative arrays:

 V[] a;
 int n = a.find(x);

 should return -1 if the value is not present in the array, or the
 index if it is.

In point of fact, if find() were defined for arrays of any kind,
instead of just char[] (or now, "const const char[]" (whatever that
means), then the string functions would almost be subsumed.

(I say almost, because the string functions search for a dchar, not a
char, and hence do UTF-8 decoding)

Of course I'd also like to see the std.string functions extended to
include wstrings and dstrings, but that's off-topic for this thread.


 So then, my second thought was, maybe it should be

 V[K] a;
 K[] n = a.findAll(x); // return an array of all keys whose value is x

My third thought is a function findEach() which returns a class which
overloads foreach, so you could do

V[K] a;
foreach (key; a.findEach(value)) {}

But again, all I'm talking about here are library functions, not
language extentions.

"Janice Caron" <caron800 googlemail.com> writes:

On 11/4/07, Janice Caron <caron800 googlemail.com> wrote:
 My third thought is a function findEach() which returns a class which
 overloads foreach, so you could do

 V[K] a;
 foreach (key; a.findEach(value)) {}

Ooh - on fourth thoughts, I'd like to rename that function "each". As in

    foreach (key; a.each(value)) { /*do something*/ }

I like that.

Walter Bright <newshound1 digitalmars.com> writes:

Denton Cockburn wrote:
 I just figure it's done often enough that adding it wouldn't be hard,
 especially considering the keyword is already there, and with the same
 general meaning.

With AAs, the 'in' expression looks for the key, not the value. It would 
be inconsistent to overload it to search for values in regular arrays.

Bill Baxter <dnewsgroup billbaxter.com> writes:

Walter Bright wrote:
 Denton Cockburn wrote:
 I just figure it's done often enough that adding it wouldn't be hard,
 especially considering the keyword is already there, and with the same
 general meaning.

 
 With AAs, the 'in' expression looks for the key, not the value. It would 
 be inconsistent to overload it to search for values in regular arrays.

A foolish consistency.  Arrays and associative arrays are different things.

--bb

Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:

Bill Baxter wrote:
 Walter Bright wrote:
 Denton Cockburn wrote:
 I just figure it's done often enough that adding it wouldn't be hard,
 especially considering the keyword is already there, and with the same
 general meaning.

 With AAs, the 'in' expression looks for the key, not the value. It 
 would be inconsistent to overload it to search for values in regular 
 arrays.

 
 A foolish consistency.  Arrays and associative arrays are different things.
 
 --bb

It's inconsistent either way, for that same reason! (that arrays and 
associative arrays are different things). 'in' should not be overloaded 
in any way whatsoever between those two types. Neither to search for 
indexes or values in regular arrays.

Arrays and "associative arrays" are *very* different things. They only 
share the "array" name and the aspect that they are indexable. But their 
semantics are very different. Arrays have a lot more in common with 
lists than "associative arrays". Arrays and lists should have 
appropriately named methods such as 'contains', 'sort', 'slice', etc., 
while "associative arrays" should have other methods such as 
'containsKey', 'containsValue', etc. ('slice' and others don't even make 
sense).

And btw, which languages besides D call associative arrays as 
"associative arrays"? (instead of "maps" or other things more sensible)

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Ary Borenszweig <ary esperanto.org.ar> writes:

Bruno Medeiros escribió:
 Bill Baxter wrote:
 Walter Bright wrote:
 Denton Cockburn wrote:
 I just figure it's done often enough that adding it wouldn't be hard,
 especially considering the keyword is already there, and with the same
 general meaning.

 With AAs, the 'in' expression looks for the key, not the value. It 
 would be inconsistent to overload it to search for values in regular 
 arrays.

 A foolish consistency.  Arrays and associative arrays are different 
 things.

 --bb

 
 It's inconsistent either way, for that same reason! (that arrays and 
 associative arrays are different things). 'in' should not be overloaded 
 in any way whatsoever between those two types. Neither to search for 
 indexes or values in regular arrays.
 
 Arrays and "associative arrays" are *very* different things. They only 
 share the "array" name and the aspect that they are indexable. But their 
 semantics are very different. Arrays have a lot more in common with 
 lists than "associative arrays". Arrays and lists should have 
 appropriately named methods such as 'contains', 'sort', 'slice', etc., 
 while "associative arrays" should have other methods such as 
 'containsKey', 'containsValue', etc. ('slice' and others don't even make 
 sense).
 
 And btw, which languages besides D call associative arrays as 
 "associative arrays"? (instead of "maps" or other things more sensible)
 

PHP: http://ar.php.net/array

Regan Heath <regan netmail.co.nz> writes:

Bruno Medeiros wrote:
 Bill Baxter wrote:
 Walter Bright wrote:
 Denton Cockburn wrote:
 I just figure it's done often enough that adding it wouldn't be hard,
 especially considering the keyword is already there, and with the same
 general meaning.

 With AAs, the 'in' expression looks for the key, not the value. It 
 would be inconsistent to overload it to search for values in regular 
 arrays.

 A foolish consistency.  Arrays and associative arrays are different 
 things.

 --bb

 
 It's inconsistent either way, for that same reason! (that arrays and 
 associative arrays are different things). 'in' should not be overloaded 
 in any way whatsoever between those two types. Neither to search for 
 indexes or values in regular arrays.
 
 Arrays and "associative arrays" are *very* different things. They only 
 share the "array" name and the aspect that they are indexable. But their 
 semantics are very different. Arrays have a lot more in common with 
 lists than "associative arrays". Arrays and lists should have 
 appropriately named methods such as 'contains', 'sort', 'slice', etc., 
 while "associative arrays" should have other methods such as 
 'containsKey', 'containsValue', etc. ('slice' and others don't even make 
 sense).
 
 And btw, which languages besides D call associative arrays as 
 "associative arrays"? (instead of "maps" or other things more sensible)

A map is a piece of paper or book with roads and rivers drawn on it.  <g>

Regan

Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:

Regan Heath wrote:
 
 A map is a piece of paper or book with roads and rivers drawn on it.  <g>
 
 Regan

No, it's a game scenario where a match takes place. :P

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Derek Parnell <derek psych.ward> writes:

On Sun, 04 Nov 2007 12:13:35 -0800, Walter Bright wrote:

 Denton Cockburn wrote:
 I just figure it's done often enough that adding it wouldn't be hard,
 especially considering the keyword is already there, and with the same
 general meaning.

 
 With AAs, the 'in' expression looks for the key, not the value. It would 
 be inconsistent to overload it to search for values in regular arrays.

No it wouldn't.

If someone says "is 'cat' in that list?" nearly everyone knows exactly what
was meant. If the list is 'ordered' (i.e. an AA) the person was looking for
an index of 'cat', and if the list was not 'ordered' (a regular array) the
person was looking for content of 'cat'.

For example, I have a dictionary and wonder if 'cat' is in it. I look up
the word "cat" instead of scanning every page for the first mention of a
cat. I have a newspaper article about dog training and wonder if 'cat' is
in it, so I scan for the first mention of a cat.

It is not an inconsistant overload. For such an example of inconsistant
overloads see "static", or "in" when used with DbC.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

"Janice Caron" <caron800 googlemail.com> writes:

On 11/4/07, Derek Parnell <derek psych.ward> wrote:
 If someone says "is 'cat' in that list?" nearly everyone knows exactly what
 was meant.

I'd rather have consistency - particularly when it would be so easy to
add a find() function to do the search-for-a-value thing.

Daniel Keep <daniel.keep.lists gmail.com> writes:

Janice Caron wrote:
 On 11/4/07, Derek Parnell <derek psych.ward> wrote:
 If someone says "is 'cat' in that list?" nearly everyone knows exactly what
 was meant.

 
 I'd rather have consistency - particularly when it would be so easy to
 add a find() function to do the search-for-a-value thing.

I think his point was that the double meaning for "in" *is* consistent
with how people use the word in every day life.  On the other hand,
there are lots of keywords in D that have completely non-orthogonal
meanings.  The consistency argument is, frankly, a load of codswallow
when you consider that "in" already has *three* unrelated meanings:
"membership test", "precondition" and "pass by value."

And it's not the only keyword like that; static has multiple meanings,
too.  And every other operator in the language can have subtly different
meanings depending on how its been overloaded.  The important thing is
that the operators all do "the right thing" for the given type.

An example: you can't use real[4] + real[4], but you *can* do
vector!(real, 4) + vector!(real, 4).  I mean, they're basically the
exact same thing.  Thus, this is inconsistent, and you shouldn't be
allowed to add vectors.  But that's stupid because adding vectors is
actually *really* useful, and I'm actually quite capable of putting
arrays and vectors into different mental boxes.  Arrays vs. maps is no
different; in that case you're saying that "in" shouldn't be usable on
arrays because it's implemented differently for AAs.

Anyway, you can probably tell which side of the fence I'm sitting on.
Just thought I'd chip in my AU$0.02.

	-- Daniel