January 2005 - Libraries

Hierarchical module namespace extension not sufficiently flexible
by Duncan Coutts 07 Mar '05

07 Mar '05

All, So here's the problem: we have a binding to a large foreign library (GTK) which we are trying to fit nicely into hierarchical module name space. It would live under Graphics.UI.Gtk Graphics.UI.Gtk.Button Graphics.UI.Gtk.Frame ... etc Now there are over 100 modules directly under Graphics.UI.Gtk and you don't want to have to import each one of them separately. Of course you will not use all of them in one module but you might reasonably use 20+ of them. So it'd be nice to be able to say: > import Graphics.UI.Gtk or > import qualified Graphics.UI.Gtk as Gtk But now we have a problem. These import directives import a flat namespace, or a flat namespace qualified by a single module alias (ie Gtk in the second example). But the Gtk modules are deliberatly designed to have hierarchical names. You cannot simply combine them all together into a flat namespace without falling back to the trick of prefixing each function name with the module name. So while we would like to be able for users to do this: > import Graphics.UI.Gtk > > ... Button.setLabel ... They will instead have to say: > import Graphics.UI.Gtk > > ... buttonSetLabel ... Which is one of the things that the hierarchical module namespace extension was trying to get rid of! All the other language bindings for Gtk (apart from C) use the former import and useage style. It doesn't make us look good! :-) So my question is: have I overlooked something or is this really not possible at the moment. And secondly, if it is currently not possible is there a 'nice' extension that would allow this sort of thing. (Where nice probably means Haskell98 compatible / 'doesn't' break existing programs) How about: > module Graphics.UI.Gtk ( > > module qualified Graphics.UI.Gtk.Button as Button > ... > ) where > > import Graphics.UI.Gtk.Button or equivalently(?): > module Graphics.UI.Gtk ( > > module qualified Button > ... > ) where > > import Graphics.UI.Gtk.Button as Button Duncan Ps there's a oddity I found where if you say: > module Foo ( > module Bar > ) > > import qualified Bar then module Foo exports precisely nothing. But there's no error or warning.

6 8

Text.PrettyPrint.HughesPJ inserting blank lines
by Christian Maeder 02 Feb '05

02 Feb '05

I've found myself using "$+$ space $+$" in order to insert a blank line between two docs. There are probably other ways to do it. "(test "")" (and $$) instead of "space" (or $+$) also work in many cases (but not "empty"). Which way would be the best? Maybe one could add a further function "$++$" to do this and a list version "vsep" of "$++$"? Another idea might be something like a vertical space "vspace" so that several blank lines would be created by: $$ vspace $$ vspace $$ ... Cheers Christian

3 3

Time Resolution
by Ashley Yakeley 02 Feb '05

02 Feb '05

What underlying numerical type should be used to store TAI and UTC types, and at what resolution? newtype Clocktime = Clocktime ??? deriving (Eq,Ord, ...) Here are some suggestions. Not all of them are good ones: * Integer, where 1 = 1 microsecond, nanosecond, picosecond But which? Current ClockTime is ps. POSIX "struct timeval" is micro-s, "struct timespec" is ns. TAI64NA uses attoseconds (10^-18 s). <http://cr.yp.to/libtai/tai64.html> + fast(?) + power of ten matches common practice - whatever resolution might not be enough * Integer, where 1 = 1 Planck time (c. 5*10^-44 s) + amusing + unlikely to ever need more accuracy - number of Planck times in an SI second not precisely known - not a power of ten - about 2*10^31 in a picosecond, or about 100 bits * Fixed-size integer type, where 1 = 1 microsecond or etc. 2^64 mus = 580,000 years 2^64 ns = 580 years 2^128 ps = 10^19 years + fast(?) - probably need Int128 * Rational, where 1 = 1 second + 1 = 1 second easy to use + all the resolution you need + no error when dividing, guarantee (a / b) * b == a - might be slower? * Fixed-point type, where 1 = 1 second This could be Integer at some power of ten. + 1 = 1 second easy to use - we'd have to create it - whatever resolution might not be enough * Floating-point type, where 1 = 1 second + 1 = 1 second easy to use + fair amount of resolution + can use sqrt and trig functions easily + fancy NaN values, signed zeros and infinities - resolution variable, bad use of floating point * Type parameter, where 1 = 1 second + flexible - extra complication - can't use directly with Integer except for 1-second resolution -- Ashley Yakeley, Seattle WA

7 22

Data.Graph patch
by John Meacham 31 Jan '05

31 Jan '05

Here is a patch for Data.Graph which fixes an oversight in graphFromEdges. graphFromEdges returns a function which turns vertexes into nodes, but provides no way to go the other direction and figure out which vertex goes with a node. I simply return the already created function of type key -> Maybe Vertex in the tuple. I provided it as a new function graphFromEdges' and left the old functionality under the old name. if we don't care about backwards compatability, I'd recommend just replacing the one that is already there since it is a more complete interface and an easy transition for anyone currently using the library. John -- John Meacham - ⑆repetae.net⑆john⑈

1 0

RE: Time Library Organisation
by Simon Marlow 31 Jan '05

31 Jan '05

On 28 January 2005 21:54, Ketil Malde wrote: > Ashley Yakeley <ashley(a)semantic.org> writes: > >> It seems what should have been done was to create a patch to the >> kernel that allows the hardware clock to run on TAI but have >> gettimeofday return broken time as per POSIX, and have some other >> function to return TAI time. Perhaps someone's done this. > > I tried to find out, with no success. Anybody? I'm about to > reinstall my Linux laptop after a disk crash, so I could try to do > this. It also appears that support is needed in NTP, although I'm not > sure why. I don't know about the NTP support, but at least with GNU libc you can use a system clock set to TAI: > TZ=Europe/London date Mon Jan 31 09:42:47 GMT 2005 > TZ=right/Europe/London date Mon Jan 31 09:42:26 GMT 2005 when TZ is set to "right/..." glibc assumes the system clock is set to TAI seconds since the epoch. Of course, there's still no way for a user program to tell whether the system clock is supposed to be TAI or UTC. Cheers, Simon

3 2

RE: Time
by Bayley, Alistair 30 Jan '05

30 Jan '05

> From: Simon Marlow [mailto:simonmar@microsoft.com] > > I like the idea of having a single notion of absolute time, which is > independent of TAI or UTC time. You can do arithmetic on > absolute time > (add/subtract absolute units of time, find absolute time differences), > and convert to/from TAI and UTC. This is something I don't see any motivation for, from a user's point of view. AFAICT, there _is_ no notion of absolute time, just time w.r.t. a given calendar (if you view TAI and UTC as calendars). The representation of time as "units since epoch" is "just an implementation detail" :-) Seriously, though, what use is being able to find the difference between two times like this? If I want the difference between two times, I want to specify in what units the difference should be e.g. millisecs, seconds, days, years, etc. The difference between times tA and tB might be 86400 seconds, but they might still be on the same day e.g. leap seconds, so if I ask for (diffDays tA tB) I might get zero, one, or two, depending on the date. 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. *****************************************************************

7 14

RE: Time Library Organisation
by Simon Marlow 28 Jan '05

28 Jan '05

On 27 January 2005 17:06, Daan Leijen wrote: > Marcin 'Qrczak' Kowalczyk wrote: >> >> You can't have gettimeofday() returning UTC and libtai returning TAI >> at the same time, because they return the same thing. This is the >> implementation from libtai: >> >> [snip] > > >> DJB (the author of libtai) disagrees with POSIX about what >> gettimeofday should return, and assumes that it actually returns >> what he wishes it returned. > > Wow, that is terrible! Well, we can not fix libraries. If libtai is > that broken, we can just as well do it ourselves: That's pretty much the conclusion I came to when I looked at libtai for implementing my library. > if we assume that > we can convert a current UTC time to TAI, we can calculate the TAI > time at the start of the program and use time_t to keep track of the > TAI delta -- here we take advantage of the time_t bug which is not > adjusted for leap seconds! You can't assume that time_t is not being adjusted for leap seconds: the host might be running NTP, for example. The best thing to do seems to be to assume that time_t is a count of seconds since the epoch minus leap seconds, and calculate TAI from that. It might be wrong by up to a second around a leap second on a host running NTP, and slightly more wrong on a host not running NTP, but the latter probably don't care too much about second-accuracy anyway. Cheers, Simon

6 6

RE: Time Library Organisation
by Simon Marlow 28 Jan '05

28 Jan '05

On 26 January 2005 08:43, Ashley Yakeley wrote: > This is one way the time libraries might be organised. I think the > functionality splits cleanly into two separate modules. > > > "Time" module (System.Time? System.DateTime.Time?) > > * TAI/UTC arithmetic and conversions, leap-second tables > > * possibly UT1 types and conversions, Julian days and dates > > * getting the current time > > > "Date" module (System.Date? System.DateTime.Date?) importing Time > module > > * time zones > > * getting the locale time zone > > * converting times to "calendrical" format, > Gregorian and possibly also Julian > > * 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 Looks fine to me. Maybe System.Time.Clock and System.Time.Calendar? Cheers, Simon

5 7

RE: Text.PrettyPrint.HughesPJ inserting blank lines
by Simon Peyton-Jones 28 Jan '05

28 Jan '05

I use (text ""), but I grant it's a bit of a hack. Simon | -----Original Message----- | From: libraries-bounces(a)haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Iavor | Diatchki | Sent: 27 January 2005 18:13 | To: Christian Maeder | Cc: libraries(a)haskell.org | Subject: Re: Text.PrettyPrint.HughesPJ inserting blank lines | | Hi, | Nothing constructive here, I just like to second the suggestion, | as I often need a vertical space document for things like: | vcat (punctuate vspace lines) | or is there already a way to do that? | -Iavor | | | On Wed, 26 Jan 2005 19:51:27 +0100, Christian Maeder <maeder(a)tzi.de> wrote: | > I've found myself using "$+$ space $+$" in order to insert a blank line | > between two docs. | > | > There are probably other ways to do it. "(test "")" (and $$) instead of | > "space" (or $+$) also work in many cases (but not "empty"). Which way | > would be the best? | > | > Maybe one could add a further function "$++$" to do this and a list | > version "vsep" of "$++$"? | > | > Another idea might be something like a vertical space "vspace" so that | > several blank lines would be created by: $$ vspace $$ vspace $$ ... | > | > Cheers Christian | > _______________________________________________ | > Libraries mailing list | > Libraries(a)haskell.org | > http://www.haskell.org/mailman/listinfo/libraries | > | _______________________________________________ | Libraries mailing list | Libraries(a)haskell.org | http://www.haskell.org/mailman/listinfo/libraries

1 0

RE: [Haskell-cafe] File path programme
by Simon Marlow 27 Jan '05

27 Jan '05

[ moving to libraries(a)haskell.org ] On 26 January 2005 12:22, Malcolm Wallace wrote: >> Could we just punt this library for this release. After all we can >> add libraries in a later point release (eg 6.4.1) you just can't >> change existing APIs. > > FWIW, I agree with Duncan, Ben, and Peter, that the new > System.FilePath interface is broken, and the implementation more so. > It would be better to redesign FilePaths as an algebraic datatype. Ok, I'll go with the concensus. System.FilePath in its current state will be removed from the base package. Isaac or Krasimir: can you make the required changes to Cabal? (the code is already duplicated in Distribution.Compat.FilePath, just remove the import for GHC). So let's aim for 6.6 to do it right, and design an abstract type for path names. We have to think about the migration path: Haskell 98 programs must continue to work, so at least IO.FilePath must still be a String, and IO.openFile must still take a String. We can therefore: (a) make System.IO.FilePath be the new type, which is different from, and incompatible with, IO.FilePath. Similarly for System.IO.openFile, System.Directory.removeFile, and so on. (b) or just define a new type, and force you to insert read/show to convert where necessary, eg. before calling openFile. (a) is kind of the right thing, but (b) is a lot less painful in the short term. Since we'll be migrating to a new IO library at some point, (b) is probably fine (the new IO library can use the new FilePaths exclusively), but we'll need to migrate System.Directory too. Would someone like to take up the reigns on the design for the new library? Cheers, Simon

6 6