Hi Perl 6 people.

I've been looking closely at the definition of the Range class in S02 and the current Rakudo implementation, and I have some comments...

It seems that there are two intended uses for this class:
Range       A pair of Ordered endpoints
Lets call the above the "interval definition".
The |..| operator now constructs a |Range| object rather than merely functioning as an operator. Both sides are in item context. Semantically, the |Range| acts like a list of its values to the extent possible, but does so lazily, unlike Perl 5's eager range operator.
And this one the "list definition".

It seems fair enough to demand that a class supports both the concept of being able to tell whether some value is between two endpoints (even supporting open ranges) as well as being a lazy list in disguise, but this concept only works on countable domains.

The most common example is 1 .. 100, which represents both an object that can tell whether some other Integer is between 1 and 100 (inclusive) as well as the list of numbers from 1 to 100.

But there are problems if you try extending it to other data types that model over-countable things, such as real numbers.

The Range 1.0001 .. 2.15 makes sense as an interval definition, but there can hardly be a useful list definition without defining a step size, at least, making it possible to use step sizes less than one.

This issue also surfaces when working with strings. As far as I can see, Rakudo has some other comparison operation, which means that Ranges using String endpoints are not dwimmy in the sense I'd expect:

say @("a" .. "ax").perl; # expands to a .. z, aa .. ax
say @("aa" .. "b").perl; # expands to the empty list

As far as I can see, the ordering is like so:

sub { $^a.chars cmp $^b.chars || $^a cmp $^b }

The code below shows that Rakudo does not currently use lexicographical comparison, which may be surprising.

say 'aaa' cmp 'aa';
say 'aaa' cmp 'ba';
say 'aaa' ~~ 'aa' .. 'ba';

The output is:

The last 0 should be 1 if using normal lexicographical ordering, just like cmp does.

It is necessary to consider the data types that we want to use as interval endpoints and carry out some sort of analysis of their domains. The basic requirements are:

For the interval definition: there must be an obvious ordering relation, so we can do $a cmp $b on any $a and $b of the given data type.

For the list definition: for any value $a of the given datatype, it must be possible to come up with some $b, where no $c exists so $a < $c < $b.

Now for a short analysis of the different data types used as end points:

Integers - both interval and list definitions are ok.

Str - using lexicographical comparison permits only the interval definition. Using the different comparison operator above permits both, but results in counter-intuitive interval definition.

Num - using numerical comparison permits only the interval definition. It should be easy to come up with a way to specify step sizes to support list definition.

Complex - neither definitions are possible.

I am unsure about how this can be solved, apart from extracting the interval definition to a super class to Range (we could call it an Interval). The backside is that the class returned by the .. operator depends on the operands:

Int .. Int -> Range
Str .. Str -> Interval
Complex .. Complex -> undef, exception or some other bad thing.
DataTypeA .. DataTypeB -> undef, exception or some other bad thing.

The most elegant solution would be if the data types themselves indicated their capabilities. So if the given class has a cmp method working on the same data type, the .. can construct an Interval. If the given class has a next method (my name for a method returning the next value), the .. can even construct a Range. If you want to construct an Interval using non-countable things, you should then be able to provide your own next replacement. Maybe like so:

my $range = 1.14 .. 1.82 :by {* + 0.01};

Another option is to provide a completely different operator for constructing Intervals.

Darren Duncan brought this up before. See http://osdir.com/ml/perl6-language/2009-02/msg00422.html


Michael Zedeler.

Reply via email to