Okay...final version attached. This one fixes the toCycle bugs and changes from Int to Integer so overflow is no longer an issue. The result of cycleFromThenTo fits what I would expect, but you are free to drop this or adapt it. cycleFrom and cycleFromTo and cycleFromThen are easy, since there is no difference between ascending and descending. Note that the returned list is never null. cycleFromThenTo can be either ascending or descending depending on the first two arguments, and it considers the first occurrence of the third argument in that direction of the cycle starting from the initial argument: *Cycle> cycleFromThenTo Monday Wednesday Tuesday [Monday] instead of

*Cycle> cycleFromThenTo Monday Wednesday Tuesday [Monday,Wednesday,Friday,Sunday,Tuesday]

This agrees with things like [1,3 .. 2] returning [1] and [3,1 .. 2] returning [3]. {- By Chris Kuklewicz 3 Clause BSD license, copyright 2006 -} module Cycle (Cyclic(..)) where import System.Time import Data.Word import Data.Int default () class (Eq c,Enum c, Bounded c) => Cyclic c where cyclePeriod :: c -> Integer cyclePeriod _ = fromCycle (maxBound :: c) - fromCycle (minBound :: c) + 1 succCycle :: c -> c succCycle c | c == maxBound = minBound | otherwise = succ c predCycle :: c-> c predCycle c | c == minBound = maxBound | otherwise = pred c fromCycle :: c -> Integer fromCycle = toInteger . fromEnum toCycle :: Integer -> c toCycle = toEnum . fromInteger . (+ (fromCycle (minBound::c))) . (`mod` (cyclePeriod (undefined::c))) . (subtract (fromCycle (minBound::c))) cycleFrom :: c -> [c] cycleFrom x = map toCycle [fromCycle x ..] cycleFromTo :: c -> c -> [c] cycleFromTo x y = let xi = fromCycle x yi = fromCycle y zi = if xi > yi then yi + cyclePeriod (undefined::c) else yi in map toCycle [xi .. zi] cycleFromThen :: c -> c -> [c] cycleFromThen x y = let xi = fromCycle x yi = fromCycle y in map toCycle [xi, yi ..] cycleFromThenTo :: c -> c -> c -> [c] cycleFromThenTo x y z = let c = cyclePeriod (undefined::c) xi = fromCycle x; yi = fromCycle y; zi = fromCycle z zi' = if xi <= yi then if xi <= zi then zi else zi + c else if zi <= xi then zi else zi - c in map toCycle [xi, yi .. zi'] instance Cyclic () instance Cyclic Bool instance Cyclic Ordering instance Cyclic Int instance Cyclic Char instance Cyclic Day -- Imported from System.Time instance Cyclic Month -- Imported from System.Time instance Cyclic Int8 -- Imported from GHC.Int instance Cyclic Int64 -- Imported from GHC.Int instance Cyclic Int32 -- Imported from GHC.Int instance Cyclic Int16 -- Imported from GHC.Int instance Cyclic Word8 -- Imported from GHC.Word instance Cyclic Word64 -- Imported from GHC.Word instance Cyclic Word32 -- Imported from GHC.Word instance Cyclic Word16 -- Imported from GHC.Word

On Fri, 14 Jul 2006, Johan Holmquist wrote:

from Henning Thielemann:

...

Since the days are cycling, what is more natural about your result compared to my one?

I would prefer the one without any repetitions.

...

I assume the Bounded instance exists in order to allow loops like liftM2 (,) [0..] [minBound .. (maxBound::System.Time.Month)]

Would not "liftM2 (,) [0..] [Sunday .. Saturday]" do the trick?

You mean liftM2 (,) [0..] [January .. December] ? (I chose Months in order to get a sensible example.) I assume that the Bounded class exists in order to stay independent from the particular type. With minBound and maxBound you do not rely on whether the counting starts on Sunday or Monday if you only want to do something for all days.

Sure there are subtleties, like what should [Monday .. Monday] return, either: [Monday] or [Monday, Tuesday ... Sunday] but to settle for one would be ok to me.

You mean [Monday, Tuesday ... Sunday, Monday] ? I also think that there must be a possibility to obtain an empty list. Now I get it with [Monday .. Sunday] but I assume that you prefer [Monday, Tuesday ... Sunday]

On 14/07/06, Johan Holmquist wrote:

...

You mean [Monday, Tuesday ... Sunday, Monday] ?

Actually not. No repetitions.

That seems like a very bad idea. '..' normally means 'inclusive', breaking those semantics would be a very weird thing to do, and breaks the principle of least surprise. -- -David House, dmhouse@gmail.com

David House wrote:

On 14/07/06, David Roundy wrote:

...

Anyhow, just thought I'd mention that this isn't useful only for "ordinary" cyclic objects like dates.

Correct. Which is why Chris Kuklewicz included instances for, e.g., Int :)

And the new version takes everything to Integer so there is never any internal overflow.

I think this would be a great class to have in the standard libs. It would be even better if we could derive it.

All the existing instances are just three words: instance Cyclic Foo You only need more if you have something strange, or you want to avoid projecting to Integer. -- Chris