2006/7/14, David House [EMAIL PROTECTED]:
On 14/07/06, Johan Holmquist [EMAIL PROTECTED] 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
I'll answer my own post to elaborate:
If Day (and Month) where NOT instances of Bounded, the following would
be possible:
[Monday .. Sunday]
= should return [Monday, Tuesday ... Saturday, Sunday]
= but returns []
[Saturday .. Tuesday]
= should return [Saturday, Sunday, Monday, Tuesday]
= but
On Fri, 14 Jul 2006, Johan Holmquist wrote:
I'll answer my own post to elaborate:
If Day (and Month) where NOT instances of Bounded, the following would
be possible:
[Monday .. Sunday]
= should return [Monday, Tuesday ... Saturday, Sunday]
= but returns []
Why not
[Monday, Tuesday
Johan Holmquist [EMAIL PROTECTED] wrote:
If Day (and Month) where NOT instances of Bounded, the following would
be possible:
[Saturday .. Tuesday]
= should return [Saturday, Sunday, Monday, Tuesday]
= but returns []
This does seem like a reasonable argument to me. Some enumerations are
Try this:
module Cycle (Cyclic(..)) where
import System.Time
import Data.Word
import Data.Int
class (Eq c,Enum c, Bounded c) = Cyclic c where
cyclePeriod :: c - Int
cyclePeriod _ = fromEnum (maxBound :: c) - fromEnum (minBound :: c) + 1
succCycle :: c - c
succCycle c | c ==
Hmmm... I think I should have said:
toCycle :: Int - c
toCycle = toEnum
. (+ (fromEnum (minBound::c)))
. (`mod` (cyclePeriod (undefined::c)))
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
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
Yes, it would be possible to make ones own class and instantiate from
that. I was just thinking Day and Month should be cyclic per default.
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
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 (,)
Interestingly, your Cyclic class idea may have practical purposes
beyond enumeration. Integers modulo some number are also cyclical,
and can come in very handy. In fact, raw unsigned ints are modulo
2^32 (or something like that), so they really ought (under one
interpretation) to be members of
On 14/07/06, David Roundy [EMAIL PROTECTED] 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 :)
I think this would be a great class to have in the standard libs.
On 14/07/06, Johan Holmquist [EMAIL PROTECTED] 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
David House wrote:
On 14/07/06, David Roundy [EMAIL PROTECTED] 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
On Fri, Jul 14, 2006 at 02:28:20PM +0100, David House wrote:
On 14/07/06, David Roundy [EMAIL PROTECTED] 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 :)
Ah,
14 matches
Mail list logo
