- Libraries - Haskell.org

Proposal: Add &&& and *** to Data.Tuple
by Josef Svenningsson 23 Oct '07

23 Oct '07

Hi all, It is becoming increasingly popular to import Control.Arrow just to get access to the functions &&& and *** specialized to the function arrow. I propose to add the specialized version of these two functions to Data.Tuple which is more logical thing to import if you wish to have functions operating on tuples. I have chosen the same fixities for these operators as in Control.Arrow. I have deliberately chosen not to include any tests. These functions are so simple that eye-balling them beats any other method of verification, at least in my opinion. Some suggestions for better documentation of &&& would be very welcome. Proposal period: 2 weeks. Deadline October 1st. I haven't been able to create a ticket for this proposal. I'm unsure what the problem is, maybe trac and Firefox doesn't work so well together. No matter what I've tried (logging as both myself and as guest) trac tells me that I don't have the permission to create a ticket whenever I submit it. If someone would be willing to create a ticket for this proposal I would be grateful. Cheers, /Josef

18 44

Re[2]: System.Win32.Types to base library?
by Bulat Ziganshin 23 Oct '07

23 Oct '07

Hello Felix, Tuesday, October 23, 2007, 1:24:08 AM, you wrote: >> NO, because this will lead again to non-upgradability hell. other >> libraries will need to import these types from different places >> depending on GHC version where they are runned > Ok, so how about a new module in base for Windows API error handling? > E.g. a Foreign.C.Error.Win32 module which resembles Foreign.C.Error. it will raise the same problem. imho, it's better to redefine as much as possible in other libs, or just reexport `base` types/functions via additional libs -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

Data.Stream conflict
by Conal Elliott 21 Oct '07

21 Oct '07

The "arrows" and "Stream" package both provide a Data.Stream module. I'd like to use the latter, which is much more filled out, but ghc is finding and choosing the former. Are there mechanisms for resolving this kind of conflict? - Conal

2 1

Data encoding library
by Magnus Therning 20 Oct '07

20 Oct '07

I've just created the page http://haskell.org/haskellwiki/Library/Data_encoding (there are no links into it at the moment). Any comments on what I've written there? Are the locations in the hierarchy good? I have code to share if you are interested in commenting on it as well. Just let me know and I'll find a place to put it for public download. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus．therning＠gmail．com http://therning.org/magnus Windows [n.] A thirty-two bit extension and GUI shell to a sixteen bit patch to an eight bit operating system originally coded for a four bit microprocessor and sold by a two-bit company that can't stand one bit of competition. -- Anonymous USEnet post

2 4

Applicative functor for building C structs with Storable
by Henning Thielemann 20 Oct '07

20 Oct '07

Are there analogons to ByteString's Put and Get Monads to construct and disect binary data in a C struct for exchange with a C program?

6 11

Re: [Haskell] Re: Trying to install binary-0.4
by Simon Marlow 19 Oct '07

19 Oct '07

Several good points have been raised in this thread, and while I might not agree with everything, I think we can all agree on the goal: things shouldn't break so often. So rather than keep replying to individual points, I'd like to make some concrete proposals so we can make progress. 1. Document the version numbering policy. We should have done this earlier, but we didn't. The proposed policy, for the sake of completeness is: x.y where: x changes ==> API changed x constant but y changes ==> API extended only x and y constant ==> API is identical further sub-versions may be added after the x.y, their meaning is package-defined. Ordering on versions is lexicographic, given multiple versions that satisfy a dependency Cabal will pick the latest. 2. Precise dependencies. As suggested by various people in this thread: we change the convention so that dependencies must specify a single x.y API version, or a range of versions with an upper bound. Cabal or Hackage can refuse to accept packages that don't follow this convention (perhaps Hackage is a better place to enforce it, and Cabal should just warn, I'm not sure). Yes, earlier I argued that not specifying precise dependencies allows some packages to continue working even when dependencies change, and that having precise dependencies means that all packages are guaranteed to break when base is updated. However, I agree that specifying precise dependencies is ultimately the right thing, we'll get better errors when things break, There's lots more to discuss, but I think the above 2 proposals are a step in the right direction, agreed? Cheers, Simon

14 30

Linking executables and the library of a Cabal package description
by ramsdell＠mitre.org 18 Oct '07

18 Oct '07

I'm sure this will be an easy question for those on this list. What do you need to add to a Cabal package description so as to allow an executable in the description to be built from the library it also describes? I searched the Cabal documentation many times, but came up empty handed. John $ make runhaskell Setup.hs build Preprocessing library a-1.0... Preprocessing executables for a-1.0... Building a-1.0... [1 of 1] Compiling A ( A.hs, dist/build/A.o ) /usr/bin/ar: creating dist/build/libHSa-1.0.a exec/Main.hs:3:7: Could not find module `A': Use -v to see a list of the files searched for. make: *** [all] Error 1 $ : after cleaning... $ more `find . -type f ` > ../a.txt $ cat ../a.txt :::::::::::::: ./a.cabal :::::::::::::: Name: a Version: 1.0 Build-Depends: base Exposed-Modules: A Executable: b Main-Is: Main.hs Other-Modules: A Hs-Source-Dirs: exec :::::::::::::: ./Setup.hs :::::::::::::: import Distribution.Simple main = defaultMain :::::::::::::: ./Makefile :::::::::::::: SETUP = runhaskell Setup.hs all: if test ! -f .setup-config; then $(SETUP) configure; fi $(SETUP) build Makefile: @echo make $@ %: force $(SETUP) $@ .PHONY: all force :::::::::::::: ./A.hs :::::::::::::: module A where a :: Int a = 3 :::::::::::::: ./exec/Main.hs :::::::::::::: module Main (main) where import A main :: IO () main = print a $ ghc -h ghc-6.6.1: unrecognised flags: -h Usage: For basic information, try the `--help' option. $ uname -a Linux goo 2.6.22.9-91.fc7 #1 SMP Thu Sep 27 23:10:59 EDT 2007 i686 i686 i386 GNU/Linux $

4 11

CPP confusion
by Duncan Coutts 17 Oct '07

17 Oct '07

All, There seems to me to be a great deal of confusion with CPP options in Haskell land. We apply the same cpp options to C code and to Haskell code, and there are other tools like pre-processors which make things even more confusing. The latest thing I've stumbled over is HsUnix.h in ghc-6.8. This header file is for defines to use when pre-processing Haskell code. It used to live in the global $GHCLIBDIR/include but now lives in the include dir for the unix package. This is probably the right thing to do, however... How do packages that want to use this include actually use it? If they #include it directly in a .hs file then it'll work since ghc -package unix adds the unix package's include dir to the search path. But what if someone needs to use it in a .hsc file? Well, then it does not work. It does not work because Cabal does not pass these include directories to hsc2hs, since we've relied on ghc to do that. But obviously that does not work for hsc2hs. As it happens the fork of hsc2hs that ghc comes bundled with uses ghc as it's C compiler, so we could in fact pass hsc2hs --cflag=-package --cflag=unix then it does work because hsc2hs ends up passing ghc -package unix and then ghc adds the unix's include dir to the search path when it goes on to call gcc to actually compile the C code. Yay, for many layers of confusion. So what is the solution? We could take advantage of the fact that we know that hsc2hs really uses ghc as it's C compiler and change the flags we pass it when we happen to be building with ghc. On the other hand this all becomes non-portable. In fact this totally relies on a package database to remember what search directories to use when pre-processing dependent packages. In other words it only has a chance of working with ghc at the moment, or nhc in future if/when it implements a package database. What to do? Short and long term suggestions please. Duncan

3 2

Support for high baud rates in the serial binding
by Don Stewart 17 Oct '07

17 Oct '07

The attached patch adds support for higher baud rates to System.Posix.Terminal. We need this in practice, so it would be nice to get this into stable. Its a trivial change. -- Don

1 0

Re: [Haskell-cafe] Let's do ListT right, finally
by David Menendez 15 Oct '07

15 Oct '07

On 10/14/07, Dan Piponi <dpiponi(a)gmail.com> wrote: > On 10/14/07, Yitzchak Gale <gale(a)sefer.org> wrote: > > Not very much, I suspect. That "monad" really is broken - > > it's not a monad at all. > > Depending on your point of view, ListT isn't broken. It correctly > transforms commutative monads into monads. The problem is that you > can't express "commutative monad" any differently from "monad" in > Haskell. And so it's been shoehorned into the wrong type class. If desired, we could easily define a class for commutative monads, and then state that ListT m is only a monad if m is a commutative monad. For example, class Monad m => CommutativeMonad m instance (CommutativeMonad m) => Monad (ListT m) where return a = ListT (return [a]) etc. Naturally, it's up to the programmer to guarantee that instances of CommutativeMonad are actually commutative monads. -- Dave Menendez <dave(a)zednenem.com> <http://www.eyrie.org/~zednenem/>

2 1