February 2008 - Libraries

RE: Exports of STM constructors.
by Simon Peyton-Jones 28 Feb '08

28 Feb '08

[Redirecting to libraries] Your suggestion seems plausible to me: - export everything from GHC.Conc; import this only if you know what you are doing - export STM, TVar only abstractly from Control.Concurrent.STM; this is the interface for ordinary users This sounds like a candidate for the standard library modification process, if someone wants to put it into action. http://haskell.org/haskellwiki/Library_submissions Simon From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Sterling Clover Sent: 27 February 2008 20:15 To: glasgow-haskell-users(a)haskell.org Subject: Exports of STM constructors. I was recently bitten by the urge to hack around with STM, and discovered to my dismay that there's no way to get at the primitive constructors for TVar and STM, both of which are defined in GHC.Conc. Given that, when we so desire, we can get at the primitives to break IO into pieces, manually unbox integers and such, and that the primitives for working with MVars are similarly exposed through appropriate imports, it would be really nice (or, well, at least fun) to be able to do the same for STM. --S

2 1

Re: H98 Text IO
by Thorkil Naur 27 Feb '08

27 Feb '08

Hello, On Wednesday 27 February 2008 17:30, Ian Lynagh wrote: > On Tue, Feb 26, 2008 at 07:30:08PM -0500, David Roundy wrote: > > On Wed, Feb 27, 2008 at 12:06:59AM +0000, Duncan Coutts wrote: > > > I think personally I'm coming round to the "always locale" point of > > > view. We already have no cross-platform consistency for text files > > > because of the lf vs cr/lf issue and we have no cross-implementation > > > consistency. > > > > I'm leaning in the same direction. > > This has swung me too. > Let me be contrary, then: The "always locale" idea depends, as I understand it, on some relatively global setting. And, especially in the context of functional programming, global things dont strike me as particularly appropriate. This particular global thing also has the wonderful property of being modifiable. So it is actually a global variable.Some years ago, I had a hard time because some program that I hadn't written, but had to call from my program, occasionally changed the locale setting when called. The problem turned out, after much and exasperating work, to be that this changed the behaviour of sprintf: In Denmark we use commas for decimal points. I know that we are not supposed to discuss a new and marvellous IO library on this thread, but let me mention what I would consider a very valuable property of this new library that I believe may affect what we do now to clean up the present affair: I would very much like to be able to specify the desired encoding myself, as others have mentioned, at some level of using this new library. So that the present library in principle could be implemented on top of this by specifying any desirable encoding used, including using the current locale setting or utf-8 or letting the encoding depend on the device or whatever one prefers. So although my favorite choice at this moment is "always utf-8", I am much more concerned that the choice that we make does not exclude the possibility of creating this new and wonderful IO library that can be used easily to support the behaviour of the existing library (in whatever form it is changed into as a result of the present discussion). > ... Best regards Thorkil

3 2

Re: H98 Text IO
by Jules Bean 27 Feb '08

27 Feb '08

Matthew Bentham wrote: > "It’s not unreasonable to have a program that wants to encode its outputin a particular encoding. The example I gave earlier still seemsreasonable to be, a program that takes input in one encoding andrecodes to a different encoding on its output, with both the input andoutput encoding specified on the command line. Clearly such a programshould be able to use stdin and stdout so that it can form part of apipe. So how in Python do I change sys.stdout to use a particular encoding? It’s a right pain." > Which is an excellent point. But there are two (different) areas here. (1) how we make the over-simplistic H98 interface do something 'mostly right' or 'least worst' (2) how we design a better (but necessarily non-H98) interface for more sophisticated programs. And we need to solve (1) independently of all the possible nice design spaces for (2). Jules

1 0

Re: darcs patch: [PROOF OF CONCEPT] build readline package with libedit
by Christian Maeder 27 Feb '08

27 Feb '08

Robert Dockins wrote: > I've now built a Shellac-editline package using the bindings from the > editline-0.2. It's on hackage[1]. I've run the package through a quick > sanity check, but I have not extensively tested it. Thanks, I've compiled it and run a short test on an Intel Leopard with success. > [1]http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Shellac-editli… I wasn't amused to also change my sources to use editlineBackend instead of readlineBackend, besides changing the import to System.Console.Shell.Backend.Editline. Maybe the interfaces of the packages could be identical and one gets a warning when both packages are installed. (I suppose one package must be hidden then, during compilation.) 1. In order to compile under MacOS with editline and under Linux with readline it would be nice to use the same sources. In order to avoid several #ifdefs (maybe differently or suboptimal given) in user sources (to achieve 1.) such #ifdefs (or wrappers) should be part of the libraries (including the documentation for the license differences)! Cheers Christian

8 15

Cabal vs. C++
by Roman Leshchinskiy 26 Feb '08

26 Feb '08

What is the simplest way to build a Haskell project that uses a C++ library? It needs at least the following from Cabal. - It must know how to compile C++ files. This kind of works by accident if I list those under c-sources since gcc knows what to do with them but this is (a) ugly and (b) doesn't allow me to pass C++-specific options to gcc. - The project must be linked with g++. However, I don't understand how to tell Cabal which linker to use. I got as far as main = defaultMainWithHooks $ defaultUserHooks { hookedPrograms = [Program "ld" (findProgramOnPath "g++") (\_ _ -> return Nothing)] but this doesn't seem to work. configure --with-ld=g++ does, but it's not nice. Is there any simple way of making this work or do I have to use makefiles? Also, is it intentional that Cabal ignores standard environment variables such as CC, CFLAGS etc.? Roman

4 5

Storable instance for Complex
by Jed Brown 26 Feb '08

26 Feb '08

I propose that the following instance be added to base: instance (RealFloat a, Storable a) => Storable (Complex a) where sizeOf z = 2 * sizeOf (realPart z) alignment z = sizeOf (realPart z) peek p = do [r,i] <- peekArray 2 (castPtr p) return (r :+ i) poke p (r :+ i) = pokeArray (castPtr p) [r,i] This instance is binary compatible with C99, C++ and Fortran complex types. It is currently needed by at least two independent packages: hmatrix and fft. Since it is natural for user code to use both of these packages, we need to move the instance to a common location. http://hackage.haskell.org/trac/ghc/ticket/2099 Jed

4 6

Re: [GHC] #974: Add unzipEithers, lefts, rights to Data.Either
by roconnor＠theorem.ca 26 Feb '08

26 Feb '08

On Fri, 15 Feb 2008, GHC wrote: > Comment (by igloo): > > Having reread the thread, I think we are here: > > We are agreed that we should add > {{{ > lefts :: [Either a b] -> [a] > rights :: [Either a b] -> [b] > }}} > and that we should add a function with type > {{{ > [Either a b] -> ([a],[b]) > }}} > Possible names include > {{{ > splitEithers > unzipEithers > partitionEithers > catEithers > leftRights > leftsAndRights > boths > demuxEithers > }}} > While choosing a name, we should bear in mind that we might want to define > a function with type > {{{ > (a -> Either b c) -> [a] -> ([b],[c]) > }}} > at some point in the future. I am reopening discussion of this trac. Here are mine (and some others) comments on the possible names: splitEithers - reject because the result of split should be such that the concatination of the resulting two lists should be (isomorphic) to the original list. unzipEithers - reject because unzip should have the same length as the original lists. Also unzipEithers suggests there is a zipEithers somewhere. catEithers - reject because this isn't a concatination. leftRights, leftAndRights, boths - reject because they are mnenomic enough. demux, demuxEithers - these are less popular options. demux is too general, but may make for an intersting class definition somewhere. partitionEithers - This is (I believe) the most popular (or least controversial) name. The output of our function has similar properties to the output of partition. The only objection possible objection is that partitionEithers perhaps should have type (a -> Either b c) -> [a] -> ([b],[c]), ie. partitonEithers should take a function as a parameter. The response to this objection by saying that the extra `Eithers' in the name fills the place of the predicate/function. Also the function of type (a -> Either b c) -> [a] -> ([b],[c]) is less widely used that the function we are trying to name in this trac. -- Russell O'Connor <http://r6.ca/> ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''

3 3

Proposal: add new forms of unsafePerformIO and unsafeInterleaveIO
by Duncan Coutts 26 Feb '08

26 Feb '08

This proposal is to add two new variations on unsafePerformIO and one new form of unsafeInterleaveIO to the System.IO.Unsafe module in the base library (which already exports unsafePerformIO and unsafeInterleaveIO). The additions are documented and portable to non-ghc. Summary and documentation below, see patch attached to the ticket for code details. http://hackage.haskell.org/trac/ghc/ticket/2095 Suggested timescale: ~2 weeks, ends Friday 29th February Summary * unsafeDupablePerformIO and unsafeDupableInterleaveIO When GHC added SMP support the previous unsafePerform/InterleaveIO got renamed to these two functions and new unsafePerform/InterleaveIO functions were added that provide protection against duplication in a multi-threaded context. This protection comes at some cost so there are cases where it is ok to uses these weaker forms if duplicating the IO action is safe. These are already defined and documented in GHC.IOBase, this patch just exports them. * unsafeInlinePerformIO This is an even less safe form of unsafePerformIO. It is used in the Data.ByteString implementation and is very occasionally needed in other projects. If it is needed it is better that it be supplied in a portable form from a standard module with a sensible name and with full documentation. Haddock Documentation This version of 'unsafePerformIO' is slightly more efficient, because it omits the check that the IO is only being performed by a single thread. Hence, when you write 'unsafeDupablePerformIO', there is a possibility that the IO action may be performed multiple times (on a multiprocessor), and you should therefore ensure that it gives the same results each time. unsafeDupablePerformIO :: IO a -> a TODO: Actually, unsafeDupableInterleaveIO is not yet documented, that will have to be fixed. unsafeDupableInterleaveIO :: IO a -> IO a This variant of 'unsafePerformIO' is quite /mind-bogglingly unsafe/. It unstitches the dependency chain that holds the IO monad together and breaks all your ordinary intuitions about IO, sequencing and side effects. Avoid it unless you really know what you are doing. It is only safe for operations which are genuinely pure (not just externally pure) for example reading from an immutable foreign data structure. In particular, you should do no memory allocation inside an 'unsafeInlinePerformIO' block. This is because an allocation is a constant and is likely to be floated out and shared. More generally, any part of any IO action that does not depend on a function argument is likely to be floated to the top level and have its result shared. It is more efficient because in addition to the checks that 'unsafeDupablePerformIO' omits, we also inline. Additionally we do not pretend that the body is lazy which allows the strictness analyser to see the strictness in the body. In turn this allows some re-ordering of operations and any corresponding side-effects. With GHC it compiles to essentially no code and it exposes the body to further inlining. unsafeInlinePerformIO :: IO a -> a

9 12

darcs patch: moved docs for old fringeList to new parBuffer
by ben.franksen＠online.de 25 Feb '08

25 Feb '08

Warning: please review for correctness, as my understanding of this function is rather limited Mon Feb 25 21:36:36 CET 2008 ben.franksen(a)online.de * moved docs for old fringeList to new parBuffer

2 1

upgrading GHC
by Henning Thielemann 25 Feb '08

25 Feb '08

I did now spend some days(!) on making only some of my packages compatible to both GHC-6.4.1 and GHC-6.8.2. The amount of adaption work increased with every GHC update for me, also because the number of installed packages constantly grew. I'm hardly able to manage this work for GHC-6.10, many packages will then go 'outdated', maybe only weeks after their release. Some people wonder, why not simply upgrade. There are many reasons: This way you can easily fall into a gap between dependent packages that are still not updated to GHC-6.8.2 and others that are already updated, but not backwards compatible. Compiler versions are different in usability, bugs and annoyances. Namely, GHC-6.4.1 introduced wrong warnings on apparently superfluous imports and a bug that let one of my modules become uncompileable because of the compiler running out of memory, GHC-6.6 replaced working filename completion by only partially working identifier completion (it was certainly not a good idea, to remove the old behaviour completely, before the new one worked reliably, but it happened and we have to cope with), GHC-6.8.1 had a bug in compilation. So after investing much time in upgrading you might encounter that your programs don't work anymore or usability decreased considerably and you have the choice to wait for the next compiler release, try to compile the HEAD version from repository yourself (good luck!) or turn everything back to the old version. Even if the compiler does only get better with respect to features, you might decide not to upgrade, because the newer version consumes more memory or is slower due to more features that the compiler must handle. Every GHC update so far forced me to recompile my packages, broke some code, either by new class instances, modules being replaced by newer ones, shifting modules between packages. Sometimes the update helped improving the code, either when the compiler emitted new warnings or when internal functions were changed, and I became aware, that I was using internal functions. But it is very hard to get a library compiled on different compiler versions, not to mention different compilers. This is especially nasty if you are working in an institute (like the universities I worked at in the past) with different machines with very different software installations. We have some Solaris machines here with GHC-5, which I do not administer, Linux machines with GHC-6.4.1, GHC-6.6.1 and so on. I cannot simply push around patches with darcs because every machine needs separate package adaption. It was said, that Cabal would work also with GHC-6.2. I didn't get it running and then switched to GHC-6.4. It was said, that multiple versions of GHC can be installed on the same machine. That's somehow true, but e.g. runhaskell cannot be told which actual GHC binary to use, and thus it is not possible to run Cabal with a compiler or a compiler version different from the compiler to be used for the package. I decided to upgrade to Cabal-1.2, which also needed installation of filepath. I know that installation could be simplified with cabal-install, which has even more dependencies, and thus I canceled this installation project. Then I have equipped my Cabal files with a switch on splitBase, which merely duplicates the globally known information that former base-1.0 package is now split into base-2.0 or base-3.0 and satellites. It doesn't give the user any new value, but costs a lot of time for the package maintainer. I wonder if it would have been simpler to ship GHC-6.8 with a base-1.0 package or provide it on Hackage that just re-exports the old modules in the known way. This would allow the usage of packages that are in different state of adaption and it will reduce the amount of work for package maintainers considerably. I also predict that the switch on different package arrangements in the Cabal file will grow in future, eventually becoming error-prone and unmaintainable. How many GHC versions do you have installed simultaneously in order to test them all? Don't misunderstand me. I embrace tidying the libraries but I urge to do it in a more compatible manner. Deprecated packages do not need to be banned from the internet. It is not necessary to enforce programmers to adapt to changes immediately, it is better provide ways for doing the changes later, when time has come, in a smooth manner. I thought it was a good idea to adapt to FunctorM in GHC-6.4 quickly instead of rolling my own class. Then, two GHC releases later this module disappeared, was replaced by Traversable. I thought it was good style to rewrite code from List.lookup to FiniteMap in GHC-6.0, in GHC-6.4 it already disappeared, replaced by Data.Map. Why is it necessary to make working libraries obsolete so quickly? I thought using standard modules is more reliable (because of more testers, more possible maintainers) than using custom modules. If libraries change so quickly this forces programmers to fork to their own modules.

5 9