- Libraries - Haskell.org

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

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

24 Oct '05

On 24 October 2005 11:17, Sebastian Sylvan wrote: > On 10/24/05, Simon Marlow <simonmar(a)microsoft.com> wrote: >> 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 :) > > Wouldn't an Array (or DiffArray) based HashMap be even better? DiffArray as it stands isn't very efficient. It's an interesting idea, though. We should really have a DiffUArray, for one thing. Cheers, Simon

2 1

RE: Darcs supports pre-checkin hooks was Re: Controlled anarchy
by Simon Marlow 24 Oct '05

24 Oct '05

On 23 October 2005 13:10, Sven Panne wrote: > I see a dire need for more Haskell *maintainers*, not for more > developers or brand new shiny version control systems. With > "maintainers" I mean people accepting/testing/merging patches, > discussing with people about APIs, kicking coders to write tests for > their code, collecting opinions and writing down API proposals, > keeping existing APIs stable/sane/usable, etc. This is a lot of work, > it's difficult, time-consuming and much less fun than coding, but we > need those people. Darcs won't help with this at all... Here here... However, my impression is that moving to darcs is not purely an attempt at a technical solution to a social problem. Many of the people we want to attract as maintainers are the kind of people who appreciate good tools, an enjoy working with them. Adopting a better VC system would increase the Fun Factor for working with our code, which in turn will encourage more people to contribute. Maintaining libraries is quite boring. We need to make it more enjoyable. Cheers, Simon

1 0

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

24 Oct '05

On 23 October 2005 16:19, Jean-Philippe Bernardy wrote: > Also, what's the current story on moving fptools/libraries to darcs? > While I agree with Sven that its not the solution to everything, I > would still prefer to use it over cvs. I think we have a plan, it's stalled a bit because I've been busy hacking on GHC's multiprocessor support to the exclusion of everything else. I'll try to send another email shortly and get the process moving again. Cheers, Simon

1 0