This is going to be a rambling answer, as I have a number of questions but no firm conclusions. Please bear with me.
Mason Kramer wrote: > Having Bags flatten in list context is pretty crucial to their being "as > easy and terse to use as arrays", because flattening is fundamental to > how Arrays are used, and Bags will be used like Arrays. Luckily, > however, %, which implies the Associative contract, also flattens in list > context. If Bags and Sets are sigiled with %, they should flatten, and > all that remains is to make sure they flatten into a list of keys, and > not a list of enums. The only qualm that I have with using % as a prefix for baggy things is that % carries the connotation that you're dealing with key/value pairs. While baggy things _can_ be thought of as pairs, they're value/membership pairs rather than key/value pairs; and the membership side of the pair should be hidden from view unless explicitly requested. In short, a casual programmer ought to be encouraged to think of a baggy thing as being a collection of values; the % sigil implicitly encourages him to think of it as a collection of pairs. That said, the problem with % is that baggies implement its features in an unusual way; the problem with @ is that baggies don't implement all of its features. Conceptually, @ (a collection of values) is a better fit than % (a collection of pairs); but technically, the reverse is true: % (does Associative) is a better fit than @ (does Positional). Query: should %x.k, %x.v, %x.kv, and %x.pair produce lists, bags, or sets? As I understand it, right now all four produce lists. I could see a case for having %x.k and %x.pair produce sets, while %x.kv definitely should produce a list (since even though the overall order doesn't matter, which even element follows which odd element _does_ matter); and %x.v might reasonably produce a bag. OTOH, if this is done then there will be no way to talk about, e.g., "%x.k[0]". I'm wondering if bags and sets _should_ do Positional, but with the caveat that the order is arbitrary. After all, that's what currently happens with %x.k: you get a list of the keys, but with the understanding that the order in which you get them is ultimately meaningless. Or is it that the difference between Iterable and Positional is that Positional provides random access to its membership, whereas Iterable only guarantees that you can walk through the members? Another way to phrase my concern is this: one reason why Perl 6 has gone with nominal typing rather than structural typing is that "does x" can and does promise more than just "implements the same features that x implements"; it also promises something about the way in which said features will be implemented. In this regard, I would argue that baggies should not do Associative; because even though they implement all of the same features that Associative promises to implement, they don't do so in a way that's compatible with Associative's underlying philosophy of keys and values. And if they don't do Associative, it doesn't make sense for them to use the % sigil. I hesitate to suggest this; but might we want a special sigil for Iterable, to be used when neither Positional nor Associative is quite right? Such a sigil might be useful for more than just baggies; for instance, a stream is Iterable but neither Positional nor Associative. -- Jonathan "Dataweaver" Lang
