[changing the subject because it's now clear we have two different
discussions on our hands. I think we're at or closing in on a consensus for
"a" .. "z", and this discussion is "aa" .. "bb"]

On Wed, Jul 21, 2010 at 1:56 AM, Darren Duncan <dar...@darrenduncan.net>wrote:

> Aaron Sherman wrote:
>> 2) The spec doesn't put this information anywhere near the definition of
>> the
>> range operator. Perhaps we can make a note? This was a source of confusion
>> for me.
> My impression is that a "Range" primarily defines an "interval" in terms of
> 2 endpoint values such that it defines a possibly infinite set values
> between those endpoints.

I don't think that has much to do with the fact that it was quite reasonable
for me to look to the definition of ".." is S03 for what the range between
two characters contains.

3) It seems that there are two competing multi-character approaches and both
>> seem somewhat valid. Should we use a pragma to toggle behavior between A
>> and
>> B:
>>  A: "aa" .. "bb" contains "az"
>>  B: "aa" .. "bb" contains ONLY "aa", "ab", "ba" and "bb"
> I would find A to be the only reasonable answer.

[Before I respond, let's agree that, below, I'm going to say things like
"generates" when talking about "..". What I'm describing is the idea that a
value exists in the range given, not that a range is actually a list.]

I would find B to be the only reasonable answer, but enough people seem to
think the other way that I understand there's a valid need to be able to get
both behaviors.

> If you want B's semantics then use "..." instead; ".." should not be
> overloaded for that.

I wasn't really distinguishing between ".." and "..." as I'm pretty sure
they should have the same behavior, here. The case where I'm not sure they
should have the same behavior is "apple" .. "orange". Frankly, I think that
there's no right solution there. There's the one I proposed in my original
message (treat each character index as a distinct sequence and then
increment in a base defined by all of the sequences), but even I don't like
that. To generate all possible strings of length 5+ that sort between those
two is another suggestion, but then what do you expect "father-in-law" ..
"orange" to do? Punctuation throws a whole new dimension in there, and I'm
immediately lost. When you go to my Japanese example from many messages ago,
which I got from a fairly typical Web site and contained 2 Scripts with 4
different General Categories, I begin to need pharmaceuticals.

I don't see any value in having different rules for what .. and ... generate
in these cases, however. (frankly, I'm still on the fence about ... for
single endpoints, which I think should just devolve to .. (... with a list
for LHS is another animal, of course))

> If there were to be any similar pragma, then it should control matters like
> "collation", or what nationality/etc-specific subtype of Str the 'aa' and
> 'bb' are blessed into on definition, so that their collation/sorting/etc
> rules can be applied when figuring out if a particular $foo~~$bar..$baz is
> TRUE or not.

For inclusion (e.g. does "aaaaaa" .. "zzzzzz" generate "cliché") see the
single-character range discussion, which has already touched on locale

Aaron Sherman
Email or GTalk: a...@ajs.com

Reply via email to