On 1/12/06, Dave Whipp <[EMAIL PROTECTED]> wrote:
>  >>(perhaps this discussion belongs on p6l)
>  > It sure does;)
> (this reply moved to p6l)
> > Dave Whipp wrote:
> >
> >>An Int is Enumerable: each value that is an Int has well defined succ
> >>and pred values. Conversely, a Real does not -- and so arguably should
> >>not support the ++ and -- operators. Amonst other differences, a
> >>Range[Real] is an infinite set, whereas a Range[Int] has a finite
> >>cardinality.
> >
> >
> > ++ and -- aren't meant to increment or decrement to the next/last value
> > in the set, they're increment or decrement by one (see perlop). I can
> > see your point about them not making sense for Real since it's not an
> > enumerable set like integers but I don't think it would be in the
> > spirit of DWIM ...
> Imagine I have a concrete type FixedPoint8_1000 that stores numbers from
> 0 to 1000 in an 8-bit value, and "does Real". Incrementing a value
> stored in this type by one isn't a meaningful operation.
> wrt the perlop reference, we manipulate strings with ++ and --; and
> we're going to have enumerated types (albeit backed by intergers). I'm
> sort-of hoping that we'll be able to use the operators on iterators,
> too. I think what I'm saying is that "succ/pred" semantics are more
> general than just "+/- 1"; and perl6 does not need to be bound by
> perl5's perlop. I can't find a formal defn of autoincrement in the perl6
> docs.
> I wouldn't see a problem with defining a "Real" role that has a fairly
> sparse set of operations. Afterall, a type that does support ++ and --
> (e.g. Int, Num) could easily "does Enumerable" if it wants to declare
> that it supports them.

I just meant that

my Real $x = 5; # Or Num or ...
say ++$x;

should print "6" by default as opposed to "Error: no 'next' for real value".

The "next/prev" semantics are, and should be more general than ±1, I
just think that ±1 should remain the default for reals & ints.

Reply via email to