Lists vs sets
+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 therms of what you'd typically want to do with it.
Re: Lists vs sets
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
Re: Lists vs sets
That sounds like a subclass of Bag to me. But I don't think that thinking about who is subclassing whom is is how to think about this in Perl 6. All of these types are capable of doing the Iterable role, and that is what methods that could operate on a List, Array, Bag, or Set, should be calling for. On Oct 25, 2010, at 08:08 PM, 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 therms of what you'd typically want to do with it.
Re: Lists vs sets
Sorry: I meant capable *in theory*. It's not in the spec right now for Sets or Bags. On Oct 25, 2010, at 08:41 PM, Mason Kramer wrote: That sounds like a subclass of Bag to me. But I don't think that thinking about who is subclassing whom is is how to think about this in Perl 6. All of these types are capable of doing the Iterable role, and that is what methods that could operate on a List, Array, Bag, or Set, should be calling for. On Oct 25, 2010, at 08:08 PM, 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 therms of what you'd typically want to do with it.
Re: Lists vs sets
Mason Kramer wrote: But I don't think that thinking about who is subclassing whom is is how to think about this in Perl 6. All of these types are capable of doing the Iterable role, and that is what methods that could operate on a List, Array, Bag, or Set, should be calling for. This. Really, as long as Set does Iterable, it's not as important if it's treated as hash-like or list-like - though I'd still prefer to deal with @sets rather than %sets. Conceptually, it feels like a better fit. -- Jonathan Dataweaver Lang
Re: Lists vs sets
yary wrote: 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 therms of what you'd typically want to do with it. If a list is a set, does that mean that a list only contains/returns each element once when iterated? If a list can have duplicates, then a list isn't a set, I would think. -- Darren Duncan
Re: Lists vs sets
Darren Duncan wrote: If a list is a set, does that mean that a list only contains/returns each element once when iterated? If a list can have duplicates, then a list isn't a set, I would think. -- Darren Duncan Thus Mason's point about Bags. Really, I think that Mason's right in that we should be looking as which roles each of these does rather than which classes each of them is. -- Jonathan Dataweaver Lang
