- Libraries - Haskell.org

registration tricks (cabal)
by Isaac Jones 13 Feb '05

13 Feb '05

Mighty Haskellers, I'm afraid we've never had a very good story about how to run "register" and "unregister" on a target machine which is different from the machine that a cabal package was built on. This comes up when building Debian or RPM packages which get copied into a temporary location, packaged up, and shipped off to an end user's machine. The closest I've come is to say that after installing into a temporary directory, you should bring the Setup script (and the .cabal file, and the .installed-pkg-info file) along and rerun it on the target machine, which probably has cabal anyway. This should work fine, but it's a little heavy handed for a one-line call to ghc-pkg. Yesterday someone suggested that instead of doing this, we could emit a little shell script / batch file (which might even contain the .installed-pkg-info file) and just run that on the target machine. So I'm thinking of adding a flag to register and unregister, maybe --dry-run or something which does _not_ register right away, but rather emits such a script. This is actually a pretty small change, but I wanted to check with you folks before adding it, since we're so close to a release. Does anyone see any problems with this? peace, isaac

1 0

Calendar Types
by Ashley Yakeley 12 Feb '05

12 Feb '05

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. Here's a "flat" definition: data CalendarTime = CalendarTime { ctYear :: Int, ctMonth :: Int, ctDay :: Int, ctHour :: Int, ctMin :: Int, ctSec :: Int, ctPicosec :: Integer } deriving ... This has a certain simplicity to it. Alternatively, there's this: data TimeOfDay = TimeOfDay { todHour :: Int, todMin :: Int, todSec :: Int, todPicosec :: Integer } deriving ... data CalendarDay = CalendarDay { cdYear :: Int, cdMonth :: Int, cdDay :: Int } deriving ... data CalendarTime = CalendarTime { ctDay :: CalendarDay, ctTime :: TimeOfDay } deriving ... This has an extra level of complexity, but also some advantages: * It's more internationalisation-friendly, as TimeOfDay can be reused in other kinds of calendar. In fact, CalendarTime could be parameterised with a typevar replacing "CalendarDay". * CalendarDay and possibly TimeOfDay are useful types by themselves, for instance dayToCalendar :: JulianDay -> CalendarDay Other questions: * Should we include a timezone field in CalendarTime? * Should the "year" field be an Integer instead of an Int? Assuming Int=Int32, it gives us 2*10^9 BCE to 2*10^9 CE. The age of the universe is about 13.7*10^9 years. The age of the earth is about 4.6*10^9 years. * TimeZone represents a fixed offset to UTC. What should it look like internally, and what functions on it should we provide? -- Ashley Yakeley, Seattle WA

2 1

RE: Time Libraries Rough Draft
by Bayley, Alistair 12 Feb '05

12 Feb '05

> From: Seth Kurtzberg [mailto:seth@cql.com] > > The problem is that it has been stated several times on this > thread that there will be no leap second table, nor a way to > use one. That's not my understanding (but then I do fid it hard to follow _everything_). Ashley's proposed API has the following: module System.Time.LeapSeconds ( ... ) where ... utcDayLength :: LeapSecondTable -> JulianDay -> DiffTime utcToTAITime :: LeapSecondTable -> UTCTime -> TAITime taiToUTCTime :: LeapSecondTable -> TAITime -> UTCTime Of course, where the LeapSecondTable comes from is another problem... 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. *****************************************************************

5 7

Text.Regex.Posix exposes too little
by Peter Simons 11 Feb '05

11 Feb '05

Hi, 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? 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. 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. ;-) Peter

1 0

RE: Cabal package descriptions
by Simon Marlow 11 Feb '05

11 Feb '05

On 10 February 2005 18:39, Isaac Jones wrote: > I'm still a bit worried; I suspect the Distribution.Make stuff is out > of date, and if we're under a freeze already then that should probably > go away. setup sdist has bitrotted too, and I don't have a hugs test > suite yet. > > The change I made to add preprocessors to UserHooks is pretty > important, IMO. > > I can definitely release cabal separately; I have maintained an > independent tree, as you know, but there are obviously problems with > this. Are we under a code freeze right now? Can we get another > weekend to hack on it? The GHC 6.4 release is way overdue. We originally planned to push it out in Aug last year, and it's now been over a year since the last major release of GHC! I suppose given that, another couple of weeks won't hurt :-) What is important, as I see it, is that the version of Cabal we ship with GHC - can support building & registering 3rd party packages for some time to come - will be compatible with future enhancements to Cabal. That is, packages which work with this version of Cabal will also work with future versions (maybe until the next *major* release of Cabal, at least). So the second point means that the syntax we use for .cabal files, and the Distribution.* API, have to be supported for some time to come. We should be clear about which parts of the Distribution.* API are actually supposed to be stable, BTW. Cheers, Simon

2 1

RE: Time Libraries Rough Draft
by Simon Marlow 11 Feb '05

11 Feb '05

On 11 February 2005 10:11, Seth Kurtzberg wrote: > The problem is that it has been stated several times on this thread > that there will be no leap second table, nor a way to use one. If > that's not correct, then there is no problem. I think you've misunderstood. The plan was never to get rid of TAI altogether; the discussion has been about whether getCurrentTime should return TAI or something UTC-based. In case you missed it, here's Ashley's latest proposal, which includes full support for TAI and leap second tables: http://www.haskell.org//pipermail/libraries/2005-February/003158.html Cheers, Simon

2 1

RE: Time Libraries Rough Draft
by Simon Marlow 11 Feb '05

11 Feb '05

On 11 February 2005 01:54, Seth Kurtzberg wrote: > We are getting bogged down in the terminology here. My problem is > that, as proposed, the library will give wrong answers. Having a > nanosecond granularity library that can't even manage one second > accuracy doesn't seem useful to me. Apparently, though, I'm in the > minority here, so I'll let it go. > > The comment about scheduling is not correct, because the leap year > correction is always available. To me, it is more important to get > the correct answer when, say, finding the amount of time that has > passed from one timestamp to another. I can't see the logic in a > library that returns incorrect answers, because to return correct > answers is more difficult. > > I guess those people who intend to use it don't care if the interval > results are correct. I do care, but I'll have to implement it myself > since I appear to be a minority of one. I don't see why you claim the library will produce incorrect answers. It will produce answers exactly as correct as the OS interfaces on which it is based. If you want to do accurate interval calculations then you have to use TAI, and if you need to convert between TAI and UTC then you also need appropriate leap second tables to hand. The library allows you to do this, and the documentation for the library will explain exactly why you have to use TAI if you need to do this. So what's the problem? Cheers, Simon

2 1

RE: Cabal package descriptions
by Simon Marlow 10 Feb '05

10 Feb '05

On 10 February 2005 16:18, Ross Paterson wrote: > On Thu, Feb 10, 2005 at 03:33:48PM -0000, Simon Marlow wrote: >> I more or less agree with all this, but it's too late to get any API >> changes into 6.4 now. We might have to start thinking about >> backwards compatibility. > > There's a dissonance between the need to ship GHC and the unfinished > state of Cabal. Most of the interface is worked out, but there are a > few parts (not the parts currently used by GHC) that are experimental > and/or need fixing, and these have had very little user feedback. I > think this will be a beta release for Cabal, and its interface will > need changing soon. What to do? Independent releases of Cabal > updates? It's certainly possible to produce an updated version of Cabal later on, released independently of GHC. However, that's a bit of a pain - if there are only a few minor interface changes to go in, I'm prepared to hold the GHC release until they're finished. Cheers, Simon

2 1

RE: bracketOnError, while, forever
by Simon Marlow 10 Feb '05

10 Feb '05

On 08 February 2005 12:33, Thomas Jäger wrote: > First of all >> -- Cale Gibbard >> comparing :: (Ord a) => (b -> a) -> b -> b -> Ordering >> comparing p x y = compare (p x) (p y) > fits nicely with the ...By functions from Data.List. sortBy (comparing fst) is just too cute not to have. Any objections? > Since there's no easy way to catch failure of read operations, >> readM :: (Monad m, Read a) => String -> m a >> readM s = case [x | (x,t) <- reads s, ("","") <- lex t] of >> [x] -> return x >> [] -> fail "Prelude.readM: no parse" >> _ -> fail "Prelude.readM: ambiguous parse" > this function seems to be quite natural. Also subsumes System.IO.readIO. Looks useful to me. > Finally, >> -- Koen Claessen >> selections :: [a] -> [(a,[a])] >> selections [] = [] >> selections (x:xs) = (x,xs) : [ (y,x:ys) | (y,ys) <- selections xs ] >> >> permutations :: [a] -> [[a]] >> permutations [] = [[]] >> permutations xs = >> [ y : zs >> | (y,ys) <- selections xs >> , zs <- permutations ys >> ] > are quite useful (maybe they should be named select and permute since > most Data.List names seem to be imperatives). Both look reasonable. Not all the names in Data.List are imperative (eg. inits, tails, lines, words). I think the names are fine. Cheers, Simon

7 10

Cabal package descriptions
by Ross Paterson 10 Feb '05

10 Feb '05

I think we need an extra field Synopsis for a short summary of the package, possibly supplemented by the longer Description. This should make Hackage catalogues more readable, and could also be shown by an extended form of hc-pkg list. (repeated) License and License-File should not be mutually exclusive. They're both useful, for different purposes. Perhaps License would be more accurately called License-Type. Perhaps Hidden-Modules should be renamed Other-Modules, now that it is used by both libraries and executables.

2 3