- Haskell-Cafe - Haskell.org

SPECIALIZE pragma
by Sengan.Baring-Gould＠nsc.com 12 Feb '03

12 Feb '03

Hi, If I have {-# SPECIALIZE f ... #-}, and I have f x y = ... (g x) ..., will g also be specialized? Thanks, Sengan

1 0

Beginner help
by JJ 12 Feb '03

12 Feb '03

(My apologies if this is off topic) Functional programming is completely new to me. I've been doing imperative programming for quite a while. >From my perspective, the learning curve for Haskell seems to be near vertical. I've read several things on the web, and am working my way through The Haskell School of Expression. Any words of wisdom? ADVthanksANCE, JJ Be Kind, Be Careful, Be Yourself

5 5

Very simple question
by Jorge Adriano 11 Feb '03

11 Feb '03

On style, yes. A concrete example of what I asked before. The following doesn't type check for obvious reasons. In your opinion what is the most elegant way to fix it? Like I said, I'm starting to feel like defining my own operators is the way to go. On the other hand, this kind of situation seems quite common and there are no such operators in the standard libraries, so I might be wrong here. Opinions anyone? J.A. ------------------ Source Code: ------------------ module TypeCheck where import Data.Array import Data.Ix bigR :: Double bigR = sum[a!(i,j)*(r!i - n*b!i)*(r!j-n*b!j) | (i,j)<-range(bounds a)]/n a :: Array (Int,Int) Double b :: Array Int Double r :: Array Int Int n :: Int a=undefined b=undefined r=undefined n=undefined

1 0

cant find module PrelPtr
by Chris Moline 10 Feb '03

10 Feb '03

hi i am learning to use green card. when i try to compile the preprocessed haskell file i get the error message ghc-5.04.2: chasing modules from: main.hs ghc-5.04.2: can't find module `PrelPtr' (while processing "/usr/local/lib/green-card/StdDIS.hs") i am using green-card 2.05 and ghc 5.04.2 on freebsd 4.7. what can i do to fix this? chris

1 0

RE: time since the epoch
by Simon Marlow 10 Feb '03

10 Feb '03

> SM> TimeDiff has a perfectly well-defined meaning for Eq > and Ord: one > SM> TimeDiff is equal to another iff all the fields are > respectively equal. > > Yes, sure, Eq and Ord are defined by > deriving (Eq, Ord, ...) > but this does not make much sense if the representation for a > particular duration is not unique. All I'm asking for is a unique > representation for a duration and I do not see how you can do this > using not uniquely defined terms like "month" and "year". TimeDiff isn't a "duration", it's a way of specifying time offsets whose duration depends on the base to which the offset is being added. If we only had constant-duration offsets, then there would be no way to say "give me a ClockTime for this time next Wednesday". The problem is really that all the different kinds of offset are lumped into one type: there ought to be a TimeDiffSeconds, TimeDiffMonths, and so on. TimeDiffSeconds is a constant-duration offset, but TimeDiffMonths isn't. The problem with lumping them into one type is that if multiple components are non-zero, you don't know in which order to add them. The TimeExts library gives you separate differences like these, BTW. [snip] > SM> This isn't a problem with the spec, I think. A > TimeDiff of "1 month" is > SM> precisely a difference, which, when added to a given > ClockTime, produces > SM> a ClockTime which is one month later (with respect to > some timezone, > SM> presumably UTC since it isn't specified otherwise). > That is, January > SM> 12th 12:00 UTC becomes February 12th 12:00 UTC, and > so on. Adding one > SM> month to certain ClockTimes is meaningless: eg. > adding one month to > SM> January 31st doesn't work. > > Unfortunately, with UTC, this goes on to make adding *anything* except > seconds to certain ClockTimes (namely the instants of leap seconds, > eg, what happens if you add 1 minute to 23:59:60 ? This is a perfectly > legal UTC time on a day with a leap second) meaningless. That's right, and here I'm not sure whether the right behaviour is to raise an exception or to "roll over" to the next nearest date/time. I believe TimeExts does some kind of rolling over, but I'm not sure of the exact semantics (George?). > My take would > be to look at an established standard for expressing time durations > (eg, ISO8601) and just adhere to that (but not the POSIX standard, > please!). Personally, I think that it is unacceptable to make > something like addToClockTime a partial function. Ok, ISO8601 seems to specify only constant-duration time intervals, but allows them to be given in terms of years, months, days etc., where a month is specified to be 30 days, it seems, and similar approximations are made for the other units. This seems very odd to me, but if that's what you want... (it's possible I'm misreading the standard, or maybe I got hold of an old version though). > SM> At least, that's how I believe it is supposed to work. GHC's > SM> implementation *is* completely wrong (which is > perhaps where some of the > SM> confusion comes from), but the TimeExts library can > be used instead of > SM> TimeDiffs. > > Well, so you agree that the behavior of the Time module is > unspecified! Of course, I'm not blaming GHC's implementation which > cannot be right under these circumstances. Yes, it's unspecified, but I also think many people misinterpret it to be more broken than it actually is. > SM> This is a perfectly reasonable definition of absolute > time, we don't > SM> need to talk about TAI at all, except to define what > the epoch means. > > Agreed! So what is epoch? Is it > "Seconds since 00:00:00 on 1 Jan 1970 [TAI]"? I guess so... GHC's implementation will be whatever the C library uses, which I assume is the one you specified above (at least on a decent implementation). Cheers, Simon

2 1

Error in Haskell 98 Report 'lex' function
by Simon Peyton-Jones 10 Feb '03

10 Feb '03

Ah yes, this is a genuine bug. Haskell 98 changed at some point to allow identifiers and field labels with a leading '_', but the library didn't keep pace. I'll fix GHC. HOWEVER, the sad thing is that the same bug is in the Haskell 98 Report itself, now begin printed. The definition of lex is wrong. Ah well, I knew this would happen. I'd better start keeping a new bug list! Simon -----Original Message----- From: Jong Keun Na [mailto:jongkn@microsoft.com] Sent: 10 February 2003 02:48 To: Simon Peyton-Jones; haskell-cafe(a)haskell.org Subject: RE: Auto generated instance codes through 'deriving' The following code snippet not works correctly. >data Obj = Obj {_id, p1, p2::Int} deriving (Show, Read) >showObj :: Obj -> String >showObj o = show o >main = do print (showObj (read "Obj {_id=1,p1=10,p2=20}")) > return () The reason is because I used the property name with underscore char like "_id". Looking into auto generated class codes and seeing they show it should encompass identifiers with special characters with parenthesis, so I tried "Obj {(_id)=1,p1=10,p2=20}" as argument of read func. But, the result is same, parse error. Is this problem by-design or bug? Or Am I missing any point? Thanks, /JongKeun -----Original Message----- From: Simon Peyton-Jones Sent: Friday, February 07, 2003 5:41 PM To: Jong Keun Na; haskell-cafe(a)haskell.org Subject: RE: Auto generated instance codes through 'deriving' Try -ddump-deriv http://haskell.cs.yale.edu/ghc/docs/latest/html/users_guide/options-debu gging.html#DUMPING-OUTPUT Simon -----Original Message----- From: Jong Keun Na [mailto:jongkn@microsoft.com] Sent: 07 February 2003 06:15 To: haskell-cafe(a)haskell.org Subject: Auto generated instance codes through 'deriving' Hello folks, Is there any method with which I can see instance's codes generated automatically by using 'deriving' keyword in GHC? I'm curious in how GHC generates 'Read' class's instance code for user-defined data type. Any help will be great appreciated. /JongKeun

3 2

RE: Auto generated instance codes through 'deriving'
by Jong Keun Na 09 Feb '03

09 Feb '03

The following code snippet not works correctly. >data Obj = Obj {_id, p1, p2::Int} deriving (Show, Read) >showObj :: Obj -> String >showObj o = show o >main = do print (showObj (read "Obj {_id=1,p1=10,p2=20}")) > return () The reason is because I used the property name with underscore char like "_id". Looking into auto generated class codes and seeing they show it should encompass identifiers with special characters with parenthesis, so I tried "Obj {(_id)=1,p1=10,p2=20}" as argument of read func. But, the result is same, parse error. Is this problem by-design or bug? Or Am I missing any point? Thanks, /JongKeun -----Original Message----- From: Simon Peyton-Jones Sent: Friday, February 07, 2003 5:41 PM To: Jong Keun Na; haskell-cafe(a)haskell.org Subject: RE: Auto generated instance codes through 'deriving' Try -ddump-deriv http://haskell.cs.yale.edu/ghc/docs/latest/html/users_guide/options-debu gging.html#DUMPING-OUTPUT Simon -----Original Message----- From: Jong Keun Na [mailto:jongkn@microsoft.com] Sent: 07 February 2003 06:15 To: haskell-cafe(a)haskell.org Subject: Auto generated instance codes through 'deriving' Hello folks, Is there any method with which I can see instance's codes generated automatically by using 'deriving' keyword in GHC? I'm curious in how GHC generates 'Read' class's instance code for user-defined data type. Any help will be great appreciated. /JongKeun

1 0

Ints as ints and floats - Question on style
by Jorge Adriano 08 Feb '03

08 Feb '03

Hello, Lately I've been coding functions where I have to use Int elements, both as Ints (e.g. as an array or list index) and Doubles/Floats (e.g. when performing arithmetic operations with Doubles/Floats). How do you usually deal with this? Some options I can think of are, 1. using "fromIntegral" when needed (some formulas become unredable). 2. duplicating all those ints to float elements. (not very readable either, you end up with two distinct elements that mean the same thing). 3. creating new operators perform arithmetic operations with Ints/Integers and Float/Doubles. Cheers, J.A.

1 0

libDB
by Sengan.Baring-Gould＠nsc.com 07 Feb '03

07 Feb '03

Has anyone written a binding to the BSD libdb ? Sengan ----------------------- There's a limit to all things, and everything that passes its limit destroys itself.

1 0

RE: time since the epoch
by Simon Marlow 07 Feb '03

07 Feb '03

> Ha! After playing with this, I discovered that only the seconds were > set and all other fields remained untouched. At least in ghc's > implementation. Interestingly, TimeDiff derives Eq and Ord, but I'd > better not ask for their implementation... TimeDiff has a perfectly well-defined meaning for Eq and Ord: one TimeDiff is equal to another iff all the fields are respectively equal. See http://www.haskell.org/pipermail/haskell-cafe/2002-December/003758.html > There is also a more fundamental problem with the TimeDiff data > type. While seconds, minutes, hours, and days are clearly specified > amounts of time, the duration of a month or a year may vary depending > on the reference point where the time difference is applied. This isn't a problem with the spec, I think. A TimeDiff of "1 month" is precisely a difference, which, when added to a given ClockTime, produces a ClockTime which is one month later (with respect to some timezone, presumably UTC since it isn't specified otherwise). That is, January 12th 12:00 UTC becomes February 12th 12:00 UTC, and so on. Adding one month to certain ClockTimes is meaningless: eg. adding one month to January 31st doesn't work. At least, that's how I believe it is supposed to work. GHC's implementation *is* completely wrong (which is perhaps where some of the confusion comes from), but the TimeExts library can be used instead of TimeDiffs. > My conclusion is that time differences really should be measured in > seconds and picoseconds. > > type TimeDiff = (Integer, Integer) We already have this kind of TimeDiff: just don't use anything except the seconds and picoseconds fields. I agree with John Meacham in that it ought to be possible to get a raw time in terms of seconds/picoseconds since the epoch, and indeed GHC lets you do that: importing System.Time lets you get at the representation of ClockTime: data ClockTime = TOD Integer -- Seconds since 00:00:00 on 1 Jan 1970 Integer -- Picoseconds with the specified second This is a perfectly reasonable definition of absolute time, we don't need to talk about TAI at all, except to define what the epoch means. Cheers, Simon

2 1