- Libraries - Haskell.org

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

26 Jan '05

On 26 January 2005 15:50, Keean Schupke wrote: > You could define a type in the library using conditional compilation: > > #ifdef Unix > type SystemPath = UnixPath > #endif > > #ifdef Windows > type SystemPath = WindowsPath > #endif > > > Then you do: > > let myPath = (emptyPath :: SystemPath) in ... Portable library APIs are not supposed to vary between platforms. Cheers, Simon

1 0

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

26 Jan '05

On 26 January 2005 15:38, Keean Schupke wrote: > Not at all. You just include some nice operation in the class: > > emptyPath :: Path p => p > appendPath :: Path p => p -> String -> p > > etc... > > So it is an abstract datatype and class. The user never needs to touch > the concrete type, even though they use it... The types remain > polymophic. The types can't remain completely polymorphic - at some point you have to say what type you want. Because an ambiguous Path constraint cannot be resolved, the program will have to mention either Win32Path or PosixPath, at which point it becomes non-portable without conditinoal compilation. Cheers, Simon

1 0

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

26 Jan '05

On 26 January 2005 14:30, Malcolm Wallace wrote: > Keean Schupke <k.schupke(a)imperial.ac.uk> writes: > >>> So let's define a new algebraic datatype something like: >> >> I think you can guess what comming - why not use a class for >> extensibility: class Path p where ... The path class would >> provide all the operations for using paths... > > Yup, good idea, and I think this would also allow David Roundy's > suggestion of a FastString implementation of filepaths - it becomes > just another instance. > >> This has the advantage that people can add instances for platforms >> without having to alter the code in the library... > > Exactly. Yes. Hmm, I deliberately didn't suggest using a type class. Do you really want to expose Win32 paths and POSIX paths, and whatever else, as different types? Maybe you do for extensibility, but you really want a single Path type too - otherwise portable code will have to use conditional compilation. The Path type therefore has to be an existential wrapper: data Path = (CPath p) => Path p Maybe we do want to do this, but it causes portability issues with the Path library itself: nhc98 can't compile this code for example - you can rewrite it using an explicit record of operations, as long as none of the operations are polymorphic... Cheers, Simon

3 3

ANNOUNCE: Gtk2Hs version 0.9.7 released
by Duncan Coutts 26 Jan '05

26 Jan '05

Gtk2Hs - A Haskell GUI library based on the Gtk+ GUI Toolkit. Version 0.9.7 is now available from: http://gtk2hs.sourceforge.net/ Highlights: * automatic memory management * Unicode support * nearly full coverage of Gtk+ 2.2 and partial coverage of 2.4 * bindings for several Gnome modules: * libglade for loading GUIs from xml files at run-time This allows you to design your user interface visually with the Glade user interface builder. * GConf, Gnome's system for storing app preferences * SourceView, code editor widget with syntax highlighting * the Mozilla browser rendering engine in a widget * API reference documentation * multi-platform support with native look via themes * LGPL licence Platforms and requirements: * packages are now available for Fedora Core 2 and 3 * packages for Gentoo and FreeBSD should follow shortly * builds out-of-the box on Linux, FreeBSD, Solaris and MacOS X * support for Windows is on hiatus for this release * builds with GHC 6.2.x, 6.0.x and 5.04.x * works with Gtk+ version 2.0 through to 2.2, 2.4 and 2.6 * optional Gnome support requires Gnome 2.0 or better * optional Mozilla support requires Mozilla 1.4 or better Changes since 0.9.6: * all packages now use hierarchical module names * a binding for GtkMozEmbed that embeds the Mozilla rendering engine in a Gtk+ widget. (Thanks to Wolfram Kahl) * an autotooled build system Goals for the 1.0 release: * a medium level API much like that of wxHaskell and hs-fltk * a stable API for the 1.x series * coverage of all the new widgets in Gtk+ 2.4 and 2.6 * bindings for more Gnome modules * completion of the API reference documentation * packages for all popular platforms (including Windows) * a Windows installer Please report all problems to gtk2hs-users(a)sourceforge.net . Contributions and feedback are also most welcome. Duncan

1 0

small fixes patch
by John Meacham 26 Jan '05

26 Jan '05

attached is a patch to fix a module name and generalise a couple functions in Data.Map to be usable in an arbitrary monad (rather than being restricted to Maybe). if someone could integrate it, that would be great. John -- John Meacham - ⑆repetae.net⑆john⑈

2 1

RE: Time
by Simon Marlow 25 Jan '05

25 Jan '05

On 22 January 2005 07:14, Ashley Yakeley wrote: > There's been a lot of discussion here and other lists of replacing > System.Time, and indeed Simon M. is working on a replacement proposal: > > <http://www.haskell.org/~simonmar/time/NewTime.html> > <http://www.haskell.org/~simonmar/time/NewTime.hsc> > > Rather than talk about specific Haskell code, I'd like to discuss the > measurement of time in general, how these concepts might be expressed > in Haskell, and what people might want from a time library. Rather > than propose anything, I want to try to ask some of the right > questions. I'd like to join the others in saying thanks for a fine summary, Ashley. Nice work! On the subject of the NewTime library you mentioned, it was the culmination of a long thread (or threads) on this list a while ago. I think it's a pretty good stab at an API for manipulating and converting between: - absolute time (TAI) - UTC - times in calendar representation - timezones but it is missing - time offsets (eg. "1 day later") - a more complete/accurate timezone table - some way to update the leap second table - geographical time zones and probably some other things. my plan was that the whole "time offset" issue would be a layer on top of this library, as others have suggested. You can already do simple calculations using CalendarTime. The representation of absolute time could be revisited. What I mean by "geographical time zones" is some notion of a time zone that is independent of daylight savings time. The current TimeZone type is a fixed UTC offset (which I think is right), but there's no way to say "what's the local time in London at time T?". I probably won't be doing much to this library, but I think it's a good starting point for anyone who wants to explore further. Cheers, Simon

2 1

RE: Time
by Simon Marlow 25 Jan '05

25 Jan '05

On 25 January 2005 14:25, Simon Marlow wrote: > my plan was that the whole "time offset" issue would be a layer on top > of this library, as others have suggested. You can already do simple > calculations using CalendarTime. One other thing I just remembered: IIRC there was a proposal to handle the whole timezone offset issue with a single function normalizeCalendarTime :: CalendarTime -> CalendarTime which would essentially just roll over the out of range fields in CalendarTime. This is essentially the same as the idea Marcin proposed in his message, I believe. Of course, normalizeCalendarTime needs to know about leap seconds (some minutes don't have 60 seconds!). Cheers, Simon

1 0

--prefix and --copy-prefix in Cabal
by Krasimir Angelov 25 Jan '05

25 Jan '05

Hello, Guys There are two options for prefixes: --prefix and --copy-prefix. In my opinion they have the same meaning and I wonder whether we need to have two different options for configure and copy commands. Any thoughts? Cheers, Krasimir

3 2

RE: Time
by Bayley, Alistair 24 Jan '05

24 Jan '05

I added this to the Wiki. Hope that's OK. http://haskell.org/hawiki/TimeLibrary > -----Original Message----- > From: Ashley Yakeley [mailto:ashley@semantic.org] > Sent: 22 January 2005 07:14 > To: libraries(a)haskell.org > Subject: Time > > There's been a lot of discussion here and other lists of replacing > System.Time, and indeed Simon M. is working on a replacement proposal: > > <http://www.haskell.org/~simonmar/time/NewTime.html> > <http://www.haskell.org/~simonmar/time/NewTime.hsc> > > Rather than talk about specific Haskell code, I'd like to discuss the > measurement of time in general, how these concepts might be > expressed in > Haskell, and what people might want from a time library. Rather than > propose anything, I want to try to ask some of the right questions. > > ... ----------------------------------------- ***************************************************************** 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

RE: FW: FW: cvs commit: fptools/libraries/base package.conf.in fptools/libraries/base/Data IntMap.hs IntSet.hs Map.hs FiniteMap.hs Set.hs
by Simon Marlow 21 Jan '05

21 Jan '05

On 20 January 2005 17:39, Sven Panne wrote: > Alain Cremieux wrote: >>> As I see it: we could change all the operations in >>> Data.Set/Data.Map to be right-biased, but that's a fair bit of work >>> and might introduce new bugs. >>> >>> If someone wants to do this work, it needs to be done fairly quickly >>> (i.e. in the next couple of weeks) because we plan to release GHC >>> 6.4 with the new code, and we won't be able to make further library >>> changes until 6.6. Any volunteers? >>> >>> Cheers, >>> Simon >>> >>> >> Hi, >> If everyone agrees on what's to be done, I volunteer for doing it. >> Alain > > I'm not sure if we should really do this, I was just trying to find > out the reason for this bias change. Perhaps adding a BIG comment in > the new API is enough. Right. I think the concensus is that we don't need to systematically change the bias in Data.Map, but we do need to document the change carefully for those porting old code. For the most part, old code will continue to work without changes because we've kept the old APIs. The exception (Data.Set.union) was pointed out by Ross, but it's unlikely to affect "normal" uses of union. Cheers, Simon

1 0