On Sun, Aug 1, 2010 at 11:39 PM, Martin D Kealey
wrote:
> In any case I'd much rather prefer that the behaviour be lexically scoped,
> with either adverbs or pragmata, not with the action-at-a-distance that's
> caused by tagging something as fundamental as a String.
In many cases the collation is
Martin D Kealey wrote:
On Wed, 28 Jul 2010, Darren Duncan wrote:
I think that a general solution here is to accept that there may be more
than one valid way to sort some types, strings especially, and so
operators/routines that do sorting should be customizable in some way so
users can pick the
On Wed, 28 Jul 2010, Darren Duncan wrote:
> I think that a general solution here is to accept that there may be more
> than one valid way to sort some types, strings especially, and so
> operators/routines that do sorting should be customizable in some way so
> users can pick the behaviour they wan
Aaron Sherman wrote:
> In the end, I'm now questioning the difference between a junction and
> a Range... which is not where I thought this would go.
Conceptually, they're closely related. In particular, a range behaves
a lot like an any() junction. Some differences:
1. An any() junction always
On Fri, Jul 30, 2010 at 6:45 PM, Doug McNutt wrote:
> Please pardon intrusion by a novice who is anything but object oriented.
No problem. Sometimes a fresh perspective helps to illuminate things.
Skipping ahead...
> Are you guise sure that the "..." and ".." operators in perl 6 shouldn't make
Please pardon intrusion by a novice who is anything but object oriented.
I consider myself a long time user of perl 5. I love it and it has completely
replaced FORTRAN as my compiler of choice. "Programming Perl" is so dog-eared
that I may need a replacement. I joined this list when I thought th
On Thu, Jul 29, 2010 at 9:51 PM, Aaron Sherman wrote:
> My only strongly held belief, here, is that you should not try to answer any
> of these questions for the default range operator on
> unadorned, context-less strings. For that case, you must do something that
> makes sense for all Unicode cod
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/29/10 08:15 , Leon Timmermans wrote:
> On Thu, Jul 29, 2010 at 3:24 AM, Darren Duncan
> wrote:
>> $foo ~~ $a..$b :QuuxNationality # just affects this one test
>
> I like that
>
>> $bar = 'hello' :QuuxNationality # applies anywhere the Str
On Wed, Jul 28, 2010 at 9:24 PM, Darren Duncan wrote:
> Jon Lang wrote:
>
>> I don't know enough about Unicode to suggest how to solve this.
>>
>>
Thankfully, I know little enough to take up the challenge ;-)
> All I can
>>> say is that my example above should never return a valid Range object
On Thu, Jul 29, 2010 at 5:15 AM, Leon Timmermans wrote:
> On Thu, Jul 29, 2010 at 3:24 AM, Darren Duncan
> wrote:
>> Some possible examples of customization:
>>
>> $foo ~~ $a..$b :QuuxNationality # just affects this one test
>
> I like that
>
>> $bar = 'hello' :QuuxNationality # applies anyw
On Thu, Jul 29, 2010 at 3:24 AM, Darren Duncan wrote:
> Some possible examples of customization:
>
> $foo ~~ $a..$b :QuuxNationality # just affects this one test
I like that
> $bar = 'hello' :QuuxNationality # applies anywhere the Str value is used
>
What if you compare a QuuxNationality St
On Wed, Jul 28, 2010 at 10:35 PM, Brandon S Allbery KF8NH
wrote:
> On 7/28/10 8:07 PM, Michael Zedeler wrote:
>> On 2010-07-29 01:39, Jon Lang wrote:
>>> Aaron Sherman wrote:
> In smart-match context, "a".."b" includes "aardvark".
No one has yet explained to me why that makes sense. The
On 7/28/10 8:07 PM, Michael Zedeler wrote:
> On 2010-07-29 01:39, Jon Lang wrote:
>> Aaron Sherman wrote:
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 "
Jon Lang wrote:
I don't know enough about Unicode to suggest how to solve this. All I can
say is that my example above should never return a valid Range object unless
there is a way I can specify my own ordering and I use it.
That actually says something: it says that we may want to reconsider
On 2010-07-29 02:19, Jon Lang wrote:
Michael Zedeler wrote:
Jon Lang wrote:
This is definitely something for the Unicode crowd to look into. But
whatever solution you come up with, please make it compatible with the
notion that "aardvark".."apple" can be used to match any word in the
On Jul 28, 2010, at 1:27 PM, Mark J. Reed wrote:
> On Wednesday, July 28, 2010, Jon Lang wrote:
>> Keep it simple, folks! There are enough corner cases in Perl 6 as
>> things stand; we don't need to be introducing more of them if we can
>> help it.
>
> Can I get an Amen? Amen!
> --
> Mark J.
On Jul 28, 2010, at 1:37 PM, Mark J. Reed wrote:
> On Wed, Jul 28, 2010 at 2:30 PM, Chris Fields wrote:
>> On Jul 28, 2010, at 1:27 PM, Mark J. Reed wrote:
>>> Can I get an Amen? Amen!
>>> --
>>> Mark J. Reed
>>
>> +1. I'm agnostic ;>
>
> Militant? :) ( http://tinyurl.com/3xjgxnl )
>
> No
Michael Zedeler wrote:
> Jon Lang wrote:
>> This is definitely something for the Unicode crowd to look into. But
>> whatever solution you come up with, please make it compatible with the
>> notion that "aardvark".."apple" can be used to match any word in the
>> dictionary that comes between those
On 2010-07-29 01:39, Jon Lang wrote:
Aaron Sherman wrote:
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,
On 2010-07-29 00:24, Dave Whipp wrote:
Aaron Sherman wrote:
On Wed, Jul 28, 2010 at 11:34 AM, Dave Whipp
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
Aaron Sherman wrote:
>> 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
Darren Duncan wrote:
> Does "..." also come with the 4 variations of endpoint inclusion/exclusion?
>
> If not, then it should, as I'm sure many times one would want to do this,
> say:
>
> for 0...^$n -> {...}
You can toggle the inclusion/exclusion of the ending condition by
choosing between "..."
On Wed, Jul 28, 2010 at 6:24 PM, Dave Whipp wrote:
> Aaron Sherman wrote:
>
>> On Wed, Jul 28, 2010 at 11:34 AM, Dave Whipp
>> 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
On Wed, Jul 28, 2010 at 6:24 PM, Dave Whipp wrote:
> Aaron Sherman wrote:
>
>> On Wed, Jul 28, 2010 at 11:34 AM, Dave Whipp
>> 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
Darren Duncan wrote:
Dave Whipp wrote:
Similarly (0..1).Seq should most likely return Real numbers
No it shouldn't, because the endpoints are integers.
If you want Real numbers, then say "0.0 .. 1.0" instead.
-- Darren Duncan
That would be inconsistent. $x ~~ 0..1 means 0 <= $x <= 1. The f
Dave Whipp wrote:
Similarly (0..1).Seq should most likely return Real numbers
No it shouldn't, because the endpoints are integers.
If you want Real numbers, then say "0.0 .. 1.0" instead.
-- Darren Duncan
Aaron Sherman wrote:
On Wed, Jul 28, 2010 at 11:34 AM, Dave Whipp 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 (
Darren Duncan wrote:
Aaron Sherman wrote:
The more I look at this, the more I think ".." and "..." are reversed.
I would rather that ".." stay with intervals and "..." with generators.
Another thing to consider if one is looking at huffmanization is how often the
versions that exclude en
Aaron Sherman wrote:
The more I look at this, the more I think ".." and "..." are reversed. ".."
has a very specific and narrow usage (comparing ranges) and "..." is
probably going to be the most broadly used operator in the language outside
of quotes, commas and the basic, C-derived math and log
On Wed, Jul 28, 2010 at 11:29 PM, Aaron Sherman wrote:
> The more I look at this, the more I think ".." and "..." are reversed. ".."
> has a very specific and narrow usage (comparing ranges) and "..." is
> probably going to be the most broadly used operator in the language outside
> of quotes, com
On Wed, Jul 28, 2010 at 2:29 PM, Aaron Sherman wrote:
>
> The more I look at this, the more I think ".." and "..." are reversed. ".."
> has a very specific and narrow usage (comparing ranges) and "..." is
> probably going to be the most broadly used operator in the language outside
> of quotes, co
On Wed, Jul 28, 2010 at 11:34 AM, Dave Whipp 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).p
Moritz Lenz wrote:
I fear what Perl 6 needs is not to broaden the range of discussion even
further, but to narrow it down to the essential points. Personal opinion
only.
OK, as a completely serious proposal, the semantics of "for 0..10 { ...
}" should be for the compiler to complain "sorry, t
Dave Whipp wrote:
> Moritz Lenz wrote:
>> Dave Whipp wrote:
>>>for 0..10 -> $x { ... }
>>> is treated as
>>>for (0...10).pick(*) -> $x { ... }
>>
>> Sorry, I have to ask. Are you serious? Really?
>
> Ah, to reply, or not to reply, to rhetorical sarcasm ... In this case, I
> think I will:
Moritz Lenz wrote:
Dave Whipp wrote:
for 0..10 -> $x { ... }
is treated as
for (0...10).pick(*) -> $x { ... }
Sorry, I have to ask. Are you serious? Really?
Ah, to reply, or not to reply, to rhetorical sarcasm ... In this case, I
think I will:
Was my specific proposal entirely serio
On Wed, Jul 28, 2010 at 2:30 PM, Chris Fields wrote:
> On Jul 28, 2010, at 1:27 PM, Mark J. Reed wrote:
>> Can I get an Amen? Amen!
>> --
>> Mark J. Reed
>
> +1. I'm agnostic ;>
Militant? :) ( http://tinyurl.com/3xjgxnl )
Nothing inherently religious about "amen" (or me), but I'll accept
"+
On Wednesday, July 28, 2010, Jon Lang wrote:
> Keep it simple, folks! There are enough corner cases in Perl 6 as
> things stand; we don't need to be introducing more of them if we can
> help it.
Can I get an Amen? Amen!
--
Mark J. Reed
TSa wrote:
> Swapping the endpoints could mean swapping inside test to outside
> test. The only thing that is needed is to swap from && to ||:
>
> $a .. $b # means $a <= $_ && $_ <= $b if $a < $b
> $b .. $a # means $b <= $_ || $_ <= $a if $a < $b
This is the same sort of discontinuity
> Swapping the endpoints could mean swapping inside test to outside
> test. The only thing that is needed is to swap from && to ||:
>
> $a .. $b # means $a <= $_ && $_ <= $b if $a < $b
> $b .. $a # means $b <= $_ || $_ <= $a if $a < $b
I think that's what "not", "!" are for!
On Wednesday, 28. July 2010 05:12:52 Michael Zedeler wrote:
> Writing ($a .. $b).reverse doesn't make any sense if the result were a
> new Range, since Ranges should then only be used for inclusion tests (so
> swapping endpoints doesn't have any meaningful interpretation), but
> applying .reverse c
yary wrote:
> though would a parallel batch of an anonymous block be more naturally written
> as
> all(0...10) -> $x { ... } # Spawn 11 threads
No,
hyper for 0..10 -> $x { ... } # spawn as many threads
# as the compiler thinks are reasonable
I think one (already specced) syntax for the
On Wed, Jul 28, 2010 at 8:34 AM, Dave Whipp 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).pic
Dave Whipp 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 { ... }
Sorry
Dave Whipp 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 { ... }
>
> Then the wh
Michael Zedeler wrote:
This is exactly why I keep writing posts about Ranges being defunct as
they have been specified now. If we accept the premise that Ranges are
supposed to define a kind of linear membership specification between two
starting points (as in math), it doesn't make sense that
Michael Zedeler wrote:
This is exactly why I keep writing posts about Ranges being defunct as
they have been specified now. If we accept the premise that Ranges are
supposed to define a kind of linear membership specification between two
starting points (as in math), it doesn't make sense that
On 2010-07-28 06:54, Martin D Kealey wrote:
On Wed, 28 Jul 2010, Michael Zedeler wrote:
Writing for ($a .. $b).reverse -> $c { ...} may then blow up because it
turns out that $b doesn't have a .succ method when coercing to sequence
(where the LHS must have an initial value), just like
On 2010-07-27 23:50, Aaron Sherman wrote:
PS: On a really abstract note, requiring that ($a .. $b).reverse be lazy
will put new constraints on the right hand side parameter. Previously, it
didn't have to have a value of its own, it just had to be comparable to
other values. for example:
for $
Aaron Sherman wrote:
> As a special case, perhaps you can treat ranges as special and not as simple
> iterators. To be honest, I wasn't thinking about the possibility of such
> special cases, but about iterators in general. You can't generically reverse
> lazy constructs without running afoul of th
Sorry I haven't responded for so long... much going on in my world.
On Mon, Jul 26, 2010 at 11:35 AM, Nicholas Clark wrote:
> On Tue, Jul 20, 2010 at 07:31:14PM -0400, Aaron Sherman wrote:
>
> > 2) We deny that a range whose LHS is "larger" than its RHS makes sense,
> but
> > we also don't provi
On Tue, Jul 20, 2010 at 07:31:14PM -0400, Aaron Sherman wrote:
> 2) We deny that a range whose LHS is "larger" than its RHS makes sense, but
> we also don't provide an easy way to construct such ranges lazily otherwise.
> This would be annoying only, but then we have declared that ranges are the
>
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
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
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 and ending with $RHS.
Darren Duncan wrote:
specific, the generic "eqv" operator, or "before" etc would have to be
Correction, I meant to say "cmp", not "eqv", here. -- Darren Duncan
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 define
OK, there's a lot here and my head is swimming, so let me re-consolidate and
re-state (BTW: thanks Jon, you've really helped me understand, here).
1) The spec is somewhat vague, but the proposal that I made for single
characters is not an unreasonable interpretation of what's there. Thus, we
could
On Wed, Jul 21, 2010 at 12:04 AM, Jon Lang wrote:
> Mark J. Reed wrote:
>> Perhaps the syllabic kana could be the "integer" analogs, and what you
>> get when you iterate over the range using ..., while the modifier kana
>> would not be generated by the series ア ... ヴ but would be considered
>> in
Mark J. Reed wrote:
> Perhaps the syllabic kana could be the "integer" analogs, and what you
> get when you iterate over the range using ..., while the modifier kana
> would not be generated by the series ア ... ヴ but would be considered
> in the range ア .. ヴ? I wouldn't object to such script-spe
On Tue, Jul 20, 2010 at 11:28 PM, Aaron Sherman wrote:
> So, what's the intention of the range operator, then?
... is a generator that lazily enumerates a series. .. is a
constructor for a Range object. They're two different things, with
different behaviors. In particular, consider that pi ~~
Aaron Sherman wrote:
> So, what's the intention of the range operator, then? Is it just there to
> offer backward compatibility with Perl 5? Is it a vestige that should be
> removed so that we can Huffman ... down to ..?
>
> I'm not trying to be difficult, here, I just never knew that ... could
> o
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:
Aaron Sherman wrote:
> Walk with me a bit, and let's explore the concept of intuitive character
> ranges? This was my suggestion, which se
Side note: you could get around some of the problems, below, but in order to
do so, you would have to exhaustively express all of Unicode using the Str
builtin module's RANGES constant. In fact, as it is now, it defines ASCII
lowercase, but doesn't define Latin lowercase. Presumably because doing s
On Tue, Jul 20, 2010 at 10:00 PM, Jon Lang wrote:
> Solomon Foster wrote:
>> Ranges haven't been intended to be the "right way" to construct basic
>> loops for some time now. That's what the "..." series operator is
>> for.
>>
>> for 1e10 ... 1 -> $i {
>> # whatever
>> }
>>
>> is la
Solomon Foster wrote:
> Ranges haven't been intended to be the "right way" to construct basic
> loops for some time now. That's what the "..." series operator is
> for.
>
> for 1e10 ... 1 -> $i {
> # whatever
> }
>
> is lazy by the spec, and in fact is lazy and fully functional in
>
On Tue, Jul 20, 2010 at 7:31 PM, Aaron Sherman wrote:
> 2) We deny that a range whose LHS is "larger" than its RHS makes sense, but
> we also don't provide an easy way to construct such ranges lazily otherwise.
> This would be annoying only, but then we have declared that ranges are the
> right wa
This is a long reply, but I read it over a few times, and I don't see any
fat to trim. This isn't really a simple issue for which intuition is going
to be a sufficient guide, though I agree fully that it needs to be high on
or at the top of the list.
On Sun, Jul 18, 2010 at 6:26 AM, Moritz Lenz w
Ruud H.G. van Tol wrote:
> Aaron Sherman wrote:
>
>> Having established this range for each correspondingly indexed letter, the
>> range for multi-character strings is defined by a left-significant counting
>> sequence. For example:
>>
>> "Ab" .. "Be"
>>
>> defines the ranges:
>>
>> and
>>
>
Aaron Sherman wrote:
Having established this range for each correspondingly indexed letter, the
range for multi-character strings is defined by a left-significant counting
sequence. For example:
"Ab" .. "Be"
defines the ranges:
and
This results in a counting sequence (with the most signifi
On Fri, Jul 16, 2010 at 3:49 PM, Carl Mäsak wrote:
> Aaron (>):
> > [...]
> >
> > Many useful results from this suggested change:
> >
> > "C" .. "A" = (Rakudo: <>)
>
> Regardless of the other traits of your proposed semantics, I think
> permitting reversed ranges such as the one above would be a
On Fri, Jul 16, 2010 at 9:40 PM, Michael Zedeler wrote:
>
> What started it all, was the intention to extend the operator, making it
> possible to evaluate it in list context. Doing so has opened pandoras box,
> because many (most? all?) solutions are inconsistent with the rule of least
> surpris
On Fri, Jul 16, 2010 at 1:14 PM, yary wrote:
> There is one case where Rakudo's current output makes more sense then
>
your proposal, and that's when the sequence is analogous to a range of
> numbers in another base, and you don't want to start at the equivalent
> of '' or end up at the equiv
Aaron Sherman wrote:
> Oh bother, I wrote this up last night, but forgot to send it. Here y'all
> go:
>
> I've been testing ".." recently, and it seems, in Rakudo, to behave like
> Perl 5. That is, the magic auto-increment for "a" .. "z" works very
> wonkily,
> given any range that isn't within som
On 2010-07-16 18:40, Aaron Sherman wrote:
Oh bother, I wrote this up last night, but forgot to send it. Here y'all go:
I've been testing ".." recently, and it seems, in Rakudo, to behave like
Perl 5. That is, the magic auto-increment for "a" .. "z" works very wonkily,
given any range that isn't
Aaron (>):
> [...]
>
> Many useful results from this suggested change:
>
> "C" .. "A" = (Rakudo: <>)
Regardless of the other traits of your proposed semantics, I think
permitting reversed ranges such as the one above would be a mistake.
Rakudo gives the empty list for ranges whose lhs exceeds (f
On Fri, Jul 16, 2010 at 9:40 AM, Aaron Sherman wrote:
> For example:
>
> "Ab" .. "Be"
>
> defines the ranges:
>
> and
>
> This results in a counting sequence (with the most significant character on
> the left) as follows:
>
>
>
> Currently, Rakudo produces this:
>
> "Ab", "Ac", "Ad", "Ae", "Af"
84 matches
Mail list logo
