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
