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
"a"s.
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.
