February 2005 - Libraries

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

RE: Calendar Types
by Bayley, Alistair 15 Feb '05

15 Feb '05

> From: Ashley Yakeley [mailto:ashley@semantic.org] > > * Should we include a timezone field in CalendarTime? Yes. If a CalendarTime doesn't carry timezone information with it, then the user must bundle it. They will want to do this because (1) they will be probably dealing with local time (2) a CalendarTime sans timezone is equivalent to UTC, and is therefore not much use (i.e. we may as well use UTC instead). > * TimeZone represents a fixed offset to UTC. What should it look like > internally, and what functions on it should we provide? There are timezones which are not integral hour offsets, so an (hours, minutes) pair, or maybe just ticks is sufficient. Or maybe a Duration (see below). Ticks is probably best from an implementation point-of-view, right? Should it include the timezone name? Although the name determines the offset, a given offset could match many names, so to preserve information we'd probably want to retain the timezone name internally. Do we want to support timezone names? Do we want to embed summer-time (daylight-savings) timezone behaviour into the library? This would obviously be useful for displaying the correct local time, but makes the timezone part of the library quite complex. > OK, so here are the basic functions of System.Time.Calendar: > > utcToCalendar :: TimeZone -> UTCTime -> CalendarTime > > calendarToUTC :: TimeZone -> CalendarTime -> UTCTime > > CalendarTime should be a "struct", i.e. a datatype with its > constructor and access functions exported. I'm assuming System.Time.Calendar is Gregorian. How about - a Duration type - some calendar arithmetic functions - arithmetic on Durations e.g. data Duration = Duration { -- this looks familiar... durYear :: Int, durMonth :: Int, durDay :: Int, durHour :: Int, durMin :: Int, durSec :: Int, durPicosec :: Integer } deriving ... calendarAdd :: CalendarTime -> Duration -> CalendarTime calendarDiff :: CalendarTime -> CalendarTime -> Duration durationAdd :: Duration -> Duration -> Duration durationDiff :: Duration -> Duration -> Duration Alistair. ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

9 16

RE: Calendar Types
by Bayley, Alistair 15 Feb '05

15 Feb '05

> From: Keean Schupke [mailto:k.schupke@imperial.ac.uk] > > This in IMHO is much better than windows > broken system of actualy moving the clock forwards and back for > daylight-savings. Do they still do that? (I do recall a big fuss over Win95 doing that, and how impressed people were that the system was so *clever*.) I just assumed that MS got it right later on - or didn't they? ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

1 0

Time Libraries Rough Draft
by Ashley Yakeley 15 Feb '05

15 Feb '05

This seems to be roughly where we're at with the time libraries. It's now three modules, Clock, LeapSeconds, and Calendar. Most people will have no need for LeapSeconds. I've added two more things which haven't been discussed much. The first is a getCPUTime function that returns the current "CPU time". This has an arbitrary base, but it doesn't hiccup. The Unix interface for this is a "clock()" function that returns time in some unit, and CLOCKS_PER_SECOND, which is a constant to convert to seconds. I'm assuming there's a Windows equivalent to this. The second thing is a type-synonym of Rational for Julian dates. Julian dates are a standard representation of UT1, where one unit is one day, and UT1 is a good choice for representing Earth-based times in the far past or future continuously. System.Time.Clock: * UTC arithmetic * types or type-synonyms for Julian days and dates (for UT1) * getting the current UTC time * getting the current "CPU time" System.Time.LeapSeconds: * TAI arithmetic * leap-second table type * conversion between UTC and TAI with table System.Time.Calendar (largely undiscussed so far): * time zones * getting the locale time zone * converting times to Gregorian "calendrical" format * calendrical arithmetic e.g. one month after March 31st * possibly "incomplete dates" e.g. "May 1" for all years * parsing and showing dates and times Left for other libraries (standard or user): * sunrise/sunset, moon phase, solstices & equinoxes, etc. * figuring out time zone from position on Earth * civil summertime zone adjustment calculation, interface to zoneinfo database * calendar systems other than Gregorian * generalised sets over time e.g. "2pm-4pm every 4th Saturday of the month" module System.Time.Clock ( ... ) where -- | standard Julian count of Earth days type JulianDay = Integer newtype DiffTime = MkDiffTime Integer timeToSISeconds :: DiffTime -> Rational siSecondsToTime :: Rational -> DiffTime data UTCTime = MkUTCTime JulianDay DiffTime newtype UTCDiffTime = MkUTCDiffTime Integer utcTimeToUTCSeconds :: UTCDiffTime -> Rational utcSecondsToUTCTime :: Rational -> UTCDiffTime addUTCTime :: UTCDiffTime -> UTCTime -> UTCTime diffUTCTime :: UTCTime -> UTCTime -> UTCDiffTime ...more arithmetic on UTCDiffTime... -- | standard Julian dates for UT1, 1 = 1 day type JulianDate = Rational getCurrentTime :: IO UTCTime getCPUTime :: IO DiffTime -- | most people won't need this module module System.Time.LeapSeconds ( ... ) where -- | TAI type AbsoluteTime = MkAbsoluteTime Integer addAbsoluteTime :: DiffTime -> AbsoluteTime -> AbsoluteTime diffAbsoluteTime :: AbsoluteTime -> AbsoluteTime -> DiffTime -- | TAI - UTC during this day type LeapSecondTable = JulianDay -> Int utcDayLength :: LeapSecondTable -> JulianDay -> DiffTime utcToTAITime :: LeapSecondTable -> UTCTime -> TAITime taiToUTCTime :: LeapSecondTable -> TAITime -> UTCTime module System.Time.Calendar ... TBD ... -- Ashley Yakeley, Seattle WA

8 17

fptools build for 'arrows' package
by Peter Simons 15 Feb '05

15 Feb '05

I've attached the necessary files so that libraries/arrows can be built (and installed) as part of GHC. It would be nice if someone with CVS commit rights could add those (and add "arrows" to libraries/Makefile). Peter

2 1

RE: Calendar Types
by Bayley, Alistair 15 Feb '05

15 Feb '05

> From: Ketil Malde [mailto:ketil+haskell@ii.uib.no] > > You also need to specify, or let the user specify, the order of > arithmetic. I.e. adding a day and then a second is different from > doing it the other way around. Duration arithmetic is not commutative? Can you give some examples please, because I'm not able to imagine any. ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

5 6

A bunch of new libraries ...
by Peter Simons 14 Feb '05

14 Feb '05

... or new versions of "old" libraries are available here: http://cryp.to/blockio http://cryp.to/child http://cryp.to/formdata http://cryp.to/funcmp http://cryp.to/hopenssl http://cryp.to/hsdns http://cryp.to/hsemail http://cryp.to/monadenv http://cryp.to/streamproc Each of those URLs hosts a darcs repository, all modules come with *.cabal files and build instructions for fptools; so if you compile GHC from the source code you can just drop them in at libraries/xxxx, edit libraries/Makefile, and then they'll be built as part of the standard libraries. For browsing the documentation and figuring out what is what, this URL is probably the best choice because it shows documentation for all of them: http://postmaster.cryp.to/docs/index.html Feedback is welcome, as always. Peter

1 0

RE: Text.Regex.Posix exposes too little
by Simon Marlow 14 Feb '05

14 Feb '05

On 11 February 2005 21:24, Peter Simons wrote: > I was wondering why Text.Regex.Posix does not expose the Ptr > interface to the regular expression library? Is there a > deeper reason for that? No deep reason that I'm aware of. > I am also worried about the fact that the module uses > finalizers to free-up unused expressions -- rather than > providing a bracket-style > > withRegex :: String -> Int -> (Regex -> IO a) -> IO a > > function. We quite often use it with a regex defined at the top-level: r = mkRegex "..." f x = case matchRegex r x of ... Although in this case there is limited benefit from having the regex garbage collected, since there can only be a bounded, probably small, number of these in the program. Providing withRegex seems like a good idea, though. > Last but not least I see that the regex flags are > represented as an 'Int'. I don't feel strongly about this, > but IMHO a > > data RegexFlag = IgnoreCase > | Newline > | ... > > data type with an appropriate declaration for Enum would be > nicer for this purpose. > > Unless there is violent opposition, I'd volunteer to make > those changes, because as it happens I need them anyway. ;-) Please go ahead, I'll review and commit your patch. Cheers, Simon

1 0