- Libraries - Haskell.org

[announce] Fedora Haskell mailing list
by Jens Petersen 21 Feb '05

21 Feb '05

The Fedora Haskell project now has a mailing list which is kindly hosted on haskell.org. :) If you wish to subscribe for announcements and discussion of packaging Haskell projects for Fedora, please go to <http://haskell.org/mailman/listinfo/fedora-haskell>. More information about the project is available on <http://haskell.org/fedora> Cheers, Jens

1 0

RE: Newtypes in Time Libraries
by Simon Marlow 21 Feb '05

21 Feb '05

On 18 February 2005 23:44, Ashley Yakeley wrote: > What sort of functions should be provided to access certain newtypes? > For instance, consider this: > > newtype DiffTime = MkDiffTime Integer -- picoseconds > > It's considered good practice to hide MkDiffTime. At the same time, I > need to provide access to the underlying value, so I provide these: > > timeToSISeconds :: (Real a) => DiffTime -> a > > siSecondsToTime :: (Real a) => a -> DiffTime > > These convert with picoseconds by multiplication or division. But do I > also want to provide access to the picoseconds directly? > > timeToSIPicoseconds :: DiffTime -> Integer > timeToSIPicoseconds (MkDiffTime ps) = ps > > siPicosecondsToTime :: Integer -> DiffTime > siPicosecondsToTime = MkDiffTime > > This makes certain other calculations in other modules easier. > > I have a similar issue with TimeZones. My intention is to encode them > as a count of minutes, hide the constructor, but provided > minutesToTimeZone and timeZoneToMinutes. Is this sensible? I like to just provide instance Integral and document that the type is an integral number of picoseconds. It means you can use overloaded constants, and the usual arithmetic operations on DiffTime. Cheers, Simon

1 0

Language.Haskell.Parser and layout rules
by Mirko Rahn 18 Feb '05

18 Feb '05

The function Language.Haskell.Parser.parseModule behaves somehow strange and disagrees with ghc-6.* about the set of accepted inputs. An example: -- file T1.hs: main = do args <- getArgs if null args then return [] else do ps <- mapM process args mapM print ps -- file T2.h2 main = do args <- getArgs if null args then return [] else do ps <- mapM process args mapM print ps Note the difference is an additional whitespace in T2. I think both codes are perfectly valid, but parseModule fails on T1. Is anyone able to explain why? Thanks, Mirko Rahn ---- mirak@loop:~> ghci ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.4.20050211, for Haskell 98

5 5

Newtypes in Time Libraries
by Ashley Yakeley 18 Feb '05

18 Feb '05

What sort of functions should be provided to access certain newtypes? For instance, consider this: newtype DiffTime = MkDiffTime Integer -- picoseconds It's considered good practice to hide MkDiffTime. At the same time, I need to provide access to the underlying value, so I provide these: timeToSISeconds :: (Real a) => DiffTime -> a siSecondsToTime :: (Real a) => a -> DiffTime These convert with picoseconds by multiplication or division. But do I also want to provide access to the picoseconds directly? timeToSIPicoseconds :: DiffTime -> Integer timeToSIPicoseconds (MkDiffTime ps) = ps siPicosecondsToTime :: Integer -> DiffTime siPicosecondsToTime = MkDiffTime This makes certain other calculations in other modules easier. I have a similar issue with TimeZones. My intention is to encode them as a count of minutes, hide the constructor, but provided minutesToTimeZone and timeZoneToMinutes. Is this sensible? -- Ashley Yakeley, Seattle WA

1 0

Cabal problems with an executable containing c-sources
by Einar Karttunen 18 Feb '05

18 Feb '05

Hello The following case seems to be broken: Name: tt Version: 0.0 License: BSD3 Executable: tt Main-Is: test.hs C-Sources: a.c Extensions: ForeignFunctionInterface a.c is completely ignored by Cabal. A complete minimal example can be found at: http://www.cs.helsinki.fi/u/ekarttun/haskell/executable-with-c-sources.tar.… - Einar Karttunen

3 5

RE: Minor changes in the package description syntax
by Simon Marlow 17 Feb '05

17 Feb '05

On 17 February 2005 15:42, Isaac Jones wrote: > Krasimir Angelov <kr.angelov(a)gmail.com> writes: > >> Hello Guys, >> >> In the package description syntax are used ld-options and cc-options >> fields. In the same time the Haskell compiler options are options-ghc >> and options-hugs. Is there any objections to rename them to >> ghc-options and hugs-options? This is only better naming convention. > > I have no objections if it's not too late for GHC 6.4. Yes, fine by me. Simon

1 0

Minor changes in the package description syntax
by Krasimir Angelov 17 Feb '05

17 Feb '05

Hello Guys, In the package description syntax are used ld-options and cc-options fields. In the same time the Haskell compiler options are options-ghc and options-hugs. Is there any objections to rename them to ghc-options and hugs-options? This is only better naming convention. Cheers, Krasimir

2 1

RE: Language.Haskell.Parser and layout rules
by Simon Marlow 17 Feb '05

17 Feb '05

On 17 February 2005 14:18, Malcolm Wallace wrote: > Ross Paterson <ross(a)soi.city.ac.uk> writes: > >> The Report (section 9.3, especially notes 1 and 2) says "A nested >> context must be further indented than the enclosing context", so >> this is illegal. GHC and Hugs have innovated here, ... > > I see you are using "innovated" here in the Microsoft sense, meaning > "undocumented and incompatible departure from standards". :-) You're right it's undocumented. I'll fix that. Is nhc98 fully compliant with the H98 layout rule? There are some good tests in testsuite/tests/ghc-regress/parser, BTW. I can't build nhc98 here, I keep getting ... ghc-6.2.2: unknown package name: exts make[1]: *** [/home/simonmar/tmp/nhc98-1.16/targets/ix86-Linux/obj/hmake/QSort.o] Error 1 make[1]: Leaving directory `/home/simonmar/tmp/nhc98-1.16/src/hmake' make: *** [targets/ix86-Linux/hmake-ghc] Error 2 Cheers, Simon

1 0

RE: Language.Haskell.Parser and layout rules
by Simon Marlow 17 Feb '05

17 Feb '05

On 17 February 2005 14:03, Ross Paterson wrote: > On Thu, Feb 17, 2005 at 01:40:31PM +0100, Mirko Rahn wrote: >> The function Language.Haskell.Parser.parseModule behaves somehow >> strange and disagrees with ghc-6.* about the set of accepted inputs. >> An example: >> >> -- file T1.hs: >> main = do args <- getArgs >> if null args then return [] else do >> ps <- mapM process args >> mapM print ps > > The Report (section 9.3, especially notes 1 and 2) says "A nested > context must be further indented than the enclosing context", so this > is illegal. GHC and Hugs have innovated here, but only where the > inner context is > a do expression; they don't accept > > f xs = case xs of > y:ys -> case ys of > z:zs -> zs GHC also has a bug in this area which we discovered recently, and affects mixed layout/non-layout code. This is accepted, and it shouldn't be: f x = case x of False -> do { return x; } Cheers, Simon

1 0

Data.Maybe comments
by Paul Steckler 15 Feb '05

15 Feb '05

Hi, Two comments about the docs for Data.Maybe on www.haskell.org/: 1) The documentation for the "maybe" function ends with: "Otherwise, it applies the function to the value inside the Just and returns that." Returns which? I think this should read: "Otherwise, it applies the function to the value inside the Just and returns the result." 2) The documentation for mapMaybe ends with: "If it just Just a, then a is added on to the result list." First, I think "Just a" and "a" should be "Just b" and "b", or "Just v" and "v", etc. The reader may think these a's are the same a's in the type, which is not the case. Also, the phrase "added on to the result list" is misleading, I think. So my suggested alternative is: "If it just Just b, then b is included in the result list." Hope this helps. -- Paul

1 0