- Libraries - Haskell.org

cabal installation
by Frederik Eaton 30 Oct '05

30 Oct '05

It would be nice if cabal would unlink destination files before installing over them, rather than just calling "copyFile". It appears that when "copyFile" finds that a destination file already exists, rather than removing it, it tries to open and truncate it, which leads cabal to fail with the following error message when a new version of a running program is installed: *** Exception: bar: copyFile: resource busy (Text file busy) The commonly-used 'install' command does not suffer from this bug. Frederik

2 1

Data.Monoid
by Ross Paterson 27 Oct '05

27 Oct '05

(regurgitating http://www.haskell.org/pipermail/libraries/2005-July/004057.html) I propose to replace the instance instance Monoid (a -> a) where mempty = id mappend = (.) with newtype Endo a = Endo { runEndo :: a -> a } instance Monoid (Endo a) where mempty = Endo id Endo f `mappend` Endo g = Endo (f . g) instance Monoid b => Monoid (a -> b) where mempty _ = mempty mappend f g x = f x `mappend` g x

7 14

RE: [Haskell] Read Instances for Data.Map and Data.Set
by Simon Marlow 26 Oct '05

26 Oct '05

On 21 October 2005 08:43, Johannes Waldmann wrote: > Georg made the point that if a type is an instance of Show, > then it should also be an instance of Read, and read . show == id I rather think that this should be an explicit design requirement for Read/Show instances in the libraries, along with the requirement that the Show instance outputs valid Haskell syntax that can be included in a program (assuming appropriate imports, and possibly an appropriate type signature). Show is not for pretty-printing, it is for serialising. Are there any Show instances that violate these requirements in the base/haskell98 packages currently? Cheers, Simon

7 7

RE: [Haskell] Read Instances for Data.Map and Data.Set
by Simon Peyton-Jones 26 Oct '05

26 Oct '05

| > > There is no easy way currently for me to create a | > > short synonym for the defining module name. e.g. | > > | > > import Some.Very.Long.Module.Name as Local | > | > I'd prefer such self-imports if they wouldn't need so much effort. | | me too. I have requested it on the list before. they should be | straightforward to add, the recursive module namespace rules are not | very complicated at all and just allowing self-import doesn't involve | anything but tweaking the renamer a bit and a fast fixpoint iteration. If only it were so easy: module Foo where import Foo as Bar $(some splice stuff) We don't know what Foo exports until we've run all the splices. Sigh. Simon

1 0

RE: Data.* collections maintenance
by Simon Marlow 25 Oct '05

25 Oct '05

On 22 October 2005 11:58, Adrian Hey wrote: > One problem with AVL is the complexity of most of the code means > producing specialised unboxed implementations manually is not an > attractive proposition. Hopefully compilers will do this sort of > thing for us one day. > > But in reality I expect this sort of thing to be more of an issue > for benchmark style code using Ints. For more complex keys and > comparisons the indirection cost will be relatively insignificant > I think. For polymorpic implementations counting the actual number > of comparisons required by some function is just as important IMO. It's not just benchmark code - in GHC we use Int-based maps all over the place for speed. Given your promising results for polymorphic AVL trees, it's a fair bet that you could beat Data.IntMap with a specialised Int version. If you did, we would be forced to use Data.Tree.AVL in GHC :) Cheers, Simon

4 4

Data.* collections maintenance
by Jean-Philippe Bernardy 25 Oct '05

25 Oct '05

Hello, As some demand seem to exist for the job, I volunteer to take over/resume maintenance of Data.Map and friends. In the hope that will alleviate the heavy load on the compiler maintainers :) Pending issues include : - Better integration of Map and Set (proposed by John Meacham) - More performance tests and QuickCheck properties (Christian Maeder) - Monoid instances (is this still current ?) Surely I have missed something, please state your unaddressed bug reports and wish list items. Cheers, JP.

14 18

RE: Controlled anarchy, was Re: Data.* collections maintenance
by Simon Marlow 24 Oct '05

24 Oct '05

On 21 October 2005 21:12, Jacques Carette wrote: > I would strongly recommend against 'allow everyone to just commit' > without the presence of a large automated test suite which is used to > (automatically) reject code that breaks a test. pre-commit testing using GHC isn't really practical; it would be a huge bottleneck. The asynchronous testing we have right now (full testsuite every night) is a better compromise. However, online testing of libraries using Hugs might be do-able. It would make a nice little project if anyone's interested. I would happily run a bunch of Hugs tests before committing a library change if it was done either with a single command or automatically by the checkin. Cheers, Simon

2 1

RE: [Haskell] Read Instances for Data.Map and Data.Set
by Simon Marlow 24 Oct '05

24 Oct '05

On 22 October 2005 06:21, Donald Bruce Stewart wrote: > The ones I can think of off the top of my head. Of course, these are > weird for various reasons though: > > > show $ toDyn (1::Int) -- Dynamic has no Read > "<<Int>>" > > > show $ typeOf (1::Int) -- TypeRep as no Read > "Int" That reminds me, the Show instance for Exception is similarly bogus. Cheers, Simon

2 1

Reason of OpenAL uses ccall, even on WinDoze ....
by shelarcy 24 Oct '05

24 Oct '05

Hello. I am chceking OpenAL CVS Log. Because I'm waiting that my patch is applied. And I saw this message: http://www.haskell.org//pipermail/cvs-libraries/2005-October/004551.html > Log: > For some obscure/unknown reason, OpenAL uses ccall, even on WinDoze... So I send again below message, and I notice where is the problem on windows. OpenAL uses ccall on Windows, because OpenAL's aclocal.m4 and configure.ac don't use AC_CANONICAL_*, so $host_os variable has no parameter, then 'ifeq "$(TARGETPLATFORM)" "i386-unknown-mingw32"' doen't work. I noticed this problem 2. of below message. On Mon, 26 Sep 2005 22:41:11 +0900, shelarcy <shelarcy(a)gmail.com> wrote: > I tried to build CVS HEAD, build is success on Windows. > But build is failure on Mac OS X, because you missunderstood my patch's > Mac OS X support part. > > > OpenAL/autoconf.ac must change two point. > > 1. AC_SEARCH_LIBS doesn't find framework's Library, Mac OS X can use > "-framework OpenAL" flag instead of "-l openal" option, and > FP_HEADER_AL > FP_HEADER_ALC can find headers. So you must change to declare > AC_SUBST([AL_FRAMEWORKS]) before checking to find library instead > of before checking to find header. > 2. OpenAL doesn't inherit platform parameter and dosen't declare > AC_CANONICAL_*, > so $host_os variable has no parameter and "case $host_os in" doesn't > work. > (I forgot this point earlier patch.) > > I send patch to fix these points. This patch tested on both Windows and > Mac OS X > platform. > >> If things go wrong, I need a log of the configuration and >> building + the generated config.log in fptools/libraries/OpenAL. > > And I send Mac OS X's config.log by CVS HEAD. -- shelarcy <shelarcy capella.freemail.ne.jp> http://page.freett.com/shelarcy/

4 6

RE: Data.* collections maintenance
by Simon Marlow 24 Oct '05

24 Oct '05

On 24 October 2005 11:54, Sebastian Sylvan wrote: > On 10/24/05, Simon Marlow <simonmar(a)microsoft.com> wrote: >> DiffArray as it stands isn't very efficient. It's an interesting >> idea, though. We should really have a DiffUArray, for one thing. > > Uh, isn't there already a DiffUArray? > > type DiffUArray = IOToDiffArray IOUArray oops, so there is. It doesn't look very efficient, though. > It would be interesting to benchmark this against the various maps. > Some code isn't too heavy on insertions so a regular Array would work > fine there. Or if it contains primitive types, unboxed arrays works as > well. > At any rate there probably should be an immutable HashMap > implementation (parameterized over the array-type). Yes, that would be nice. Cheers, Simon

1 0