- Haskell-Cafe - Haskell.org

ANNOUNCE: Learning Haskell portal, version 0.1
by Arjan van IJzendoorn 13 Feb '03

13 Feb '03

Hello all, Often we see messages from people who want to learn Haskell (something we applaud), but don't know where to begin. The Haskell homepage offers a lot of information, links and papers, but there is no page aimed specifically at beginning programmers. That's why I started to collect some links and put them on one single webpage. I thought about what the target audience would be interested in: getting an implementation, buying a book, reading course material, looking up functions in references and so on. The page I have now is a first start and I will work on it more. I've probably overseen many good tutorials, maybe a book here or there, listed an incorrect pro or con of an implementation and what not. Please tell me about it. If you have useful contributions ( nice slides, exercises with(out) solutions, some handout you give to your students which everyone could benefit from ) tell me about it, too. Enough talk: http://www.cs.uu.nl/~afie/haskell/LearningHaskell.html Cheers, Arjan PS: As one of the people in the Helium team I would not recommend beginners to use Helium yet. The absence of classes which leads to simpler types and messages is just not compatible with the text books and other teaching materials. Our plan is to add enough support for classes so that you can use the books without modification. This can be expected this summer. From that moment on, I will definitely recommend Helium to beginners since the feedback from the system is really great.

2 2

RE: SPECIALIZE pragma
by Simon Peyton-Jones 13 Feb '03

13 Feb '03

If 'g' is defined in the same module, yes. Simon | -----Original Message----- | From: Sengan.Baring-Gould(a)nsc.com [mailto:Sengan.Baring-Gould@nsc.com] | Sent: 12 February 2003 23:45 | To: haskell-cafe(a)haskell.org | Subject: SPECIALIZE pragma | | Hi, | | If I have {-# SPECIALIZE f ... #-}, | and I have f x y = ... (g x) ..., | will g also be specialized? | | Thanks, | | Sengan | | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

Good Tutorial to start with?
by Daniel Jian 13 Feb '03

13 Feb '03

Dear All, I use a lot of C++, a little bit of Java, and some other programming languages. But none of them is a functional language. I would like to learn Haskell as my first introduction to FP. Do any of you know a good tutorial for me to start with? FYI, it is easier for me to learn a new language by looking at the source code first, and then the explanation of that code. I browsed through the internet for quite a while, but still I could not find any tutorial that is not tediously long in discussion. Thanks! best regards, Daniel Jian __________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com

2 2

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 10 Feb '03

10 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