- Libraries - Haskell.org

openFile and text mode vs. binary mode
by Simon Marlow 17 Jun '03

17 Jun '03

Hi Folks, On Windows systems, one has the option of opening files in text or binary mode. Text mode does some simple translations: \n\r gets translated to \n, and ^Z indicates the end of the file. Binary mode does no translation. We can think of this one particular kind of text translation, where others might be UTF8, UTF16, and so on. Ultimately, having a flexible framework for attaching text translations to Handles should be a goal (and has been discussed before), but I'm going to ignore that for now. The point of this message is to ask for opinions on an interface for exposing text mode vs. binary mode to users of System.IO. This will most likely be an interrim measure. For a long time, GHC has had the following, in IOExts (and lately GHC.Handle): data IOModeEx = BinaryMode IOMode | TextMode IOMode deriving (Eq, Read, Show) openFileEx :: FilePath -> IOModeEx -> IO Handle hSetBinaryMode :: Handle -> Bool -> IO () and files are opened in text mode by default (by openFile). The question is: is this the interface that we want to expose from System.IO? Personally I have two criticisms: openFileEx is not a particularly descriptive name, and I don't see a reason for IOMode to be nested inside IOModeEx. So I'd suggest this instead: openBinaryFile :: FilePath -> IOMode -> IO Handle hSetBinaryMode :: Handle -> Bool -> IO () I can see this discussion ballooning in several different directions, which is fine. But I'm primarily looking for something simple that we can use as an interrim measure for GHC 6.2. Cheers, Simon

2 1

RE: library infrastructure roundup
by Simon Marlow 17 Jun '03

17 Jun '03

> There is also a sense that it might be useful for Haskell > implementations to provide a gtk-config type tool for letting a build > system know where it wants to keep stuff... Actually I think this is not the right way to go. It should be the package manager on the host system that tells the build system where it wants to keep stuff. Certainly the library needs to inform the Haskell implementation where it lives: that's what gtk-config does in essence, and what the GHC package system does in a more general way. But I don't see a need for the Haskell implementation to tell the library where it should place its files; indeed this is likely to conflict with OS package managers that like to keep control of where files are installed. Cheers, Simon

3 4

RE: Concerning Time.TimeDiff
by Simon Peyton-Jones 17 Jun '03

17 Jun '03

| Following a brief off-list exchange, Simon Marlow suggested I post some | notes here concerning Time.diffClockTimes and Time.TimeDiff. These arise | from my thought that the current behaviour of the GHC library in | (sometimes) returning a value with positive seconds and negative | picoseconds values might be viewed as perverse. I'm trying to go beyond a | "what is technically correct" viewpoint to "what is useful"... | | I understand there's some history here, of which I'm not properly aware, so | if this is merely rehashing old ground, please ignore. The H98 Time module is probably broken in many ways. Rather than try to fix it incrementally, I think it'd be most productive if the interested parties simply got together and agreed an interface for a new Time module, even if it's incompatible with the old one. Perhaps Graham is The Man! Simon

6 5

library infrastructure roundup
by Isaac Jones 17 Jun '03

17 Jun '03

Hello all, Lots of discussion wrt the library infrastructure has been happening off the list (rather by accident) and I'd like to bring it home a bit. Corrections and extensions are welcome. There is a goodly amount of work and thought already put into a variety of systems that are related to the project. In particular, the build system for fptools is being extended to be more generic, and there is a generic build system for Haskell in the works by the Yale folks. Also HMake is a very cool tool for building haskell programs. We discussed the fact that it would be nice if Hugs had a package list like GHC and NHC have, and similarly it would be nice if GHC (and NHC?) had a way for users to keep a pacakge list in their home directories. I also suggested that it would be nice to have a flag in each Haskell implementation for Haskell extentions which are implemented portably on each system. That is, in ghc, I can use "-fglasgow-exts" to turn on a variety of things which may or may not make my code non-portable. On the other hand, if I had a flag "-fportable-exts" (in Hugs it might be "+portable") I would feel better about using some extentions. There is also a sense that it might be useful for Haskell implementations to provide a gtk-config type tool for letting a build system know where it wants to keep stuff... Alastair Reid put it best: > What is being proposed is that there would be one program > distributed in a ghc > distribution which: > > - is used by ghc and ghc-pkg to find both the global and personal > package.conf files: > > global_packages <- shell "ghc-config --global-package" >>= readFile > local_packages <- shell "ghc-config --local-package" >>= readFile > let packages = merge local_packages global_packages > > - is used when installing packages to find the platform-, site- and user- > preferences for where to install libraries. > > (If ghc-pkg didn't have a way to find package.conf, it would be used for > that too.) > > [I expect that other uses will emerge. e.g., ghci might want to read default > flag settings from here, hscpp could read compiler-specific command line > flags from here, etc. Also, you'd want a way to dump all config info so that > it can be included in bug reports.] > > So some paths would be wired in when ghc is installed. This already happens - > all that would change is the details of what is wired in and how it is > accessed. > > The distutils wrapper would _not_ contain absolute installation locations. > Rather it would consult ghc-config to determine the platform-, site-, and > user- installation preferences and override these (where appropriate) with > any build/ installation time preferences that may be supplied. Having GHC > provide the configuration file means that distutils only needs to know about > ghc-config, it doesn't need anything else wired into it. I do believe that Alastair also means that there would be hugs-config and nhc-config programs. Are there any big things I'm missing? >From where I'm standing, the action-items seem to be this: - I am working on an abstraction-layer / wrapper similar to distutils for Python. This is so that people can choose among build systems which fit their needs, and yet allow the community to build tools for package and distribution layered on top of a consistent interface. - Peter Simons (in his words): "my next step will be to come up with a description of "my" project's goal, a repository layout, and a prototype build system. This document can then be discussed, revised, thrown away, and be re-written. :-)" (wrt the build system, you probably will want to talk to Alastair and Nilsson to see what has already been done in this area.) - "Compiler" implementers: hash out ideas for package systems mentioned above. Would anyone venture to follow up with a list of decisions that need to be made? - build system implementors: keep up the good work :) peace, isaac

2 1

Italian-crafted Rolex - only $65 - $140!! Free SHIPPING ! !
by tony2003＠yahoo.ca 16 Jun '03

16 Jun '03

1 0

RE: Concerning Time.TimeDiff
by Graham Klyne 16 Jun '03

16 Jun '03

At 11:21 02/06/03 +0100, Simon Peyton-Jones wrote: >The H98 Time module is probably broken in many ways. > >Rather than try to fix it incrementally, I think it'd be most productive >if the interested parties simply got together and agreed an interface >for a new Time module, even if it's incompatible with the old one. >Perhaps Graham is The Man! I don't feel especially well-qualified, but if I can contribute in some small ways... I've taken another look at the Haskell Report description [1], and beyond clarification of some points it doesn't seem obviously broken to me. Others may have some views... a pointer to earlier discussion might help. The only thing I see offhand that I'd be tempted to change is the TimeDiff structure, in which I'd suggest dropping the tdYear, tdMonth fields, and changing tdDay to ::Integer. (This still fudges the issue of leap-seconds in time-differences, but I don't think any errors thus introduced would affect any but the most specialized of applications.) [see comments below] Thus, maybe something like this (which is indicative of a direction, not my last word on this): [[ data TimeDiff = TimeDiff { tdDay :: Integer -- -(maxInt*365) to +(maxInt*365) , tdHour, tdMin, tdSec :: Int -- 0 to 23, 0 to 59, 0 to 61 , tdPicosec :: Integer -- 0 to 10^12-1 } deriving (Eq, Ord, Read, Show) ]] Taking a wider view, I'd ask: what are the common uses for the Time library? As I mentioned previously, I don't think it's realistic to try and satisfy all possible uses, but the library should provide useful functionality for most common purposes. Some use-cases that come to mind are: - "human-scale" timestamps; attaching a time to information for the purposes of providing additional provenance information to human users. This purpose probably has little use for sub-second granularity. - "computer scale" timestamps; attaching a time to information to ensure unique identification. Monotonicity may be more important than strict accuracy. - Timed event generation in real-time systems - "human scale" measurements of duration (e.g. days, and fractions thereof); e.g. contract durations. - "computer scale" measurements of duration (e.g. seconds and fractions thereof); e.g. race timing. I'd suggest that specialist applications, such as astronomical date measurements (at exactly what date and time will be the next total eclipse of the sun?) which have to take detailed account of interactions between leap-seconds and calendar dates, or social event scheduling (the local start-time of next XYZ conference of functional programming) which have to take account of many time-zone complexities are not to be solved by the Time library. I don't mean to suggest that, say, the CalendarTime data structure not be useful for exchanging information with such applications, but that the Time module not be expected to take account of arcane calculations involving leap-seconds or time-zone differences. I think that's enough of my rambling. In summary, I think a review would: (a) scope the purpose of the Time module (b) recommend small rather than extensive changes, and (c) be more specific about describing the data and function semantics #g -- [1] http://www.haskell.org/onlinereport/time.html ------------------- Graham Klyne <GK(a)NineByNine.org> PGP: 0FAA 69FF C083 000B A2E9 A131 01B9 1C7A DBCA CB5E

2 2

Soliciting comments on Edison
by Andrew J Bromage 16 Jun '03

16 Jun '03

G'day all. As some of you know, I'm hacking up Edison. I'd like some suggestions on namespace issues. Note that at the moment, "Edison" has its own top-level name in the libraries document, and I'm happy for things to stay that way for now. First, an overview. Edison is a library of data structures, based around three main concepts: - A Sequence is any container where order is maintained (e.g. stacks, queues, deques, lists etc). - A Collection is a container where order is not maintained, or rather, is maintained by constraints on the ADT (e.g. sets, bags, priority queues etc). - An Association is a container which maps some key type to some data type (e.g. search trees, hash tables etc). The main feature of Edison which distinguishes it from other data structure libraries is that you do not choose data structures by the set of operations which you can perform on them because, for example, all Sequences support the same set of operations. Instead, you pick your data structure by implementation, and live with the fact that some operations are going to be slow on some implementations (e.g. snoc on simple lists is O(n)). Clearly, this is suboptimal. From a programmer's perspective, I shouldn't have to remember the difference between a BinaryRandList and a JoinList. Hence, I have started to implement what I call "facade" types, which wrap underlying implementations to give them names which better reflect what they are used for. Rather than use an Edison.ListSeq, you use an Edison.Stack and use meaningful operations like push and pop rather than cons and tail. I also want to support concurrently accessible data structures, embedded in the IO monad, which will probably be implemented as wrapper functions on top of channels or ports. So now there are three kinds of ways to look at a data structure: - As a concrete implementation - As a facade, exposing those operations that it is optimised for - As a concurrently accessible abstraction The simplest namespace would be something like this: Edison -- Top-level modules may include: Prelude Sequence Collection Association Facade -- Need a better name Stack Queue Deque FiniteMap FiniteTrie Concurrent Stack Queue Deque FiniteMap FiniteTrie Impl Sequence BraunSeq MyersStack Collection SplayHeap BalancedSet BalancedBag Assoc PatriciaLoMap Another option is to dump everything in "Facade" into the top level, but presumably that would require everything in Concurrent to be in the top level too which seems to pollute the top-level namespace a bit too much. Thoughts? Cheers, Andrew Bromage

3 3

monad transformer library (was: Re: list monad transformer)
by Iavor Diatchki 14 Jun '03

14 Jun '03

hello, (appologies for the long post) Andrew J Bromage wrote: > G'day. > > On Mon, May 19, 2003 at 05:15:30PM -0700, Iavor Diatchki wrote: >>i >>think the main probelm with adding transformers to the library is that >>the amount of code grows quadratically in the number of transformers >>(as one has to specify how each one interacts with every other one). > > > I personally think that there is too much of that in the existing > library. Consider, for example, the declarations at the end of > Control.Monad.State: > > instance (MonadState s m) => MonadState s (ReaderT r m) where > get = lift get > put = lift . put > > instance (Monoid w, MonadState s m) => MonadState s (WriterT w m) where > get = lift get > put = lift . put > > IMO, this is a misfeature. As a maintainer, working out what > instances are correct is a hassle and, as you note, leads to quadratic > code complexity in the worst case. As a user, I know what monad > transformers I have stacked on top of each other and I know where to > find the "lift" function. actually i disagree with this quite strongly :-) ideally i want no lifts in my program. things like: lift $ lift $ lift $ raise "error" are, well, annoying. also if i have a state and an environment (Reader they call it in the library) i can decide to switch them around as they do not inetract with each other. now all the lifts need to be changed. and besides if one has 1 of each transformer the whole "lift" thing is pointless as there is no ambiguity as to what you mean (i.e. put clearly refers to the state transformer wherevr it is). when there is more than one copy of a transformer things are different. then some sort of addressing is necessary, which is what motivated adding the "indexes" to my library. they work quite well, but i still think there must be a better way to achieve the same effect... as for maintenance, for a number of methods (i.e. ones where computions do not appear as arguments) there are standard ways of lifting. for example, what i've been using lately (don't remember if it is on my website) is: get' = lift get and then all instances for get use get' unfortunatelly i can't quite capture this commonality with a single instance. perhaps (as bellow) overlapping instances (in some form) could help. > The one exception is liftIO, which is very useful because if IO is > anywhere in your stack of monad transformers, it must be at the > bottom. I think there's also an argument for liftST. actually the library can be generalized there. in my library i have a class: class (Monad m, Monad n) => HasBase m n | m -> n where inBase :: n a -> m a for each monad transformer there is an instance: instance HasBase m n => HasBase (t m) n inBase = lift . inBase for every base monad (i.e. one not made out of transformers) there is an instance: instance HasBase m m where inBase = id we can cut down the number of instances if overlapping intsnaces are used, but it is not quite clear (at least to me) how they interact with functional dependencies. using this calss you don't need liftIO and liftST, and liftId, and liftFudgets, etc... bye iavor

4 6

Italian-crafted Rolex - only $65 - $140!! Free SHIPPING ! !
by tony2003＠yahoo.ca 12 Jun '03

12 Jun '03

1 0

RE: Existing libraries and tools
by Simon Marlow 12 Jun '03

12 Jun '03

> Whilst we're thinking about library infrastructure, binary > packages, orphaned > libraries, etc. I just found what I think is the most > comprehensive list of > Haskell libraries and tools in existence. This list is > basically all the > Haskell-related FreeBSD ports for: > > http://www.freshports.org/haskell/ > > It's a very impressive list - far more comprehensive than for > any other platform. Yes, Oliver Braun deserves endless gratitude and many virtual beers for all the effort he's put into FreeBSD support for Haskell. Thanks Olli! Cheers, Simon

1 0