On Wed, Jul 28, 2010 at 6:24 PM, Dave Whipp <d...@dave.whipp.name> wrote:
> Aaron Sherman wrote: > >> On Wed, Jul 28, 2010 at 11:34 AM, Dave Whipp <d...@dave.whipp.name> >> wrote: >> >> To squint at this slightly, in the context that we already have 0...1e10 >>> as >>> a sequence generator, perhaps the semantics of iterating a range should >>> be >>> unordered -- that is, >>> >>> for 0..10 -> $x { ... } >>> >>> is treated as >>> >>> for (0...10).pick(*) -> $x { ... } >>> >>> >> As others have pointed out, this has some problems. You can't implement >> 0..* >> that way, just for starters. >> > > I'd say that' a point in may favor: it demonstrates the integers and > strings have similar problems. If you pick items from an infinite set then > every item you pick will have an infinite number of digits/characters. > So, if I understand you correctly, you're happy about the fact that iterating over and explicitly lazy range would immediately result in failure? Sorry, not following. > > In smart-match context, "a".."b" includes "aardvark". No one has yet explained to me why that makes sense. The continued use of ASCII examples, of course, doesn't help. Does "a" .. "b" include "æther"? This is where Germans and Swedes, for example, don't agree, but they're all using the same Latin code blocks. I don't think you can reasonably bring locale into this. I think it needs to be purely a codepoint-oriented operator. If you bring locale into it, then the argument for not including composing an modifying characters goes out the window, and you're stuck in what I believe Dante called "the Unicode circle." If you treat this as a codepoint-based operator then you get a very simple result: "a".."b" is the range between the codepoint for "a" and the codepoint for "b". "aa" .. "bb" is the range between a sequence of two codepoints and a sequence of two other code points, which you can define in a number of ways (we've discussed a few, here) which don't involve having to expand the sequences to three or more codepoints. I've never accepted that the range between two strings of identical length should include strings of another length. That seems maximally non-intuitive (well, I suppose you could always return the last 100 words of Hamlet as an iterable IO object if you really wanted to confuse people), and makes string and integer ranges far too divergent. > Then the whole question of reversibility is moot. >>> >> Really? I don't think it is. In fact, you've simply made the problem pop >> up >> everywhere, and guaranteed that .. must behave totally unlike any other >> iterator. >> > > %hash.keys has similarly unordered semantics. Unordered semantics and shuffled values aren't the same thing. The reason that hash keys are unordered is that we cannot guarantee that any given implementation will store entries in any given relation to the input. Ranges have a well defined ordering associated with the elements that fall within the range by virtue of the basic definition of a range (LHS <= * <= RHS). Hashes have no ordering associated with their keys (though one can be imposed, e.g. by sort). Therefore %hash.keys.reverse is, for most purposes, equivalent to > %hash.keys. Argh! No, that's entirely untrue. %hash.keys and %hash.keys.reverse had better be the same elements, but reversed for all hashes which remain unmodified between the first and second call. -- Aaron Sherman Email or GTalk: a...@ajs.com http://www.ajs.com/~ajs