On 1/12/06, Dave Whipp <[EMAIL PROTECTED]> wrote: > >>(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.
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.
