>>(perhaps this discussion belongs on p6l)
> It sure does;)
(this reply moved to p6l)
[EMAIL PROTECTED] wrote:
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.
Dave.
