- Libraries - Haskell.org

improvement for Data.List.sort
by Frieder Kalisch 19 Feb '03

19 Feb '03

>From libraries/base/Data/List.hs: > If I heap profile the random_list case with only 10000 then I see > random_list peaks at using about 2.5M of memory, whereas in the same > program using List.sort it uses only 100k. This is because the random number generator is evaluated too lazy. We can make mergesort more eager by replacing it with natural mergesort. i.e. mergesort :: (a -> a -> Ordering) -> [a] -> [a] mergesort cmp = mergesort' cmp . map wrap gets replaced by mergesort :: (a -> a -> Ordering) -> [a] -> [a] mergesort cmp = mergesort' cmp . map runner -- | decomposes list into monotonic runs runner :: (a -> a -> Ordering) -> [a] -> [[a]] runner _ [] = [] runner cmp l = runner' l where -- | increasing runs runner' xss@(x:xs) = case findrun (\a b->cmp a b/=GT) [x] xs of (run, []) -> [reverse run] ([_], _) -> runner'' xss (run, rest) -> reverse run : runner'' rest -- | decreasing runs. -- | We consider (x>y) instead of (x>=y) to ensure stability. runner'' xss@(x:xs) = case findrun (\a b->cmp a b==GT) [x] xs of (run, []) -> [run] ([_], _) -> runner' xss (run, rest) -> run : runner' rest -- | Do the work. findrun _ a [] = (a, []) findrun less a xss@(x:xs) | (head a) `less` x = findrun less (x:a) xs | otherwise = (a, xss) For the Demo attatched, the speedup is more than threefold for N=10^5 and the stack usage drops from 7Mb to below 1M (with flag -O1). Additionally, natural msort has the additional advantage, that it is O(N) for (almost) (anti-)sorted lists. It is also a littlebit faster on average, because runner actually does some work whereas wrap does not. Greetings, -- Frieder Kalisch f.kalisch(a)tphys.uni-heidelberg.de

1 0

Re: [ ghc-Bugs-687034 ] GetOpt overly ambiguous
by Sven Panne 18 Feb '03

18 Feb '03

[ Redirected to libraries list, because it is probably the right place to discuss System.Console.GetOpt ] Will Partain wrote: > [...] While you're thinking about it, you might want to clarify the > behavior of GetOpt in a few weird cases, e.g. > > * duplicates of no-arg options are OK; e.g.: --foo --foo > > * duplicates of with-arg options is bogus; e.g.: > --foo-file=/etc/foo --foo-file=/etc/bar > > (but what about? --foo-file=/etc/foo --foo-file=/etc/foo) > > and others you can no doubt think of easily. Hmmm, I'm not sure if there is a one-size-fits-all solution for this, e.g. think about a -v no-arg option, where one -v means "verbose", two -v mean "very verbose", three -v mean "ridiculously verbose" etc. Even for with-arg options an accumulating behaviour can make sense, e.g. for specifying multiple input files. What do other people think about this issue? Should the handling of these cases be left to the application or should we take some special measures in the library itself? Cheers, S.

2 1

FW: MonadIO needs catch?
by Simon Peyton-Jones 06 Feb '03

06 Feb '03

This question from John Meacham is really a Libraries Team question. Should the MonadIO class get an extra method? His case looks plausible to me. Simon -----Original Message----- From: John Meacham [mailto:john@repetae.net] Sent: 28 January 2003 06:35 To: haskell(a)haskell.org Subject: MonadIO needs catch? while genericizing my utility libraries to work within any MonadIO (http://haskell.cs.yale.edu/ghc/docs/latest/html/base/Control.Monad.Tran s.html) I ran into a problem, 'liftIO' is not powerful enough to catch exceptions in a MonadIO. the closest one can get is > genCatch :: MonadIO m => IO a -> (Exception -> IO a) -> m a when we want.. > genCatch :: MonadIO m => m a -> (Exception -> m a) -> m a The only way i can think of to solve this is add 'catch' (perhaps 'catchIO'? 'genCatch'?) to the MonadIO class. some open questions are whether it is possible to implement catch for any MonadIO? I would think so, since you need only store the 'internal state' of your monad at the genCatch and continue with that if an exception was raised. (this might mix badly with other extensions though?) at worst a MonadIOCatchable deriving from MonadIO could be added... John -- ------------------------------------------------------------------------ --- John Meacham - California Institute of Technology, Alum. - john(a)foo.net ------------------------------------------------------------------------ --- _______________________________________________ Haskell mailing list Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell

3 2

RE: HaskellDB
by Simon Peyton-Jones 04 Feb '03

04 Feb '03

Funnily enough, I'm currently ruminating on the possibility of adding extensible records to GHC. My current thought is: much like TRex, except with 'has' predicates instead of 'lacks' predicates. That would give polymorphic field selection and update but not polymorphic record extension So the main thing you *wouldn't* be able to do, that TRex can handle is: f :: (r\l) => {r} -> {r | l::Int} f x = {x | l = 3} Main reason: I'd like to translate records into tuples in the intermediate language, and polymorphic extension is problematic. On the other hand, you *could* do all the other things TRex supports, such as f :: (r has l::Int) => r -> Int f x = x.l f :: (r has l::Int) => r -> r f x = x { l <- 3 } (Syntax uncertain.) Question: does anyone really care about polymorphic extension. Sorry that this message is a bit brief; I'm just back from a week away. I can elaborate if anyone would be interested. Simon | -----Original Message----- | From: Dominic Steinitz [mailto:dominic.steinitz@blueyonder.co.uk] | Sent: 26 January 2003 10:19 | To: libraries(a)haskell.org | Cc: daan(a)cs.uu.nl | Subject: HaskellDB | | Having used HToolkit successfully to extract information from a MySQL | database, I am painfully aware of the limitations of sending embedded SQL | strings and finding out at runtime that something didn't quite work (in an | often subtle and difficult to track down way). | | I'd love to be able to put HaskellDB on top of HToolkit. There are two | approaches: i) add extensible records to ghc or ii) modify HaskellDB so it | uses Haskell records not extensible records (I'd have modify HaskellDB | anyway to use HToolkit rather than talk to ODBC directly). The latter sounds | as though it might be more feasible that the former. Having read the paper | and briefly looked at the code, I assume the extensibility is required if | you have two tables each with the same column name and therefore you want to | use the same label in two different records. Obviously you can't do this | with Haskell records as the labels become top level functions. However, if I | rename labels then I won't have this problem. For example, if I have two | tables, passwd and notify each containing a column called email then I could | have labels notifyEmail and passwdEmail and remember that they really | referred to email. | | Does anyone have any views on this? | | Dominic Steinitz | | _______________________________________________ | Libraries mailing list | Libraries(a)haskell.org | http://www.haskell.org/mailman/listinfo/libraries

4 4

Re: Debian library packaging? or, how to get a single deb to work for hugs/ghc/nhc?
by Isaac Jones 29 Jan '03

29 Jan '03

Shae Matijs Erisson Wrote: > In short, I'd like to see some libraries packaged for Debian. I'm > especially interested in seeing the various Gui libs arrive. My > question though, is how to package a lib in such a way that it works > for all three of the packaged Haskell compilers? There are related discussions on various lists. On Haskell-cafe, we talked about packaging Debian stuff: http://haskell.org/pipermail/haskell-cafe/2002-December/003708.html Also on Haskell-cafe, there was a small discussion on the state of libraries and the lack of a central repository for libraries: http://haskell.org/pipermail/haskell-cafe/2002-October/003516.html On Glasgow-haskell-users, there was a discussion about how to create a system for authors of 3rd party libraries independently of a particular compiler: http://haskell.org/pipermail/glasgow-haskell-users/2002-November/004322.html >From Simon Marlow's comments: >> Suppose we had an infrastructure which someone could plug their >> library source code into, and immediately get >> >> - a source tarball which will configure/build/install on a >> Unix/cygwin system with GHC installed, and provide a GHC package >> when installed. >> >> - skeleton binary packages for RPM, Windows installer, *BSD ports, >> Gentoo ebuild, etc. The binary packages will require some >> programmer intervention (such as setting the dependencies >> correctly), but much of the work can be done automatically. Though I haven't used it extensively yet, hmake seems like a good system to start with since it has nice flags like "-nhc" and "-ghc", it can be configured to use either, it has sane defaults, etc. FPTools does have a nice makefile system that 3rd party developers could adopt, though at the moment it sort of relies on those libraries being inside a ghc source directory, and I don't know how well it would work w/ nhc or Hugs. Several people have commented that the problems with Haskell libraries and compilers are similar to the problems with elisp. Maybe a solution would be to augment hmake with an idea of registering packages and {re}compiling them when new / different compilers are installed. I'm starting to like this idea a lot better than trying to make the packages depend on the particular compilers and versions. I notice that the Haskell packages sometimes get out of date, and it would be hard to get all the maintainers coordinated enough to release packages at the same time a new compiler comes out. More thoughts? peace, isaac

6 6

Debian library packaging? or, how to get a single deb to work for hugs/ghc/nhc?
by Shae Matijs Erisson 28 Jan '03

28 Jan '03

In short, I'd like to see some libraries packaged for Debian. I'm especially interested in seeing the various Gui libs arrive. My question though, is how to package a lib in such a way that it works for all three of the packaged Haskell compilers? Emacs and Python both compile source into bytecode. GHC needs access to both .hi and .o files Hugs needs access to source only, I think. Some libraries are picky about requiring -fglasgow-exts, are there any libraries which are picky about requiring the lack of -fglasgow-exts? What other factors are there? What solutions are there? Thanks, PS. after a long discussion on the #haskell irc channel about where to create a new mailing list, we decided to take Simon Marlow's advice and use an existing, but quiet mailing list. If this bothers someone, I'd be happy to move this discussion elsewhere. -- Shae Matijs Erisson - 2 days older than RFC0226 #haskell on irc.freenode.net - We Put the Funk in Funktion

1 0

HaskellDB
by Dominic Steinitz 26 Jan '03

26 Jan '03

Having used HToolkit successfully to extract information from a MySQL database, I am painfully aware of the limitations of sending embedded SQL strings and finding out at runtime that something didn't quite work (in an often subtle and difficult to track down way). I'd love to be able to put HaskellDB on top of HToolkit. There are two approaches: i) add extensible records to ghc or ii) modify HaskellDB so it uses Haskell records not extensible records (I'd have modify HaskellDB anyway to use HToolkit rather than talk to ODBC directly). The latter sounds as though it might be more feasible that the former. Having read the paper and briefly looked at the code, I assume the extensibility is required if you have two tables each with the same column name and therefore you want to use the same label in two different records. Obviously you can't do this with Haskell records as the labels become top level functions. However, if I rename labels then I won't have this problem. For example, if I have two tables, passwd and notify each containing a column called email then I could have labels notifyEmail and passwdEmail and remember that they really referred to email. Does anyone have any views on this? Dominic Steinitz

2 1

RE: Standard module header trivia
by Simon Marlow 24 Jan '03

24 Jan '03

> > I'm personally not very fond of the literate style, so > that's why none > > of the existing hierarchical libraries are literate (I actually > > converted several of them from .lhs into .hs). One reason is that > > Haddock doesn't understand literate scripts - or at least, > it expects > > all the documentation to be in comments in the Haskell source, which > > leaves little reason to use literate comments. > > As I recall, we once had a discussion here about program > documentation in > which we (well, only some of us apparently :) concluded that > literate comments > were good for documenting a module's implementation, but > something else was > needed for documenting the client interface. And that led you > eventually to develop Haddock... > > So I guess you are saying that in fact Haddock is suitable > for documenting the > implementation as well as the interface. Is that right? OK, I > didn't know > that; I will have to take a closer look at it. Not really - Haddock is intended as an interface documenting tool only. But there might be scope for extending it to support inplementation docs too, or extending Haddock to pick out annotations from literate comments somehow. I imagine there would be some overlap between the implementation and the interface docs, so that using completely separate documentation formats might be cumbersome. Cheers, Simon

1 0

RE: Standard module header trivia
by Simon Marlow 23 Jan '03

23 Jan '03

> I have a very nitpicking question about the "standard module > header" described > here: > > http://www.haskell.org/~simonmar/libraries/conventions.html > > I am not sure if the header is intended to be automatically > processed, so: > > If the source file is a literate Haskell file, is the header > supposed to be in > the Haskell code portion of the file? Or, if the literate > part is LaTeX, say, > does one put it in a LaTeX comment so that it can appear at > the head of the file? > > Are literate files even allowed for "standard library > modules"? (I don't see > any in the Hugs libraries distribution, for example.) I'm personally not very fond of the literate style, so that's why none of the existing hierarchical libraries are literate (I actually converted several of them from .lhs into .hs). One reason is that Haddock doesn't understand literate scripts - or at least, it expects all the documentation to be in comments in the Haskell source, which leaves little reason to use literate comments. To answer your question, the header is automatically processed by Haddock to generate parts of the documentation. Actually the document you point to is slightly out of date, because the header should begin with '-- |' (see the actual sources for examples). On the other hand, we're certainly not going to ban .lhs files from fptools/libraries. Feel free to cook up some "guidelines for using literate style in the libraries" and I'll add it to the document. Cheers, Simon

2 1

Standard module header trivia
by Frank Atanassow 22 Jan '03

22 Jan '03

I have a very nitpicking question about the "standard module header" described here: http://www.haskell.org/~simonmar/libraries/conventions.html I am not sure if the header is intended to be automatically processed, so: If the source file is a literate Haskell file, is the header supposed to be in the Haskell code portion of the file? Or, if the literate part is LaTeX, say, does one put it in a LaTeX comment so that it can appear at the head of the file? Are literate files even allowed for "standard library modules"? (I don't see any in the Hugs libraries distribution, for example.) Regards, -- Frank

1 0