Re: Suggested magic for a .. b
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
for $a .. $b - $c { ... }
should be able to blow up because the LHS of a Range shouldn't have to
support .succ.
Presumably you'd only throw that except if, as well, $b doesn't support .pred ?
Yes. It should be .pred. So ($a .. $b).reverse is only possible if
$b.pred is defined and $a.gt is defined (and taking an object that has
the type of $b.pred). If the coercion to Sequence is taking place first,
we'll have to live with two additional constraints ($b.lt and $a.succ),
but I guess it would be easy to overload .reverse and get rid of those.
Regards,
Michael.
Re: Suggested magic for a .. b
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 the LHS has an additional constraint (having to provide a .succ method). All we should require is that both endpoints supports comparison (that they share a common type with comparison, at least). Yes, I agree 100%. All that should be required to construct a range $foo..$bar is that the endpoints are comparable, meaning $foo cmp $bar works. Having a .pred or .succ for $foo|$bar should not be required to define a range but only to use that range as a generator. -- Darren Duncan
Re: Suggested magic for a .. b
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 the LHS has an
additional constraint (having to provide a .succ method). All we should
require is that both endpoints supports comparison (that they share a
common type with comparison, at least).
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 of reversibility is moot. Plus, there would then
be useful distinction for serialization of C.. Vs C (perhaps we
should even parallelize) When you have two very similar operators it's
often good to maximize the semantic distance between them so that people
don't get into the lazy habit of using them without thinking.
Re: Suggested magic for a .. b
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 of reversibility is moot.
No thanks; I'd prefer it if $a..$b have analogous meanings in item and
list contexts. As things stand, 10..1 means, in item context,
numbers that are greater or equal to ten and less than or equal to
one, which is equivalent to nothing; in list context, it means an
empty list. This makes sense to me; having it provide a list
containing the numbers 1 through 10 creates a conflict between the two
contexts regardless of how they're arranged.
As I see it, C $a..$b in list context is a useful shorthand for C
$a, *.succ ... $b . You only get into trouble when you start trying
to have infix:.. do more than that in list context.
If anything needs to be done with respect to infix:.., it lies in
changing the community perception of the operator. The only reason
why we're having this debate at all is that in Perl 5, the .. operator
was used to generate lists; so programmers coming from Perl 5 start
with the expectation that that's what it's for in Perl 6, too. That
expectation needs to be corrected as quickly as can be managed, not
catered to. But that's not a matter of language design; it's a matter
to be addressed by whoever's going to be writing the Perl 6 tutorials.
--
Jonathan Dataweaver Lang
Re: Suggested magic for a .. b
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 to ask. Are you serious? Really?
Cheers,
Moritz
Re: Suggested magic for a .. b
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 (0...10).pick(*) - $x { ... }
Makes me think about parallel operations.
for 0...10 - $x { ... } # 0 through 10 in order
for 0..10 - $x { ... } # Spawn 11 threads, $x=0 through 10 concurrently
for 10..0 - $x { ... } # A no-op
for 10...0 - $x { ... } # 10 down to 0 in order
though would a parallel batch of an anonymous block be more naturally written as
all(0...10) - $x { ... } # Spawn 11 threads
-y
Re: Suggested magic for a .. b
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 same thing is enough,
especially considering that hyper operators also do the same job.
Cheers,
Moritz
Re: Suggested magic for a .. b
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 could result in a coercion to Sequence. 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 Regards TSa. -- The unavoidable price of reliability is simplicity -- C.A.R. Hoare Simplicity does not precede complexity, but follows it. -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: Suggested magic for a .. b
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!
Re: Suggested magic for a .. b
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 that was causing
problems with Perl 5's use of negative indices to count backward from
the end of a list; there's a reason why Perl 6 now uses the [*-$a]
notation for that sort of thing.
Consider a code snippet where the programmer is given two values: one
is a minimum value which must be reached; the other is a maximum value
which must not be exceeded. In this example, the programmer does not
know what the values are; for all he knows, the minimum threshold
exceeds the maximum. As things stand, it's trivial to test whether or
not your sample value is viable: if $x ~~ $min .. $max, then you're
golden: it doesn't matter what $min cmp $max is. With your change,
I'd have to replace the above with something along the lines of:
if $min = $max $x ~~ $min .. $max { ... } - because if $min
$max, the algorithm will accept values that are well below the minimum
as well as values that are well above the maximum.
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.
--
Jonathan Dataweaver Lang
Re: Suggested magic for a .. b
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
Re: Suggested magic for a .. b
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 amen (or me), but I'll accept +1 as synonymous. :) -- Mark J. Reed markjr...@gmail.com
Re: Suggested magic for a .. b
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 serious: only in that it was an
attempt to broaden the box for the discussion of semantics of coercion
ranges. One of the banes of my life is to undo the sequential mindset
that so many programmers have. I like to point out that
sequentialization is an optimization to make programs run faster on
Von-Neumann architectures. Often, it's premature. Most of the time it
doesn't matter (compilers, and even HW, can extract ILP), but every now
and again it results in an unfortunate barrier in solution-space.
Why do we assume that ranges iterate in .succ order -- or even that they
iterate as integers (and are finite). Why not iterate as a top-down
breadth-first generation of a Cantor set? etc. Does the language need to
choose a default, or is it better require the programmer to state how
they want to coerce the range to the seq. Ten years from now, we'll keep
needing to refer questions to the .. Vs ... faq.
Re: Suggested magic for a .. b
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 involved, just curiosity.
Was my specific proposal entirely serious: only in that it was an
attempt to broaden the box for the discussion of semantics of coercion
ranges.
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.
Why do we assume that ranges iterate in .succ order -- or even that they
iterate as integers (and are finite). Why not iterate as a top-down
breadth-first generation of a Cantor set?
That's easy: Principle of least surprise.
Cheers.
Moritz
Re: Suggested magic for a .. b
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, that's a perl5ism: in
perl6, please use a C... or explicit coercion of the range to a sequence.
(BTW, I thought a bit more about my previous suggestion: there is
precedent in that %hash.keys is unordered -- so it's not entirely
obvious that a default range coercion should be ordered)
Re: Suggested magic for a .. b
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.
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.
Getting back to 10..0...
The complexity of implementation argument doesn't really hold for me, as:
(a..b).list = ab ?? a,*.pred ... b !! a,*.succ ... b
Is pretty darned simple and does not require that b implement anything more
than it does under the current implementation. a, on the other hand, now has
to (optionally, since throwing an exception is the alternative) implement
one more method.
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. Many (most?)
loops will involve Most array initializers will involve Why
are we not calling that ..? Just because we defined .. first, and it
grandfathered its way in the door? Because it resembles the math op? These
don't seem like good reasons.
--
Aaron Sherman
Email or GTalk: a...@ajs.com
http://www.ajs.com/~ajs
Re: Suggested magic for a .. b
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, commas and the basic, C-derived math and logic ops. +1 Though it being the day before Rakudo *'s first release makes me think, too late! -y
Re: Suggested magic for a .. b
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, commas and the basic, C-derived math and logic ops. Many (most?) loops will involve Most array initializers will involve Why are we not calling that ..? Just because we defined .. first, and it grandfathered its way in the door? Because it resembles the math op? These don't seem like good reasons. I was thinking the same. Switching them seems better from a huffmanization POV. Leon
Re: Suggested magic for a .. b
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. Many (most?) loops will involve Most array initializers will involve Why are we not calling that ..? Just because we defined .. first, and it grandfathered its way in the door? Because it resembles the math op? These don't seem like good reasons. I would rather that .. stay with intervals and ... with generators. The mnemonics make more sense that way. Having .. resemble the math op with the same meaning, intervals, is a good thing. Besides comparing ranges, an interval would also often be used for a membership test, eg $a = $x = $b would alternately be spelled $x ~~ $a..$b for example. I would imagine that the interval use would be more common than the generator use in some problem domains. -- Darren Duncan
Re: Suggested magic for a .. b
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 endpoints would be used, such as ^..^.
I would imagine that a sequence generator would also have this variability
useful.
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 - {...}
In any event, I still think that the mnemonics of ... (yadda-yadda-yadda) are
more appropriate to a generator, where it says produce this and so on. A ..
does not have that mnemonic and looks better for an interval.
-- Darren Duncan
Re: Suggested magic for a .. b
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.
In smart-match context, a..b includes aardvark. It follows that,
unless you're filtering/shaping the sequence of generated items, then
almost every element (a..b).Seq starts with an infinite number of as.
Consistent semantics would make a..b very not-useful when used as a
sequence: the user needs to say how they want to avoid the infinities.
Similarly (0..1).Seq should most likely return Real numbers -- and thus
(0..1).pick(*) can be approximated by (0..1).pick(*, :replace), which is
much easier to implement.
So either you define some arbitrary semantics (what those should be is,
I think, the original topic of this thread) or else you punt (error
message). An error message has the advantage that you can always do
something useful, later.
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. Therefore
%hash.keys.reverse is, for most purposes, equivalent to %hash.keys. That
is why I said the question of reversibility becomes moot if you define
the collapse of a range to a sequence to be unordered. It also
demonstrates precedent, so not totally unlike any other.
Even though it was only a semi-serious proposal, I seem to find myself
defending it. So maybe I was serious, afterall. That argument for DWIM
being ordered pretty much goes away once you tell people to use ...
for what they intended to mean.
Getting back to 10..0
Yes, I agree with Jon that this should be an empty range. I don't care
what order you pick the elements from an empty range :).
Re: Suggested magic for a .. b
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
Re: Suggested magic for a .. b
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 that the endpoints are integers does not imply the the range does not include non-integer reals. My argument is that iterating a range could be defined to give you a uniform distribution of values that would smart match true against that range -- and that such a definition would be just as reasonable as (and perhaps more general than) one that says that you get an incrementing ordered set of integers across that range.
Re: Suggested magic for a .. b
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
Re: Suggested magic for a .. b
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
Re: Suggested magic for a .. b
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 ...^; but the starting point is the
starting point no matter what: there is neither ^... nor ^...^.
In any event, I still think that the mnemonics of ... (yadda-yadda-yadda)
are more appropriate to a generator, where it says produce this and so on.
A .. does not have that mnemonic and looks better for an interval.
Well put. This++.
--
Jonathan Dataweaver Lang
Re: Suggested magic for a .. b
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 using the same Latin code blocks. 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. 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. This is why I dislike the notion of the range operator being used to produce lists: the question of what values you'd get by iterating from one string value to another is _very_ different from the question of what string values qualify as being between the two. The more you use infix:.. to produce lists, the more likely you are to conflate lists with ranges. -- Jonathan Dataweaver Lang
Re: Suggested magic for a .. b
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
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.
In smart-match context, a..b includes aardvark. It follows that,
unless you're filtering/shaping the sequence of generated items, then
almost every element (a..b).Seq starts with an infinite number of
as.
Consistent semantics would make a..b very not-useful when used as
a sequence: the user needs to say how they want to avoid the
infinities. Similarly (0..1).Seq should most likely return Real
numbers -- and thus (0..1).pick(*) can be approximated by
(0..1).pick(*, :replace), which is much easier to implement.
I agree that /in theory/ coercing from Range to Sequence, the new
Sequence should produce every possible value in the Range, unless you
specify an increment. You could argue that 0 and 1 in (0..1).Seq are
Ints, resulting in the expansion 0, 1, but that would leave a door open
for very nasty surprises.
In practise, producing every possible value in a Range with
over-countable items isn't useful and just opens the door for
inexperienced programmers to make perl run out of memory without ever
producing a warning, so I'd suggest that the conversion should fail
unless an increment is specified.
The general principle would be to avoid meaningless conversions, so (1
.. *).Seq (1 .. *).pick should also just fail, but with finite
endpoints, it could succeed. The question here is whether we should open
for more parallelization at the cost of simplicity. I don't know.
So either you define some arbitrary semantics (what those should be
is, I think, the original topic of this thread) or else you punt
(error message). An error message has the advantage that you can
always do something useful, later.
I second that just doing something arbitrary where no actual definition
exists is a really bad idea. To be more specific, there should be no
.succ or .pred methods on Rat, Str, Real, Complex and anything else that
is over-countable. Trying to implement .succ on something like Str is
most likely dwimmy to a very narrow set of applications, but will
confuse everyone else.
Just to illustrate my point, if we have .succ on Str, why not have it on
Range or Seq?
Let's just play with that idea for a second - what would a reasonable
implementation of .succ on Range be?
(1 .. 10).succ --?-- (1 .. 11)
(1 .. 10).succ --?-- (2 .. 11)
(1 .. 10).succ --?-- (1 .. 12)
(1 .. 10).succ --?-- (10^ .. *)
Even starting a discussion about which implementation of .succ for Range
(above), Str, Rat or Real completely misses the point: there is no
definition of this function for those domains. It is non-existent and
trying to do something dwimmy is just confusing.
As a sidenote, ++ and .succ should be treated as two different things
(just like -- and .pred). ++ really means add one everywhere and can
be kept as such, where .succ means the next, smallest possible item.
This means that we can keep ++ and -- for all numeric types.
Coercing to Sequence from Range should by default use .succ on the LHS,
whereas Seq could just use ++ semantics as often as desired. This would
make Ranges completely consistent and provide a clear distinction
between the two classes.
Getting back to 10..0
Yes, I agree with Jon that this should be an empty range. I don't care
what order you pick the elements from an empty range :).
Either empty, the same as 0 .. 10 or throw an error (I like errors :).
Regards,
Michael.
Re: Suggested magic for a .. b
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 example, don't agree, but they're all using the same Latin code blocks. 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. The key issue here is whethere there is a well defined and meaningful ordering of the characters in question. We keep discussing the nice examples, but how about apple .. ส้ม? 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. 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. This is why I dislike the notion of the range operator being used to produce lists: the question of what values you'd get by iterating from one string value to another is _very_ different from the question of what string values qualify as being between the two. The more you use infix:.. to produce lists, the more likely you are to conflate lists with ranges. I second the above. Ranges are all about comparing things. $x ~~ $a .. $b means is $x between $a and $b?. The only broadly accepted comparison of strings is lexicographical comparison. To illustrate the point: wouldn't you find it odd if 2.01 wasn't in between 1.1 and 2.1? Really? Regards, Michael.
Re: Suggested magic for a .. b
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. The key issue here is whether there is a well defined and meaningful ordering of the characters in question. We keep discussing the nice examples, but how about apple .. ส้ม? All I'm saying is: don't throw out the baby with the bathwater. Come up with an interim solution that handles the nice examples intuitively and the ugly examples poorly (or better, if you can manage that right out of the gate); then revise the model to improve the handling of the ugly examples as much as you can; but while you do so, make an effort to keep the nice examples working. 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 the notion that all string values can be sorted. You're suggesting the possibility that a cmp ส้ is, by default, undefined. There are some significant problems that arise if you do this. -- Jonathan Dataweaver Lang
Re: Suggested magic for a .. b
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? :) ( http://tinyurl.com/3xjgxnl ) Nothing inherently religious about amen (or me), but I'll accept +1 as synonymous. :) -- Mark J. Reed markjr...@gmail.com Not militant, just trying to inject a bit of humor into the zombie thread that won't die. chris
Re: Suggested magic for a .. b
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! -- Mark J. Reed markjr...@gmail.com +1. I'm agnostic ; chris
Re: Suggested magic for a .. b
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 dictionary that comes between those two words. The key issue here is whether there is a well defined and meaningful ordering of the characters in question. We keep discussing the nice examples, but how about apple .. ส้ม? All I'm saying is: don't throw out the baby with the bathwater. Come up with an interim solution that handles the nice examples intuitively and the ugly examples poorly (or better, if you can manage that right out of the gate); then revise the model to improve the handling of the ugly examples as much as you can; but while you do so, make an effort to keep the nice examples working. I am sorry if what I write is understood as an argument against ranges of strings. I think I know too little about Unicode to be able to do anything but point at some issues, I belive we'll have to deal with. The solution is not obvious to me. 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 the notion that all string values can be sorted. You're suggesting the possibility that a cmp ส้ is, by default, undefined. Yes, but I am sure its due to my lack of understanding of Unicode. Regards, Michael.
Re: Suggested magic for a .. b
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 the notion that all string values can be sorted. You're suggesting the possibility that a cmp ส้ is, by default, undefined. 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. The customization could be applied at various levels, such as using an extra argument or trait for the operator/function that cares about ordering, or by using an extra attribute or trait for the types being sorted. In fact, this whole issue is very close in concept to the situations where you need to do equality/identity tests. With strings, identity tests can change answers depending on whether you are doing it on language-dependent or language-independent graphemes, and Perl 6 encodes that abstraction level as value metadata. When you want to be consistent, the behaviour of cmp affects all of the other order-sensitive operations, including any working with intervals. Some possible examples of customization: $foo ~~ $a..$b :QuuxNationality # just affects this one test $bar = 'hello' :QuuxNationality # applies anywhere the Str value is used Also, declaring a Str subtype or something. Of course, after all this, we still want some reasonable default. I suggest that for Str that aren't nationality-specific, the default ordering semantics are by whatever generic ordering Unicode defines, which might be by codepoint. And then for Str with nationality-specific grapheme abstractions, the default sorting can be whatever is the case for that nationality. And this is how it is except where users define some other order. So then, a cmp ส้ is always defined, but users can change the definition. -- Darren Duncan
Re: Suggested magic for a .. b
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? This is where Germans and Swedes, for example, don't agree, but they're all using the same Latin code blocks. 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. The key issue here is whethere there is a well defined and meaningful ordering of the characters in question. We keep discussing the nice examples, but how about apple .. ส้ม? I thought that was already disallowed by spec.
