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 want.
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 Sun, Aug 1, 2010 at 11:39 PM, Martin D Kealey
mar...@kurahaupo.gen.nz 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
-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 dar...@darrenduncan.net
wrote:
$foo ~~ $a..$b :QuuxNationality # just affects this one test
I like that
$bar = 'hello' :QuuxNationality # applies
On Thu, Jul 29, 2010 at 9:51 PM, Aaron Sherman a...@ajs.com 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
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 the
On Fri, Jul 30, 2010 at 6:45 PM, Doug McNutt dougl...@macnauchtan.com 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
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 Wed, Jul 28, 2010 at 10:35 PM, Brandon S Allbery KF8NH
allb...@ece.cmu.edu 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 Thu, Jul 29, 2010 at 3:24 AM, Darren Duncan dar...@darrenduncan.net 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
On Thu, Jul 29, 2010 at 5:15 AM, Leon Timmermans faw...@gmail.com wrote:
On Thu, Jul 29, 2010 at 3:24 AM, Darren Duncan dar...@darrenduncan.net
wrote:
Some possible examples of customization:
$foo ~~ $a..$b :QuuxNationality # just affects this one test
I like that
$bar = 'hello'
On Wed, Jul 28, 2010 at 9:24 PM, Darren Duncan dar...@darrenduncan.netwrote:
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
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
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
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 whole question
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, I have
On Wed, Jul 28, 2010 at 8: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
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 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
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!
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 of meaning
On Wednesday, July 28, 2010, Jon Lang datawea...@gmail.com 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 markjr...@gmail.com
On Wed, Jul 28, 2010 at 2:30 PM, Chris Fields cjfie...@illinois.edu wrote:
On Jul 28, 2010, at 1:27 PM, Mark J. Reed wrote:
Can I get an Amen? Amen!
--
Mark J. Reed markjr...@gmail.com
+1. I'm agnostic ;
Militant? :) ( http://tinyurl.com/3xjgxnl )
Nothing inherently religious about
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
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:
No sarcasm
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,
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
On Wed, Jul 28, 2010 at 2:29 PM, Aaron Sherman a...@ajs.com 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,
On Wed, Jul 28, 2010 at 11:29 PM, Aaron Sherman a...@ajs.com 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,
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 logic ops.
Darren Duncan wrote:
Aaron Sherman wrote:
The more I look at this, the more I think .. and ... are reversed.
snip
I would rather that .. stay with intervals and ... with generators.
snip
Another thing to consider if one is looking at huffmanization is how often the
versions that exclude
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 { ... }
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
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 fact
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
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
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 ... and ...^;
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 they're all
On 2010-07-29 00:24, Dave Whipp 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
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, for
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 two words.
On Jul 28, 2010, at 1:37 PM, Mark J. Reed wrote:
On Wed, Jul 28, 2010 at 2:30 PM, Chris Fields cjfie...@illinois.edu wrote:
On Jul 28, 2010, at 1:27 PM, Mark J. Reed wrote:
Can I get an Amen? Amen!
--
Mark J. Reed markjr...@gmail.com
+1. I'm agnostic ;
Militant? :) (
On Jul 28, 2010, at 1:27 PM, Mark J. Reed wrote:
On Wednesday, July 28, 2010, Jon Lang datawea...@gmail.com 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!
--
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
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 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 a .. b include
æther?
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 n...@ccl4.org 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
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 the
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
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
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. If $RHS
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 and ending with
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 la...@wall.org wrote:
On Tue, Jul 20, 2010 at 11:53:27PM -0400, Mark J. Reed wrote:
: In particular, consider that pi
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 markjr...@gmail.com wrote:
Ok, I find that surprising (and counter to current Rakudo behavior),
but thanks for the
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
On Wed, Jul 21, 2010 at 1:28 AM, Aaron Sherman a...@ajs.com 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
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 3:55 PM, Darren Duncan dar...@darrenduncan.net 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
On Tue, Jul 20, 2010 at 7:31 PM, Aaron Sherman a...@ajs.com 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
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
Rakudo.
On Tue, Jul 20, 2010 at 10:00 PM, Jon Lang datawea...@gmail.com 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 lazy
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
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 seems
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
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-specific
On Wed, Jul 21, 2010 at 12:04 AM, Jon Lang datawea...@gmail.com 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
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
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
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
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:
A B and b c d e
This results in
On Fri, Jul 16, 2010 at 9:40 PM, Michael Zedeler mich...@zedeler.dk 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
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:
A B and b c d e
This results in a counting sequence (with the most
On Fri, Jul 16, 2010 at 9:40 AM, Aaron Sherman a...@ajs.com wrote:
For example:
Ab .. Be
defines the ranges:
A B and b c d e
This results in a counting sequence (with the most significant character on
the left) as follows:
Ab Ac Ad Ae Bb Bc Bd Be
Currently, Rakudo produces this:
Aaron ():
[...]
Many useful results from this suggested change:
C .. A = C B 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 (fsvo
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 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 some very
On Fri, Jul 16, 2010 at 1:14 PM, yary not@gmail.com 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
78 matches
Mail list logo
