Thomas Sandlaß wrote:
> The benefit of a dedicated Interval type comes from supporting set
> operations (&), (|) etc. which are still unmentioned in S03.

Have set operations been implemented in either Rakudo or Pugs?

> BTW,
> what does (1..^5).max return? I think it should be 4 because this
> is the last value in the Range. Only in 4.7 ~~ 1..^5 does the five
> matter. How does ~~ retrieve that information? For open intervals
> the .min and .max methods should return the bound outside. Or better,
> we should introduce infimum and supremum as .inf and .sup respectively.

No offense, but I've noticed a tendency on your part to suggest highly
technical names for things.  "Infimum" and "supremum" may be
technically accurate; but I wouldn't know, since I don't know for
certain what they mean.  "Min" and "max" may be misleading in terms of
the specifics; but they get the general point across.

>> I'm thinking of a Range-alike that one could use with Rat|Num or Instant
>> etc, and not just Int etc.  There would be operators to test membership of
>> a value in the interval, and set-like operators to compare or combine
>> intervals, such as is_inside, is_subset, is_overlap, union, intersection,
>> etc.  Such an interval would be what you use for inexact matching and would
>> be the result of a ± infix operator or % postfix operator.  Also, as Range
>> has a .. constructor, this other type should have something.
>
> Since the Interval type shall be an addition to the Set subsystem I
> propose the (..) Interval creation operator together with the open
> versions. Admittedly that leaves (^..^) at a lengthy six chars. But
> Jon's proposal of setting the by to zero isn't any shorter. Note that
> the open versions are more important for Interval than they are for Range
> because for Range you can always write it without ^ at the ends.

In defense of my proposal, note that it _can be_ shorter if you say
that :by defaults to zero when the endpoints are of continuous types
such as Num, Instance, or Rat.  That said, I admit that my proposal is
something of a kludge - albeit te type of kludge that Perl tends to
embrace (where reasonable, make a best guess as to the programmer's
intentions; but provide a means gor him to be more explicit if your
guess is wrong).

-- 
Jonathan "Dataweaver" Lang

Reply via email to