> Let's ignore System.Time since it's obsoleted by Data.Time.
While you're updating the Data.Time docs, could you mention the above
in System.Time? I recently looked at both and used System.Time
because Data.Time looked too complicated.
___
Haskell-Cafe
On Nov 29, 2007, at 12:12 , Arthur van Leeuwen wrote:
Going through Rational is the right solution, though. My hackish
detour was to use fromIntegral . toInteger . fromEnum
?? fromEnum produces an Int, which is an Integral such as
fromIntegral requires; why is toInteger needed?
Yes, that
On 29-nov-2007, at 14:44, Simon Marlow wrote:
Brandon S. Allbery KF8NH wrote:
On Nov 19, 2007, at 16:06 , Arthur van Leeuwen wrote:
here is a puzzle for you: try converting a
System.Posix.Types.EpochTime into either a
System.Time.CalendarTime or a Data.Time.Clock.UTCTime without
going thro
Brandon S. Allbery KF8NH wrote:
On Nov 19, 2007, at 16:06 , Arthur van Leeuwen wrote:
here is a puzzle for you: try converting a
System.Posix.Types.EpochTime into either a
System.Time.CalendarTime or a Data.Time.Clock.UTCTime without going
through
read . show or a similar detour through stri
Aaron Denney wrote:
On 2007-11-19, Andrew Coppin <[EMAIL PROTECTED]> wrote:
As I understand it, it's widely recognised that Haskell's current
numeric class hierachy is broken (or at best, not very well chosen), but
nobody came up with a better suggestion yet.
Oh, there are /lots/ of s
On 2007-11-19, Andrew Coppin <[EMAIL PROTECTED]> wrote:
> Arthur van Leeuwen wrote:
>> A closely related issue: fromIntegral is in Integral which also
>> requires quotRem. However,
>> the two are semantically quite disjoint. I can *easily* see the
>> semantics of fromIntegral
>> on EpochT
