On 09/27/2011 04:24 PM, Clinton Jeffery wrote: > 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.
Interesting. I hadn't thought of sets in terms of holding keys, but rather attributes. Tables could also be thought of sets of relations (mapping attributes to values). Then, if one squints and thinks of lists as being ordered sets of attributes, it would be consistent to have member(X,x) as determining if x is an attribute of X. Of course, this would mean introducing the concept of 'attribute' as used in set theory and relations into the Unicon vernacular *and* possibly breaking existing code. So maybe a new function attribute(X,x...) that would implement the above point of view? Note that attribute(S, x) === member(S,x), attribute(T,x) === member(T,x), but attribute(L, x) ~=== member(L,x). element() would work as well as attribute(). This isn't a big point with me. I can live with the current member [now that I understand it - thanks, Clint] and write my own attribute/element() procedure. > 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. :-) Hmmm, what an interesting extension of find() that would be. I'd hate to be the one to come up with the formal description of how it behaves, however! -- Steve Wampler -- [email protected] The gods that smiled on your birth are now laughing out loud. ------------------------------------------------------------------------------ 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
