I think the ambiguity of

key in hash
and
foreach( in int foo; array )

should be removed.  I think "in" is better in the second example.  While I
understand these two contexts
are _VERY_ different, I was under the impression that Walter was against any
context sensitive syntax at
all.  (Just look a visual basic for an example of how context sensitive
languages make a mess.)  It also
makes it that much easier for parsers to do things with the code.

Possibly the key in hash syntax could be replaced with something like this:

hash has key
hash includes key
hash contains key

My personal vote would be with hash has key.


- My two cents

On Wed, 27 Jul 2005 05:53:16 +0000 (UTC), Shammah Chancellor <Shammah_member@pathlink.com> wrote:
> I think the ambiguity of
>
> key in hash
> and
> foreach( in int foo; array )
>
> should be removed.  I think "in" is better in the second example.  While I
> understand these two contexts
> are _VERY_ different, I was under the impression that Walter was against any
> context sensitive syntax at
> all.  (Just look a visual basic for an example of how context sensitive
> languages make a mess.)  It also
> makes it that much easier for parsers to do things with the code.
>
> Possibly the key in hash syntax could be replaced with something like this:
>
> hash has key
> hash includes key
> hash contains key
>
> My personal vote would be with hash has key.

I prefer "contains" and I prefer a method format, eg.

if (hash.contains(key)) //true/false
if (hash.contains(key,value)) //true/false, sets value on true

This allows a check and get with a single lookup and no pointers if desired (the 2nd form)

Regan

"Shammah Chancellor" <Shammah_member@pathlink.com> wrote in message news:dc77gc$228i$1@digitaldaemon.com...
>I think the ambiguity of
>
> key in hash
> and
> foreach( in int foo; array )
>
> should be removed.  I think "in" is better in the second example.  While I
> understand these two contexts
> are _VERY_ different, I was under the impression that Walter was against
> any
> context sensitive syntax at
> all.  (Just look a visual basic for an example of how context sensitive
> languages make a mess.)  It also
> makes it that much easier for parsers to do things with the code.

By "context sensitive" Walter (I believe) means that the semantics of
symbols - for example when a C++ parser sees  a < b it needs to know if a is
a template about to be instantiated or if it < is less-than. In D the uses
of 'in' never need to know any information about the surrounding symbols to
do its job. In a param list it means 'in/out/inout' and in an expression it
means 'hash in'.
I'm not sure what you mean by making things easier for parsers to do things
to code - do you have an example in mind?

As for changing 'in' to something else I don't have a strong opinion - it would make it easier for MinTL to mimic builtin AA's since we don't have any opIn for 'in' overloading so unless opIn is added I agree 'in' should change and Regan's suggestion looks like a good way to go. In any case the bool contains(key,out value) would be useful no matter what happened to 'in'.

I agree, 'contains' is better than 'in'.

-Craig

"Regan Heath" <regan@netwin.co.nz> wrote in message news:opsuj5i2iy23k2f5@nrage.netwin.co.nz...
> On Wed, 27 Jul 2005 05:53:16 +0000 (UTC), Shammah Chancellor <Shammah_member@pathlink.com> wrote:
>> I think the ambiguity of
>>
>> key in hash
>> and
>> foreach( in int foo; array )
>>
>> should be removed.  I think "in" is better in the second example.  While
>> I
>> understand these two contexts
>> are _VERY_ different, I was under the impression that Walter was against
>> any
>> context sensitive syntax at
>> all.  (Just look a visual basic for an example of how context sensitive
>> languages make a mess.)  It also
>> makes it that much easier for parsers to do things with the code.
>>
>> Possibly the key in hash syntax could be replaced with something like this:
>>
>> hash has key
>> hash includes key
>> hash contains key
>>
>> My personal vote would be with hash has key.
>
> I prefer "contains" and I prefer a method format, eg.
>
> if (hash.contains(key)) //true/false
> if (hash.contains(key,value)) //true/false, sets value on true
>
> This allows a check and get with a single lookup and no pointers if desired (the 2nd form)
>
> Regan

I really don't mind "in", but if it's going to be changed, my vote is for "has". Keep it nice and short.

In addition, let's not forget about the negative version(s)...

# if (key in array)    // fine.
# if (!(key in array)) // clunky.
# if (key !in array)   // ideal.
#
# if (array has key)    // fine.
# if (!(array has key)) // clunky.
# if (array !has key)   // odd?

Cheers,
--AJG.


In article <dc77gc$228i$1@digitaldaemon.com>, Shammah Chancellor says...
>
>I think the ambiguity of
>
>key in hash
>and
>foreach( in int foo; array )
>
>should be removed.  I think "in" is better in the second example.  While I
>understand these two contexts
>are _VERY_ different, I was under the impression that Walter was against any
>context sensitive syntax at
>all.  (Just look a visual basic for an example of how context sensitive
>languages make a mess.)  It also
>makes it that much easier for parsers to do things with the code.
>
>Possibly the key in hash syntax could be replaced with something like this:
>
>hash has key
>hash includes key
>hash contains key
>
>My personal vote would be with hash has key.
>
>
>- My two cents
>
>

in has three uses , DBC , key in hash , and a modifier for parameters.

I agree with Regan, 'contains' gets my vote , and unless it also works for arrays , Id argue the method syntax.

Charlie

"Shammah Chancellor" <Shammah_member@pathlink.com> wrote in message news:dc77gc$228i$1@digitaldaemon.com...
> I think the ambiguity of
>
> key in hash
> and
> foreach( in int foo; array )
>
> should be removed.  I think "in" is better in the second example.  While I
> understand these two contexts
> are _VERY_ different, I was under the impression that Walter was against
any
> context sensitive syntax at
> all.  (Just look a visual basic for an example of how context sensitive
> languages make a mess.)  It also
> makes it that much easier for parsers to do things with the code.
>
> Possibly the key in hash syntax could be replaced with something like
this:
>
> hash has key
> hash includes key
> hash contains key
>
> My personal vote would be with hash has key.
>
>
> - My two cents
>
>

Shammah Chancellor <Shammah_member@pathlink.com> wrote:

> I think the ambiguity of
> 
> key in hash
> and
> foreach( in int foo; array )
[...]

This is not an ambiguity in any way.

For example: parentheses are spread over the grammar at several places but introduce an ambiguity only at a very special construct:

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3847

-manfred

On Wed, 27 Jul 2005 17:51:49 +0200, AJG <AJG_member@pathlink.com> wrote:
> In addition, let's not forget about the negative version(s)...
>
> # if (key in array)    // fine.
> # if (!(key in array)) // clunky.
> # if (key !in array)   // ideal.

Yes. I'm waiting for "!in" too.

> # if (array has key)    // fine.
> # if (!(array has key)) // clunky.
> # if (array !has key)   // odd?

Bleh ...
-- 
Dawid Ciężarkiewicz

In article <opsuj5i2iy23k2f5@nrage.netwin.co.nz>, Regan Heath says...
>
>On Wed, 27 Jul 2005 05:53:16 +0000 (UTC), Shammah Chancellor <Shammah_member@pathlink.com> wrote:
>> I think the ambiguity of
>>
>> key in hash
>> and
>> foreach( in int foo; array )
>>
>> should be removed.  I think "in" is better in the second example.  While
>> I
>> understand these two contexts
>> are _VERY_ different, I was under the impression that Walter was against
>> any
>> context sensitive syntax at
>> all.  (Just look a visual basic for an example of how context sensitive
>> languages make a mess.)  It also
>> makes it that much easier for parsers to do things with the code.
>>
>> Possibly the key in hash syntax could be replaced with something like this:
>>
>> hash has key
>> hash includes key
>> hash contains key
>>
>> My personal vote would be with hash has key.
>
>I prefer "contains" and I prefer a method format, eg.
>
>if (hash.contains(key)) //true/false
>if (hash.contains(key,value)) //true/false, sets value on true
>
>This allows a check and get with a single lookup and no pointers if desired (the 2nd form)
>
>Regan


Ah much better.  Just get rid of special operators alltogether.  Plus that second example clears up some problems with testing hashes before you use their values when they're classes.

Then you can easily do this:

if( hash.contains( key, value ) && value ) value.foo

I think that should be called get() though as before.  Contains leads you to believe that it contains that key-value pair.

And if we're going to start adding properties on AA's like
remove and .add why not go the rest of the way and add contains and get?

-Sha