>>(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

++ 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.


Reply via email to