June 2009 - Libraries

Re: Top Level
by John Lato 23 Jun '09

23 Jun '09

> From: wren ng thornton <wren(a)community.haskell.org> > > I think at this stage in the game, OpenGL.* is probably better. The way > I see it there are two rather different kinds of modules (or module > collections): > > * For module collections which have high utility across many different > packages/programs (e.g. Data.Map, Control.Monad), having > functionality-based names is helpful for solving name-clash and > functionality-discovering/remembering issues. These modules are truly > stand-alone "libraries" and are extremely composable (with other module > collections) and extremely decomposable (from module collection into the > constituent modules). > > * However, there are other collections of modules which are not > "libraries" so much as "frameworks". While they're still (usually) > composable, they're typically not decomposable. Often these are the > results of taking an executable and shaving off some of the front-end > details. Because of the non-decomposability, it makes sense to me to > give each of these a top-level module name. Under the top-level they > should be organized by functionality--- in the terms of the framework > itself, not in the general terms shared by the "libraries". > +1. For me, the largest problem with the current system is one that Simon mentioned under his third point. While I may know what to expect from a module named "Control.Functor.Pointed", I have no idea what package to import to get that functionality.* This situation is worse in the cases of multiple packages providing the same modules, such as transformers and mtl. I do think that the module namespace hierarchy is useful, and I am not convinced that the top level should be flattened, but I think it would be good to have some sort of tighter connection between package name and either the top level or second level module name, even if only as a convention. John Lato * I actually do know, because it's my example. It's in category-extras. I was able to find this in Hayoo!, but not Hoogle.

2 2

Re: was 6.10.3 prerelease
by Yusaku Hashimoto 22 Jun '09

22 Jun '09

It is problem about the library for dealing OS process. This bug is fixed, and fixed version of process is in the repository. You can check out latest library from http://darcs.haskell.org/packages/ process and replace the library in the build directory (libraries/ process). If you are bothered to this, you can just comment-in a line 90 (maybe near of here...) in libraries/process/cbits/runProcess.c to disableItimers() in the child process. HTH, Hashimoto On 2009/06/20, at 21:09, Iain Barnett wrote: > In reference to http://www.nabble.com/6.10.3-prerelease- > td23346957.html > > I also run Mac OSX 10.4.11 (there are some left) and I experience > the same problem but with the full release of 6.10.3 from source. > I've read the discussion and the trac ticket at http:// > hackage.haskell.org/trac/ghc/ticket/3243, but I have no idea how to > actually get and apply the patch. > > Sorry if I'm being incredibly thick, (or even just a bit thick) but > I have barely used C or darcs (though I do have darcs installed). > Any advice on how to fix this is much appreciated - originally I > just wanted to upgrade Cabal but when it didn't work I tried to > upgrade GHC, and now I seem to be digging a big hole! > > Iain > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

3 2

problems encountered installing/upgrading Cabal
by Iain Barnett 21 Jun '09

21 Jun '09

I want to install Cabal library 1.6.0.2 on OSX 10.4.11. Unfortunately, none of my attempts so far appear to have worked. I already had 1.4.0.1 but it wouldn't upgrade when running "cabal upgrade", it just hangs. iainb$ cabal --v cabal-install version 0.5.1 using version 1.4.0.1 of the Cabal library first attempt: iainb$ darcs get http://darcs.haskell.org/cabal-install iainb$ sudo sh bootstrap.sh Setup: At least the following dependencies are missing: Cabal >=1.7.2 && <1.9 Error during cabal-install bootstrap: Configuring the cabal-install package failed second attempt; I downloaded the tarball from http://www.haskell.org/ cabal/release/cabal-1.6.0.2/Cabal-1.6.0.2.tar.gz: iainb$ cd Cabal-1.6.0.2/ iainb$ sudo runhaskell Setup configure --prefix=/usr/local/ iainb$ sudo runhaskell Setup build iainb$ sudo runhaskell Setup install Installing library in /usr/local/lib/Cabal-1.6.0.2/ghc-6.8.3 Registering Cabal-1.6.0.2... Reading package info from "dist/installed-pkg-config" ... done. Saving old package config file... done. Writing new package config file... done. iainb$ cabal --v cabal-install version 0.5.1 using version 1.4.0.1 of the Cabal library If I run "ghc-pkg list" then it displays: /usr/local/lib/ghc-6.8.3/package.conf: Cabal-1.2.3.0, Cabal-1.6.0.2, ... /Users/iainb/.ghc/i386-darwin-6.8.3/package.conf: Cabal-1.6.0.2, ... I don't seem to understand what I'm supposed to do, or why 1.4.0.1 is the lib being used when it's not in the pkg list. Does anyone know how I can get cabal-install to use the new library? Any help is much appreciated. Iain

3 2

Cool C libraries we could have on hackage server
by Maurício 20 Jun '09

20 Jun '09

Hi, I just submitted bindings to libusb, and realized I should comment pkgconfig-depends in .cabal since libusb-1.0 is not installed on the server, or cabal would refuse building it. There are many libraries we probably would like to have bindings for, but we need to have them on hackage to do that. What if we generate a wish list of really trusted and important libraries we would like to use, and then test if they build on hackage, and install in /usr/local those that do? I have a few sugestions: http://www.gnu.org/software/gsl http://www.hdfgroup.org/HDF5 http://libusb.sourceforge.net http://sourceware.org/libffi http://directory.fsf.org/project/mailutils Best, Maurício

6 8

Haskell Platform difficulties
by Wolfgang Jeltsch 19 Jun '09

19 Jun '09

Hello, I just wanted to install a current GHC and some Haskell libraries on my new Debian lenny installation. So I thought I’ll go the quick and easy route via the new Haskell Platform. Alas, I had to discover that I need GHC >= 6.10.3 already installed in order to install the platform. So I wonder why it isn’t possible to use an older GHC. GHC 6.10.x should be compilable with older GHCs and the libraries could be compiled with the newly installed GHC 6.10.x. If GHC >= 6.10.3 wouldn’t be needed in advance, I could install GHC 6.8.2 from the Debian package repository and then install the Haskell Platform using it. Now, it’s actually easier to not use the platform at all. :-( In addition, I wonder whether it would be possible to make binary distributions of the Haskell Platform, at least for generic Linux x86 and x86_64. If I install GHC and libraries by hand, I can take an already compiled GHC. If I use the platform, GHC needs to be compiled from source. Best wishes, Wolfgang

2 1

Re: Top Level
by Malcolm Wallace 19 Jun '09

19 Jun '09

Wolfgang Jeltsch <g9ks157k(a)acme.softbase.org> wrote: > The Yampa people and I (the Grapefruit maintainer) already agreed to > introduce a top-level FRP namespace instead of putting FRP under > Control or whatever. The problem with a top-level namespace like FRP is that it is a cryptic acronym: it means nothing to a novice, and may be easily confused with other acronyms by an expert. I believe top-level names should _at_the_ _very_least_ be minimally descriptive of the category of things that live in it. So, I'd be fine with Control.Reactive.FRP, Control.Reactive.Yampa, etc, or even just Reactive.Yampa etc. I do understand that hierarchical classification is inherently problematic, and will never quite fit the ways we think of our modules. But the alternative being proposed here is neither more descriptive, nor more logical. In fact, it is an abandonment of description, in favour of arbitrary naming. A package called foo-1.0 containing a module hierarchy rooted at "Foo." tells me precisely nothing about its contents. It it were rooted at Military.Secret.Foo, at least I would have some clue about what it does, even if the category is inadequate or slightly misleading in certain circumstances. You may argue that only novices are disadvantaged by arbitrary names - once you learn the referent of the name, it is no longer confusing. However, I strongly believe that even experienced users are helped by the continuous re-inforcement of visual links between name and concept. After all, if you are collaboratively building a software artifact that depends on large numbers of library packages, it may not be so easy to keep your internal dictionary of the mapping between names and functionality up-to-date, and in sync with your colleagues. Being just a little bit more explicit in the hierarchy is a one-time cost at time of writing, that reaps perceptual benefits long into the future for yourself, and those maintainers who will follow you. Regards, Malcolm

6 6

Applicative functor composition
by Henning Thielemann 18 Jun '09

18 Jun '09

In the TypeCompose package there is the O data type for composing two applicative functors http://hackage.haskell.org/packages/archive/TypeCompose/0.6.4/doc/html/Cont… However I hesitate to import this package because of a lot of needed type extensions. But since 'O' seems to be the canonical way for combining two functors, could we add it to Control.Applicative?

3 2

Proposal #3271: new methods for Data.Sequence
by Louis Wasserman 18 Jun '09

18 Jun '09

(Thanks to Isaac for the n00b-friendly instruction link!) http://hackage.haskell.org/trac/ghc/ticket/3271 Data.Sequence is meant as a general-purpose implementation of finite sequences. The range of methods it offers, however, is considerably more constrained than Data.List, even allowing for the constraint that sequences are finite. The following methods cannot be efficiently implemented based on currently exported methods from Data.Sequence. - zipWith and its variants. Note: it suffices to define zipWith alone. - replicate. (This can be implemented in O(log n) time with node sharing.) The following methods are relatively simple extensions of already-exported methods. It may be more appropriate to allow library users to reimplement them themselves. - scanl, scanr, and variants. This is relatively straightforward using methods borrowed from the Traversable instance. - tails and inits. tails is equivalent to scanr (<|) empty; inits is similar. - takeWhile, dropWhile, span, break (and perhaps from-the-end variations). Finding a breakpoint index can be done as efficiently on lists as on sequences; find the appropriate breakpoint index after converting to a list and use splitAt. - unfoldr and iterate, though the latter would require a finite number of iterations to perform. - partition. I can conceive of a slightly more efficient implementation than the trivial one, but the gains may be minimal. Discussion deadline: two weeks from today (June 16). Of these, I have implemented the first three bullets. Louis Wasserman wasserman.louis(a)gmail.com On Mon, Jun 1, 2009 at 9:52 PM, Isaac Dupree <ml(a)isaac.cedarswampstudios.org > wrote: > Louis Wasserman wrote: > >> This patch contains several methods for Data.Sequence I've always thought >> were long missing: >> > > Excellent! Can you make an official "library proposal"? It's not hard. > http://www.haskell.org/haskellwiki/Library_submissions > > Basically, see section 2: make a Trac ticket; choose a discussion deadline > (perhaps, 2 weeks from now); and then post back on this mailing-list > including a link to the ticket, a copy of the description, and stating the > end-of-discussion date. > > -Isaac >

2 1

Ticket #3271: New methods for Data.Sequence
by Louis Wasserman 17 Jun '09

17 Jun '09

I'm finished with Ticket #3271: New methods for Data.Sequence. I'd like someone to at least briefly review it before committing it, but I'm pretty sure I've done everything right. I think there are some separate, Cabal-based issues with containers (specifically, I need to amend containers.cabal to depend on base>=4.0.0.0, but that should be a separate bug), but I'm confident in everything there currently, and QuickCheck confirms that all of the added methods behave analogously to their Data.List counterparts. Louis Wasserman wasserman.louis(a)gmail.com

1 0

Top Level
by Ashley Yakeley 16 Jun '09

16 Jun '09

(moving to Libraries list) Wolfgang Jeltsch wrote: > The Yampa people and I (the Grapefruit maintainer) already agreed to introduce > a top-level FRP namespace instead of putting FRP under Control or whatever. > Graphics.UI is a bad choice in my opinion, since not all user interfaces are > graphical (ncurses) and for those who are, it’s not so important anymore that > they are (it was important in the 1980ies). So it might be good to change > Graphics.UI to just UI. Then we might want to change Graphics.Rendering to > just Graphics. > > What do others think? I prefer this too. UI and Graphics are different things: doing stuff with images is graphics but not UI, while ncurses or even a command-line is UI but not graphics. -- Ashley Yakeley

1 0