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
