On Wed, Jul 21, 2010 at 3:47 PM, Jon Lang wrote:
> ... When comparing two strings, establishing an order between them is
> generally straightforward as long as both are composed of letters from
> the same alphabet and with the same case; but once you start mixing
> cases, introducing non-alphabet
Aaron Sherman wrote:
> Darren Duncan wrote:
> 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"
On Wed, Jul 21, 2010 at 3:55 PM, Darren Duncan wrote:
> Larry Wall wrote:
>>
>> On Tue, Jul 20, 2010 at 11:53:27PM -0400, Mark J. Reed wrote:
>> : In particular, consider that pi ~~ 0..4 is true,
>> : because pi is within the range; but pi ~~ 0...4 is false, because pi
>> : is not one of the gene
Larry Wall wrote:
On Tue, Jul 20, 2010 at 11:53:27PM -0400, Mark J. Reed wrote:
: In particular, consider that pi ~~ 0..4 is true,
: because pi is within the range; but pi ~~ 0...4 is false, because pi
: is not one of the generated elements.
Small point here, it's not because pi is fractional:
On Wed, Jul 21, 2010 at 9:46 AM, Aaron Crane wrote:
>
> > I think that "Ā" .. "Ē" should ĀĂĄĆĈĊČĎĐĒ
>
> If that's in the hope of producing a more "intuitive" result, then why
> not ĀB̄C̄D̄Ē?
>
> That's only partly serious. I'm acutely aware that choosing a baroque
> set of rules makes life harde
Aaron Sherman wrote:
> There's just an undefined codepoint smack in the middle of the Greek
> uppercase letters (U+03A2). I'm sure the Unicode specs have a rationale for
> that somewhere, but my guess is that there's some thousand-year-old debate
> about the Greek alphabet behind it.
It becomes c
[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 wrote:
> Aaron Sherman wrote:
>
>> 2) The spec doesn't put
On Wed, Jul 21, 2010 at 1:28 AM, Aaron Sherman wrote:
>
> For reference, this is the relevant section of the spec:
>
> Character positions are incremented within their natural range for any
> Unicode range that is deemed to represent the digits 0..9 or that is deemed
> to be a complete cyclical a
On Wed, Jul 21, 2010 at 09:23:11AM -0400, Mark J. Reed wrote:
: Strike the "counter to current Rakudo behavior" bit; Rakudo is
: behaving as specified in this instance. I must have been
: hallucinating.
Well, except that we both neglected precedence. Since ... is looser
than ~~, it must be writ
Strike the "counter to current Rakudo behavior" bit; Rakudo is
behaving as specified in this instance. I must have been
hallucinating.
On Wed, Jul 21, 2010 at 7:33 AM, Mark J. Reed wrote:
> Ok, I find that surprising (and counter to current Rakudo behavior),
> but thanks for the correction, and
Ok, I find that surprising (and counter to current Rakudo behavior),
but thanks for the correction, and sorry about the misinformation.
On Wednesday, July 21, 2010, Larry Wall wrote:
> On Tue, Jul 20, 2010 at 11:53:27PM -0400, Mark J. Reed wrote:
> : In particular, consider that pi ~~ 0..4 is tru
Smylers wrote:
> Jon Lang writes:
>> Approaching this with the notion firmly in mind that infix:<..> is
>> supposed to be used for matching ranges while infix:<...> should be
>> used to generate series:
>>
>> With series, we want C< $LHS ... $RHS > to generate a list of items
>> starting with $LHS
On Tue, Jul 20, 2010 at 11:53:27PM -0400, Mark J. Reed wrote:
: In particular, consider that pi ~~ 0..4 is true,
: because pi is within the range; but pi ~~ 0...4 is false, because pi
: is not one of the generated elements.
Small point here, it's not because pi is fractional: 3 ~~ 0...4 is
also f
13 matches
Mail list logo
