sorry forgot cc
>________________________________
>From: David Gamey <[email protected]>
>To: "[email protected]" <[email protected]>
>Sent: Tuesday, September 27, 2011 9:30:12 PM
>Subject: Re: [Unicon-group] [unicon-group] member
>
>
>Clint,
>
>
>
>As someone may be using this, I'm in favor of documentation.
>
>
>
>There is probably a case for member2(X,x) where X is list or table and we mean
>that X[k] == x is different and member2 is a more meaningful name than I can
>come up with at this moment.
>
>
>
>
>Overloading find would likely do nicely unless it's going to bite me
>sometime.
>
>
>
>
>
>There is also the case of member(X,x,y,z) and member2/find(X,x,y,z).
>
>
>The other question that arises is what does find return in these cases? Does
>it generate results as well?
>
>
>Consider L := [1,2,2,3,4,5,2] and find(L,2) or find(L,3,4,5).
>
>
>
>
>
>David
>
>
>
>
>>________________________________
>>From: Clinton Jeffery <[email protected]>
>>To: David Gamey <[email protected]>
>>Cc: Steve Wampler <[email protected]>;
>>"[email protected]" <[email protected]>
>>Sent: Tuesday, September 27, 2011 7:24:15 PM
>>Subject: Re: [Unicon-group] [unicon-group] member
>>
>>
>>Actually, member()'s current semantics for lists are understandable even if
>>they aren't what you want. But we can discuss whether to fix or better
>>document them.
>>
>>member(L, x) in Icon is a runtime error
>>
>>member(L, x) in Unicon at the moment is implemented to be consistent with
>> member(T, x), and member(S, x), which both test whether x is a valid key
>>in T or S.
>> The goal is polymorphism and consistency rather than maximal utility; the
>>view is
>> that a list is like a special-case of a table in which keys are integers
>>from 1 to n.
>>
>>So instead of being similar to !L===x its semantics is closer to key(L)===x,
>>which is
>>to say 1 <= x <= *L
>>
>>So, we could talk about throwing out polymorphism in favor of utility, or we
>>could talk
>>about whether a different function, other than member, ought to be built-in
>>that would
>>search through the elements; that is the job of find(), isn't it. :-)
>>
>>Cheers,
>>Clint
>>
>>
>>On Tue, Sep 27, 2011 at 2:00 PM, David Gamey <[email protected]> wrote:
>>
>>I think it's a bug.
>>>
>>>
>>>From ub3 "member(x, ...) returns x if its second and subsequent arguments
>>>are all members of set,
>>>cset, list or table x but fails otherwise. If x is a cset, all of the
>>>characters in subsequent
>>>string arguments must be present in x in order to succeed."
>>>
>>>
>>>Of course he could always do something like this ....
>>>
>>>
>>>procedure member(X[])
>>>static builtin
>>>initial builtin := proc("member",0)
>>>if *X > 1 then
>>> if type(X[1]) ~== "list" then return builtin!X
>>> else {
>>> every x := X[2 to *X] do
>>> if x
=== !X[1] then next else fail
>>> return X[1]
>>> }
>>>end
>>>
>>>
>>>in the short term.
>>>
>>>
>>>David
>>>
>>>
>>>>________________________________
>>>>From: Steve Wampler <[email protected]>
>>>>To: [email protected]
>>>>Sent: Tuesday, September 27, 2011 9:16:33 AM
>>>>Subject: Re: [Unicon-group] [unicon-group] member
>>>>
>>>>
>>>>On Tue, Sep 27, 2011 at 01:59:01PM +0100, John
Sampson wrote:
>>>>> For beginners it might be useful in a future version if an attempt to use
>>>>> 'member' with a list as first argument gave an error message. It is not
>>>>> obvious from the term that it applies to sets and tables but not lists.
>>>>> If one uses it with a list it just mysteriously fails.
>>>>
>>>>John has a good point and raises an interesting question:
>>>>
>>>>Why shouldn't member(["a","b","c"], "c") work? Yes, it would
>>>>be slower than testing membership in a set or table, but...
>>>>
>>>>
>>>>
>>>>------------------------------------------------------------------------------
>>>>All the data continuously generated in your IT infrastructure contains a
>>>>definitive record of customers, application performance, security
>>>>threats, fraudulent activity and more. Splunk takes this data and makes
>>>>sense of it. Business sense. IT sense. Common sense.
>>>>http://p.sf.net/sfu/splunk-d2dcopy1
>>>>_______________________________________________
>>>>Unicon-group mailing list
>>>>[email protected]
>>>>https://lists.sourceforge.net/lists/listinfo/unicon-group
>>>>
>>>>
>>>>
>>>------------------------------------------------------------------------------
>>>All the data continuously generated in your IT infrastructure contains a
>>>definitive record of customers, application performance, security
>>>threats, fraudulent activity and more. Splunk takes this data and makes
>>>sense of it. Business sense. IT sense. Common sense.
>>>http://p.sf.net/sfu/splunk-d2dcopy1
>>>_______________________________________________
>>>Unicon-group mailing list
>>>[email protected]
>>>https://lists.sourceforge.net/lists/listinfo/unicon-group
>>>
>>>
>>
>>
>>
>
>------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Unicon-group mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/unicon-group
