- Haskell-Cafe - Haskell.org

Local Search Module
by David F. Place 23 Oct '07

23 Oct '07

Dear [Reader]: Recently, I needed to solve a constraint satisfaction problem. So I coded a solution using backtracking and tabu lists. I was pleased to see how easy it is in Haskell. As an exercise, I created a module and a class interface for the search algorithm. That was also a pleasure. Since, I've become interested in this area I thought I might try to create a library that presents a nice interface for various popular metaheuristics. I have poked around in Hackage, but not found anything similar. Is such a thing already available? I am thinking of something that would be immediately useful in Haskell programs without needing to learn another language like CLP. BTW, the problem I am working on is an automated approach to lifting pieces of Renaissance polyphony from 3-limit to 5-limit Just Intonation. Cheers, David ___________________ (---o-------o-o-o---o-o-o----( David F. Place mailto:d@vidplace.com

3 6

Hugs on Windows
by Galchin Vasili 23 Oct '07

23 Oct '07

Hello, If I run hugs from cygwin, I should be able to get Posix functionality? Kind regards, Bill Halchin

1 0

What algorithm to use ?
by manu 23 Oct '07

23 Oct '07

Hello I am not sure it is appropriate to post to this mailing list to inquire about a peculiar algorithm, if not let me know... I was looking at one particular puzzle posted on the Facebook site, 'Wiretaps' (http://www.facebook.com/jobs_puzzles/?puzzle_id=11) Briefly, you have 26 programmers (numbers 1 to 26) which need to be assigned a job (a name to decode). Even numbered programmers spend 1.5 hours more per vowel. Odd ones spend 1 hour more per consonant. And finally, each programmer whose number share primes factors with the length of the name to decode, spend 2 hours extra per factor (For example, it takes programmer 12 -- factors of 2 and 3 -- an extra 4 hours to decode 'NORMAN') The point is to come up with the combination of (programmer, name) which minimizes the time taken overall. Now the simplest solution, conceptually, is calculating the time taken by each combination, and pick the fastest... However looking at the number of permutations (26! = 403291461126605635584000000), quickly dampened my enthusiasm... There must be some algorithm (dynamic programming ?), that cuts down the number of calculations involved in order to find the right combination. But I cannot identify the proper algorithm to use... Can someone give me a tip ? Can some of the computations be parallelized ? (it's not an assignment, nor will I send anything to Facebook, I am just trying this out of curiosity) Thank you

4 3

Re: [Haskell] Re: Trying to install binary-0.4
by Duncan Coutts 22 Oct '07

22 Oct '07

On Sun, 2007-10-21 at 23:42 +0200, Udo Stenzel wrote: > Duncan Coutts wrote: > > You can hack the .cabal file further to make it work in your situation, > > but I don't suggest that's a great long term solution. If you wanted to > > hack it you'd change it to just: > > > > build-depends: base, bytestring >= 0.9 > > > > without any 'if' or flags and without cpp-options: -DBYTESTRING_IN_BASE. > > Exactly what I did, and I consider that a crock, not a solution. I agree, that's what I said. > > The solution we're using at the moment is to use the separate bytestring > > package with ghc-6.4 and ghc-6.8 and to use the version of the > > bytestring code in base-2.x for ghc-6.6.x. That's what the newest > > versions of zlib, bzlib, iconv, binary, tar etc do. They all work with > > ghc-6.4, 6.6 and 6.8 (using Cabal-1.2.x). > > IOW, on GHC 6.6 I'm stuck with bytestring-0.8 and no package that > expects bytestring >= 0.9 will work unless it contains an ugly > workaround (an #ifdef). Unless my memory is failing me, that was not a > design objective of cabal. Indeed. That was not a design objective. However it's not something Cabal can change, it's a property of the underlying Haskell implementations. Currently it is not possible for a program to use two packages that have overlapping exposed modules. Also, it is essentially impossible at the moment to upgrade the base library on an existing ghc installation. These two facts together are why ghc-6.6 users are stuck with the implementations provided by base-2.x and cannot overlay things on top. It is also the motivation for breaking up the base package into smaller pieces which can be upgraded independently. (The base package itself will still not be easily upgradable but the other packages that were split out do become upgradable). > > What kind of change are you suggesting? > > > > We have to support base 2.x because that is the versions of base that > > come with ghc-6.6.x. We cannot sensibly install the separate bytestring > > package with ghc-6.6.x because it would clash with the base package > > there. We cannot easily upgrade base in existing installations of ghc > > because ghc is just not designed with that in mind at the moment. > > I'm suggesting to pretend that base never included ByteString, to have > an empty bytestring-0.8 package for GHC-6.6 (that just copies the > configuration of base) and to have bytestring > 0.8 fix the > configuration of base for GHC-6.6. GHC-6.6 is broken, and I'm > suggesting to fix it instead of accepting the breakage. I see why it's an attractive solution but I just don't think it is practical. We cannot go changing existing installations just like that. For one thing it's only possible for root users. For another one is not supposed to modify packages managed by the system package manger. We'd never get everyone to change. > If this was the right time for grand visions, I'd propose a feature > comparable to Provides: and Replaces: of Debian's apt, maybe combined > with packages that re-export modules and a better mechanism (read: any > mechanism) to resolve conflicts between packages. base may not be > upgradeable, but parts of it are. Oh, and I think multiple packages > providing the same modules and then causing conflicts is just a bad > idea, unless of of them took precedence. I agree, any of these things would be great. At the moment none of them are implemented (and they cannot be implemented in Cabal without corresponding support from the Haskell implementations). > > The right thing to do is to use the > > latest Cabal-1.2.x with whichever version of ghc you happen to have and > > not to use a hacked version of base. > > So the API of ByteString 0.8 is now fixed and nothing is allowed to > depend on anything newer, and that will be the case for at least the > next 2 years (until GHC 6.8 trickles down into Linux distributions in > actual use). Correct? Right. In practise that's not too bad since the public api of bytestring hardly changed. The internal changes only affect extension packages that use the internal api, things like binary. > Unless I need recent developments. Then I just copy the Data/ByteString > tree into my project directory... Funnily enough that's the only thing that will work, because ghc allows local modules to mask ones from a package like base, but not for modules from two used packages to overlap. There's not a lot Cabal can do to work around that. > > There is no need to upgrade > > immediately to ghc-6.8, in fact at the moment that'd make the situation > > worse since most packages need tweaks to work with it. > > And does that feel right to you? Should they actually need tweaks? No. I'd have preferred a better solution. Cabal configurations were not designed with this purpose in mind. You listed several better solutions. However the base breakup went ahead without any of them in place. The only currently implemented solution is to take advantage of configurations. As you notice the configurations syntax for this purpose is a bit clumsy, because it was designed for a slightly different use case. If we do not want to use configurations in the upcoming ghc release then the alternative is for the accompanying packages to *only* work with base 3.0. I think it's better for them to work with older releases too, which is why I've been modifying many of them to use configurations. If I stop or revert those changes you'll just get packages that cannot be used with ghc-6.4/6.6 at all without hacking build files. > Whatever... right now it feels like messing up my 'base' configuration > was exactly right, I can stick with cabal-1.1.6.2 if I want, and having > to edit .cabal files is just part of the game. So be it. I can't > convice you of my idea of the correct fix, and I don't need to. I'm not the one you need to convince. I'd be very happy with a better solution. However nobody is seriously talking about delaying imminent releases to implement a better solution. That is what you would need to change. > [Don't get me wrong: your (that's Duncan, Don, Bjorn, and many others I > forgot) software is great. Haskell without ByteString is just not up to > processing large files, and the reason this situation pisses me off is > that I _want_ to use the latest developments and Cabal _should_ make > that easy, but it doesn't.] Cabal is not the only thing involved in how the package system works. I suggest your irritation is misdirected at the most obvious user-visible part of the system. Duncan

1 0

ANN: Haskell89 grammar extended with links to online report
by Peter Hercek 22 Oct '07

22 Oct '07

Hi, I extended the hyperlinked Haskell 98 grammar so that each production now contains also links to all the sections in the online report which explicitly name it. I needed it few times myself so I added it. Some people expressed interest so they may want to check out the update. Javascript must be enabled to have the links functional (both the backward links from a production head to all the usages and also the links to the online report). Here it is: http://www.hck.sk/users/peter/HaskellEx.htm Peter.

2 1

Strange subtract operator behavior
by Peter Verswyvelen 22 Oct '07

22 Oct '07

(/ 10) means the function that divides its argument by 10 (- 10) however is just the number -10, even if I put a space between the - and 10. How can I create a function that subtracts 10 from its argument in a clean way then? I could use (flip (-) 10) but that looks like a hack. Thanks, Peter

15 29

Automatic file closing after readFile
by Magnus Therning 22 Oct '07

22 Oct '07

I recently bumped into a problem with the feed on my WordPress blog. The problem was an extra empty line at the top of the XML file which some parsers choked on. I suspected there was some PHP file that contained an extra empty line at the top or bottom of the file so I hacked up this: hasEmpty s = let _first_empty = s !! 0 == '\n' _last_empty = (reverse s) !! 1 == '\n' in _first_empty || _last_empty loadAndCheck fp = liftM hasEmpty $ readFile fp main = getArgs >>= filterM loadAndCheck >>= mapM_ putStrLn Maybe not the most effective piece of code, but it worked. The one problem I had was that running this on /all/ files in my WP resulted in an exception: *** Exception: ./wp-includes/images/smilies/icon_mrgreen.gif: openFile: resource exhausted (Too many open files) Is there some (easy) way to avoid this while still using readFile? /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus．therning＠gmail．com http://therning.org/magnus Beauty is more important in computing than anywhere else in technology because software is so complicated. Beauty is the ultimate defence against complexity. -- David Gelernter

7 16

Re: [Haskell] Re: Trying to install binary-0.4
by Duncan Coutts 22 Oct '07

22 Oct '07

(moving to haskell-cafe) On Sun, 2007-10-21 at 14:55 +0200, Udo Stenzel wrote: > Duncan Coutts wrote: > > New tarball releases of Cabal-1.2.1, bytestring-0.9, binary-0.4.1, tar > > and others (zlib, bzlib, iconv) will appear on hackage in the next few > > days. > > I just tried one of them, iconv. First it wants a recent cabal; that's > fine, I installed the darcs version. Then I get this: > > | Codec/Text/IConv.hs:64:17: > | Could not find module `Data.ByteString': > | it is a member of package bytestring-0.9, which is hidden > > Okay, it obviously tries to be smart, but doesn't know that I upgraded > to a separate ByteString library. Right. > So I take out the gunk about 'flag(bytestring-in-base)' and try again: > | Setup: At least the following dependencies are missing: > | base <2.0||>=2.2 > > Of course that was to be expected, since I have base-2.0 hacked to not > get in conflict with bytestring-0.9, and you (Duncan) couldn't possibly > anticipate this (or could you?). Right. It expects that if you have base >= 2.0 && < 2.2 then that version of base exports Data.ByteString. That's not an unreasonable assumption I think. You can hack the .cabal file further to make it work in your situation, but I don't suggest that's a great long term solution. If you wanted to hack it you'd change it to just: build-depends: base, bytestring >= 0.9 without any 'if' or flags and without cpp-options: -DBYTESTRING_IN_BASE. > Now what am I supposed to do? Give my messed up base a new version > number? (Which one?) Rewrite every single cabal file, hoping that > they never become Turing complete turning the exercise into a reverse > engineering fest rivaling the ICFP contest? Bite the bullet and > install GHC from darcs? So you've changed the API of base-2.1.1 so that will break packages that expect that they know what the api of base-2.1.1 actually is. You can either hack the .cabal files of things you try to install (which would be a pain, I don't recommend it) or you could revert your changes to your base package. > For the time being, I'll go with 'ghc --make'. And I think that cabal > configurations are an exceptionally bad idea carried to perfection. Don't get me wrong, I'm not claiming that the changes in what is in and what is out of the base package could not have been handled better. Configurations just happen to be one mechanism that we have available now to enable packages to build with various versions of the base package. The other alternative seemed to be that they'd only work with an old or a new version but not both. There are plenty of things that we could have done better to make the base changes less disruptive but I really don't think you can blame configurations for that or for adding to that problem. If we had made different decisions at various points we would not need configurations for this purpose right now. We'd still need configurations for other things. Configurations serve other purposes too. They're not just for managing the mess over moving modules between packages. They're generally to allow changes in the way a package is built depending on the environment in which the package is built to reduce the need for non-portable configure scripts and wadges of fragile code in Setup.hs files. > They make things worse, not better. (And that's just GHC 6.6... I don't > want to even think about what happens on Hugs, JHC and YHC.) It's mostly orthogonal to the Haskell implementation since the base package is shared by all Haskell implementations. > What would it take to talk you into giving up on supporting the broken > base-2.0 and incorporating a patch to unbreak it into the bytestring > setup? Can I stop the insanity by simply writing that patch? What kind of change are you suggesting? We have to support base 2.x because that is the versions of base that come with ghc-6.6.x. We cannot sensibly install the separate bytestring package with ghc-6.6.x because it would clash with the base package there. We cannot easily upgrade base in existing installations of ghc because ghc is just not designed with that in mind at the moment. The solution we're using at the moment is to use the separate bytestring package with ghc-6.4 and ghc-6.8 and to use the version of the bytestring code in base-2.x for ghc-6.6.x. That's what the newest versions of zlib, bzlib, iconv, binary, tar etc do. They all work with ghc-6.4, 6.6 and 6.8 (using Cabal-1.2.x). > > So all will not be plain sailing for the first few weeks after > > ghc-6.8 comes out as maintainers update their packages. People will have > > to be patient and/or stick to ghc-6.6 for a bit. > > Okay, so now we have *three* almost-stable versions of GHC in wide > circulation, all of them broken in different ways with respect to cabal > packages. I feel tears welling up... So far this weekend I've uploaded to hackage: Cabal-1.2.1, bytestring-0.9, unix-compat-0.1.1, tar-0.1.1 and Kolmodin uploaded binary-0.4.1. When hackage itself is using Cabal-1.2.1 then I can also upload zlib-0.4, bzlib-0.4, iconv-0.4. All these packages (with the exception of bytestring-0.9 with ghc-6.6 as I explained) work with all recent versions of ghc. I've also been checking that the packages that will come with ghc-6.8 will also work with ghc-6.6 and 6.4 (where it makes sense for them to do so). These packages will be released separately on hackage too. This required using configurations in many cases to allow the packages to build with several base/ghc versions. I do understand you've have a bad experience with incompatible bits of software and different versions of build systems etc, but I really think the situation is not that bad. The right thing to do is to use the latest Cabal-1.2.x with whichever version of ghc you happen to have and not to use a hacked version of base. There is no need to upgrade immediately to ghc-6.8, in fact at the moment that'd make the situation worse since most packages need tweaks to work with it. Duncan

1 0

SYB3 codebase
by Greg Meredith 21 Oct '07

21 Oct '07

Haskellians, Does anyone know the status of SYB3 codebase? It appears that FreshLib critically depends on it, but the code downloadable from http://homepages.cwi.nl/~ralf/syb3/code.html dies in make test on the first test with lgmaclt:~/work/src/projex/biosimilarity/HS1/Process/haskell/SYB3 lgm$ make test make test1 stem=geq1 ghci -fglasgow-exts -fallow-overlapping-instances -fallow-undecidable-instances -v0 geq1.hs < Main.in > geq1.out geq1.hs:27:34: Inferred type is less polymorphic than expected Quantified type variable `a1' escapes Probable cause: `geq'' is applied to too few arguments In the first argument of `gzipWithQ', namely `geq'' In the first argument of `and', namely `(gzipWithQ geq' x y)' <interactive>:1:0: Not in scope: `main' diff -b geq1.out geq1.ref 0a1,4 > True > False > False > True make[1]: *** [test1] Error 1 make: *** [test] Error 2 lgmaclt:~/work/src/projex/biosimilarity/HS1/Process/haskell/SYB3 lgm$ Is there a newer version of this codebase? Has this functionality been folded into mainline Haskell tree somewhere? Best wishes, --greg -- L.G. Meredith Managing Partner Biosimilarity LLC 505 N 72nd St Seattle, WA 98103 +1 206.650.3740 http://biosimilarity.blogspot.com

3 5

building hslogger
by Chris Hayden 21 Oct '07

21 Oct '07

Hello! I'm trying to build the most recent version of hslogger and have run into some issues. Below is the error message I receive. (I see that the same error has come up elsewhere: http://haskell.galois.com/packages/archive/hslogger/1.0.2/log) The hslogger (http://software.complete.org/hslogger) website indicates that questions should be posted here - I apologize if this is the wrong venue. Thank you, Chris runhaskell Setup.hs configure Setup.hs:19:35: Couldn't match expected type `(Either GenericPackageDescription PackageDescription, HookedBuildInfo)' against inferred type `PackageDescription' In the first argument of `(confHook defaultUserHooks)', namely `mydescrip' In the expression: let mydescrip = case os of "mingw32" -> ... _ -> ... in (confHook defaultUserHooks) mydescrip flags In the definition of `customConfHook': customConfHook descrip flags = let mydescrip = case ... of "mingw32" -> ... _ -> ... in (confHook defaultUserHooks) mydescrip flags

3 2