- Libraries - Haskell.org

hscolour -anchor via cabal ?
by Conal Elliott 03 Mar '08

03 Mar '08

Is there a way to get cabal to tell hscolour to add anchors for top-level defs (hscolour's -anchor option)?

4 5

Proposal: Add an instance for IArray (IOToDiffArray IOUArray) Bool (Trac #2133)
by Matti Niemenmaa 02 Mar '08

02 Mar '08

An instance for 'IArray (IOToDiffArray IOUArray) Bool' is missing from Data.Array.Diff. There doesn't seem to be any good reason for this: all the other 'IArray UArray a' instances defined in Data.Array.IArray have corresponding instances. Bool is the sole exception. They cannot be added in user code without copying the entire Data.Array.Diff source, since the instances require internal functions which aren't exposed. Since all the instances are defined in exactly the same way, only varying the second type parameter, this requires practically zero work: just copy any of the other instances and replace the type parameter with Bool. A Show instance should also be provided. Both are in the patch (attached to the ticket). To be sure that the instances haven't been omitted because they don't work, I wrote a few QuickCheck properties (attached to the ticket) and it seems that it does work without any trouble. Suggested deadline for discussion: 17th March 2008.

1 1

every use of BSD4 on hackage is incorrect
by Duncan Coutts 02 Mar '08

02 Mar '08

The following hackage packages specify in their .cabal file: license: BSD4 Which is the 4-clause BSD license, ie the one with the advertising clause. cabal-upload-0.3 Chart-0.5 FiniteMap-0.1 haxr-3000.0.1 haxr-th-1.0 hbeat-0.1 htar-0.1 pcap-0.4.2 tar-0.1.1.1 unix-compat-0.1.2.1 Inspecting the LICENSE files for every one of these packages reveals that they actually use the 3-clause BSD license. Not a single hackage package really uses the 4-clause BSD license. In every case that it has been used it was just a confusion. We therefore propose to deprecate BSD4 as a valid license in .cabal files: http://hackage.haskell.org/trac/hackage/ticket/205 In the unlikely case that anyone really wants to use the 4-clause BSD license they can still specify "license: OtherLicense" and put the text in the accompanying LICENSE file. Additionally, I propose to add the MIT license since there are a couple packages that really use that and allow optional versions on the licenses that are versioned, which includes the GPL and LGPL. Looking at OtherLicense we find common ones are MIT, variations on BSD3 (2 clause and fewer, other informal variations), disjunctions of BSD3 / GPL (ie dual licensing), conjunctions of BSD3 / GPL (ie some bits user BSD some under GPL). Duncan

3 3

H98 Text IO
by Duncan Coutts 29 Feb '08

29 Feb '08

>From the H98 report: All I/O functions defined here are character oriented. [...] These functions cannot be used portably for binary I/O. In the following, recall that String is a synonym for [Char] (Section 6.1.2). So ordinary text Handles are for text, not binary. Char is of course a Unicode code point. The crucial question of course is what encoding of text to use. For the H98 IO functions we cannot set it as a parameter, we have to pick a sensible default. Currently different implementations disagree on that default. Hugs has for some time used the current locale on posix systems (and I'm guessing the current code page on windows). GHC has always used the Latin-1 encoding. These days, most operating systems use a locale/codepage encoding that covers full the Unicode range. So on hugs we get the benefit of that but on GHC we do not. This is endlessly surprising for beginners. They do putStrLn "αβγδεζηθικλ" and it comes out on their terminal as junk. It also causes problems for serious programs, see for example the recent hand-wringing on cabal-devel. So here is a concrete proposal: * Haskell98 file IO should always use UTF-8. * Haskell98 IO to terminals should use the current locale encoding. The main controversial point I think is whether to always use UTF-8 or always use the current locale or some split as I've suggested. C chose to always go with the current locale. Some people think that was a mistake because the interpretation changes from user to user. For terminals it is more clear cut that the locale is the right choice because that is what the terminal is capable of displaying. Using anything else will produce junk. We can detect if a handle is a terminal when we open it using hIsTerminalDevice. This should be done automatically (and ghc would ghc get it for free because it already does that check to determine default buffering modes). Sockets and pipes would be treated the same as files when opened in the default text mode. The only special case is terminals. The major problem is with code that assumes GHC's Handles are essentially Word8 and layer their own UTF8 or other decoding over the top. The utf8-string package has this problem for example. Such code should be using openBinaryFile because they are reading/writing binary data, not String text. Note that many programs that really need to work with binary file already use openBinaryFile, those that do not are already broken on Windows which does cr/lf conversion on text files which breaks many binary formats (though not utf8). So we have decide which is more painful, keeping a limited text IO system in GHC or breaking some existing programs which assume GHC's current behaviour. Opinions? Please can we keep this discussion to the interpretation of the H98 IO functions and not get into the separate discussion of how we could extend or redesign the whole IO system. This is a questions of what are the right defaults. Duncan

14 35

darcs patch: #2053: add additional history functions (+1 more)
by Judah Jacobson 28 Feb '08

28 Feb '08

The following patches reflect the discussion and consensus on #2053. The discussion period has passed; can someone please apply them to the readline repo? Thanks, -Judah Mon Jan 21 21:05:36 PST 2008 alexander.dunlap(a)gmail.com * #2053: add additional history functions The following functions were added: readHistory, writeHistory, appendHistory, historyTruncateFile, clearHistory, stifleHistory, unstifleHistory, historyIsStifled, historyMaxEntries M ./System/Console/Readline.hsc +85 Tue Feb 26 15:39:29 PST 2008 judah.jacobson(a)gmail.com * #2053: Make readHistory/writeHistory return a Bool instead of throwing an exception on failure. M ./System/Console/Readline.hsc -9 +10

2 1

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 28 Feb '08

28 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 27 Feb '08

27 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