yary wrote: > +1 on this > On Mon, Oct 25, 2010 at 4:56 PM, Jon Lang <datawea...@gmail.com> wrote: >> As for the bit about sets vs. lists: personally, I'd prefer that there >> not be quite as much difference between them as there currently is. >> That is, I'd rather sets be usable wherever lists are called for, with >> the caveat that there's no guarantee about the order in which you'll >> get the set's members; only that you'll get each member exactly once. >> The current approach is of much more limited value in programming. > > I think of a list conceptually as a subclass of a set- a list is a > set, with indexing and ordering added. Implementation-wise I presume > they are quite different, since a set falls nicely into the keys of a > hash in terms of what you'd typically want to do with it.
By "implementation-wise", are you referring to "under the hood details"? If so, I agree: it's OK to implement a set internally as a hash. But as far as the user is concerned, it ought to look like a list. Well, technically, a list should look like a set that has additional features. But as Damian pointed out earlier, one reason why he chose to use lists in his transjunction module instead of sets is that as they are now, you can iterate over a list; but you can't iterate over a set. From a practical standpoint, sets would be considerably more attractive if you could iterate over them as well without having to first turn them into lists via the .k method. Thus my suggestion to treat a set as a list of unique values without a guaranteed order, at least as far as the user is concerned. -- Jonathan "Dataweaver" Lang
