davepermen wrote:

[...]
> how this would be done with re's ?
[...]

  if((new RegExp("string","")).test("a string")) puts("matched");

I would like that Walter would have provided some syntactical sugar to omit an empty attributes list.

So long.

Ugh , that was probably the worst example I could have written.  I just mean

if ( item in collection ) {}

Ignore the example ( I would probably just use if ( find( str,"str") != -1 )
for that ).

Charlie

However in my own defenese if opIn was overloadable we could also do

if ( subcollection in largercollection ) also :)  ( not for arrays )


"Manfred Nowak" <svv1999@hotmail.com> wrote in message news:c12ck7$3e2$1@digitaldaemon.com...
> davepermen wrote:
>
> [...]
> > how this would be done with re's ?
> [...]
>
>   if((new RegExp("string","")).test("a string")) puts("matched");
>
> I would like that Walter would have provided some syntactical sugar to omit an empty attributes list.
>
> So long.

Maybe I'm too old-fashioned, but IMHOFO a lauguage should choose it's primitives well, support them well, (within the compiler) and leave the other fancies to libraries.

Sorry, but I don't think "collections" should be internalized to the compiler, and its easy enough to write a function, a template, or a class to do what you want.  Write it, tune it the way you want, and use it as needed.

And about subcollections within (or not) collections, overlapping (or not) with other subcollections, ad infinitum - I think not - have you ever heard of loops? - or were you thinking that the compiler should read your mind and know that this collection should be hashed, and in such a way that subcollection1 and subcollection2 can easily be subsetted, and have everything done in the most efficient way (presuming that this is not data dependent - or maybe it should adjust for that dynamically)?

-larry

In article <c12ng3$nch$1@digitaldaemon.com>, C says...
>
>Ugh , that was probably the worst example I could have written.  I just mean
>
>if ( item in collection ) {}
>
>Ignore the example ( I would probably just use if ( find( str,"str") != -1 )
>for that ).
>
>Charlie
>
>However in my own defenese if opIn was overloadable we could also do
>
>if ( subcollection in largercollection ) also :)  ( not for arrays )
>
>
>"Manfred Nowak" <svv1999@hotmail.com> wrote in message news:c12ck7$3e2$1@digitaldaemon.com...
>> davepermen wrote:
>>
>> [...]
>> > how this would be done with re's ?
>> [...]
>>
>>   if((new RegExp("string","")).test("a string")) puts("matched");
>>
>> I would like that Walter would have provided some syntactical sugar to omit an empty attributes list.
>>
>> So long.
>
>

"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:c12787$2rkt$1@digitaldaemon.com...
> While it was 2/18/04 10:08 PM throughout the UK, C sprinkled little black dots on a white screen, and they fell thus:
>
> > Can we get this ? And also add it to arrays ?
> >
> > char []  x = "a string";
> >
> > if ( "string" in x ) puts("matched");
>
> That would be semantics bending.  The role of 'in' is to determine whether a key exists in an associative array.  If it's ever defined on normal arrays, it would have to mean the given index being within the array's bounds.

i don't agree
I often wan't to write something like this:
int[] numbers;
int x;

if(x in numbers)
{
    //do something
}

but then i remember that there is no in for arrays and have to do it like
this
foreach(int i; numbers)
{
    if(i == x)
    {
        //do something
        break;
    }
}

Which is a lot more typing when the types are more complex than int[]




>
> We have '~' for string concatenation, to avoid confusingly overloading '+'.  Surely we shouldn't be confusingly overloading 'in' either?
>
> Stewart.
>
> --
> My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

I am must be horrible at explaining, or there is a misunderstanding somewhere.  I want an operator for a class , for your own collections.

struct Deuque(T) {

 T[] collection;

 bit opIn(T t ) { /* enumerate through collection, return true if found*/ }

 }

 bit opIn(T[] t ) { /* return true if all of t is in collection */ }

 }

}


Deuque!(int) d;
/* fill d */
int userInput = 0;
/* get var from user */

if ( userInput in d ) {
  doFoo();
}


Why did u think I was talking about primitives ?  For D at least doesnt an operator imply a class / struct / template ?

I dont want the compiler to do anything more than translate the 'in' operator to the corresponding member function.

Charles.


"larry cowan" <larry_member@pathlink.com> wrote in message news:c12p6j$qh8$1@digitaldaemon.com...
> Maybe I'm too old-fashioned, but IMHOFO a lauguage should choose it's
primitives
> well, support them well, (within the compiler) and leave the other fancies
to
> libraries.
>
> Sorry, but I don't think "collections" should be internalized to the
compiler,
> and its easy enough to write a function, a template, or a class to do what
you
> want.  Write it, tune it the way you want, and use it as needed.
>
> And about subcollections within (or not) collections, overlapping (or not)
with
> other subcollections, ad infinitum - I think not - have you ever heard of
loops?
> - or were you thinking that the compiler should read your mind and know
that
> this collection should be hashed, and in such a way that subcollection1
and
> subcollection2 can easily be subsetted, and have everything done in the
most
> efficient way (presuming that this is not data dependent - or maybe it
should
> adjust for that dynamically)?
>
> -larry
>
> In article <c12ng3$nch$1@digitaldaemon.com>, C says...
> >
> >Ugh , that was probably the worst example I could have written.  I just
mean
> >
> >if ( item in collection ) {}
> >
> >Ignore the example ( I would probably just use if ( find( str,"str")
!= -1 )
> >for that ).
> >
> >Charlie
> >
> >However in my own defenese if opIn was overloadable we could also do
> >
> >if ( subcollection in largercollection ) also :)  ( not for arrays )
> >
> >
> >"Manfred Nowak" <svv1999@hotmail.com> wrote in message news:c12ck7$3e2$1@digitaldaemon.com...
> >> davepermen wrote:
> >>
> >> [...]
> >> > how this would be done with re's ?
> >> [...]
> >>
> >>   if((new RegExp("string","")).test("a string")) puts("matched");
> >>
> >> I would like that Walter would have provided some syntactical sugar to omit an empty attributes list.
> >>
> >> So long.
> >
> >
>
>
>

In article <c129oq$2vmq$1@digitaldaemon.com>, Matthew says...
>
>
>"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:c12787$2rkt$1@digitaldaemon.com...
>> While it was 2/18/04 10:08 PM throughout the UK, C sprinkled little black dots on a white screen, and they fell thus:
>>
>> > Can we get this ? And also add it to arrays ?
>> >
>> > char []  x = "a string";
>> >
>> > if ( "string" in x ) puts("matched");
>>
>> That would be semantics bending.  The role of 'in' is to determine whether a key exists in an associative array.  If it's ever defined on normal arrays, it would have to mean the given index being within the array's bounds.
>
>Why so? What's wrong with 'in' meaning just an element exists within a collection? Why must it ape the semantics of the associative arrays?

The use of in would be entirely ambiguous though.  If you'd use in on an associative array, right now it'll return a bool if the key exists in the array. If it would be extended to also say whether a value exists in a collection/array, what would it mean if the operator was used on an associative array?

IMO, the in operator should be overloadable to make classes that mimic associative arrays, and if an operator is really needed to check whether a value exists in an array, it would need to be a new operator (though... it might be a bit confusing since when people see in, they'll think it means to check for value if they haven't used that part of the language before...)

C wrote:

[...]
> Why did u think I was talking about primitives ?
[...]

Ahh, I've got it. Surely I am with you to be able to overload `in'.

So long.

"Luke D" <Luke_member@pathlink.com> wrote in message news:c13bf6$1s53$1@digitaldaemon.com...
> In article <c129oq$2vmq$1@digitaldaemon.com>, Matthew says...
> >
> >
> >"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:c12787$2rkt$1@digitaldaemon.com...
> >> While it was 2/18/04 10:08 PM throughout the UK, C sprinkled little black dots on a white screen, and they fell thus:
> >>
> >> > Can we get this ? And also add it to arrays ?
> >> >
> >> > char []  x = "a string";
> >> >
> >> > if ( "string" in x ) puts("matched");
> >>
> >> That would be semantics bending.  The role of 'in' is to determine whether a key exists in an associative array.  If it's ever defined on normal arrays, it would have to mean the given index being within the array's bounds.
> >
> >Why so? What's wrong with 'in' meaning just an element exists within a collection? Why must it ape the semantics of the associative arrays?
>
> The use of in would be entirely ambiguous though.  If you'd use in on an associative array, right now it'll return a bool if the key exists in the
array.
> If it would be extended to also say whether a value exists in a collection/array, what would it mean if the operator was used on an
associative
> array?

The same thing as it does now. I don't see the problem personally, but then I've always looked at maps/assoc-arrays as having the keys being the important thing.

Nonetheless, I understand your point. It needs further thought.

How do other languages deal with this?

> IMO, the in operator should be overloadable to make classes that mimic associative arrays, and if an operator is really needed to check whether a
value
> exists in an array, it would need to be a new operator (though... it might
be a
> bit confusing since when people see in, they'll think it means to check
for
> value if they haven't used that part of the language before...)