- Haskell-Cafe - Haskell.org

wordsBy in the base libraries?
by Maxime Henrion 23 Oct '07

23 Oct '07

Hello all, What do you think about having a wordsBy function in the standard libraries? It often comes in handy. > wordsBy :: (a -> Bool) -> [a] -> [[a]] > wordsBy p s = case dropWhile p s of > [] -> [] > ':rest -> (s':w) : wordsBy p s'' > where (w, s'') = break p rest This version takes care of avoiding a redundant character check that is present in the standard definition of the words function, originally discovered by Neil Mitchell, see his blog post here: http://neilmitchell.blogspot.com/2007/07/equational-reasoning-in-haskell.ht… Then we can define the words function naturally: > words :: String -> [String] > words = wordsBy isSpace Cheers, Maxime

5 11

Re: [Haskell-cafe] Function Types
by PR Stanley 23 Oct '07

23 Oct '07

f x = x x :: a f x :: b therefore f :: a -> b x = a and x = b therefore a = b therefore f :: a -> a Simple mappings are easy to work out. It's the more detailed stuff I'm not sure about. f g x y = g x (y x) Cheers, Paul At 03:15 23/10/2007, you wrote: >On 10/22/07, PR Stanley ><<mailto:prstanley@ntlworld.com>prstanley(a)ntlworld.com> wrote: >Hi >What are the rules for calculating function types? >Is there a set procedure ? >Thanks, Paul > > >There must be a set procedure, since otherwise the compiler could >not function! =) > >Seriously, though, I'm not exactly sure what you're asking >for. Could you maybe provide a few examples of the kind of thing >you're asking about? > >-Brent

4 3

How much of Haskell was possible 20 years ago?
by Maurício 22 Oct '07

22 Oct '07

Hi, I like Haskell, and use it as my main language. However, compiling a Haskell program usually takes a lot of memory and CPU. So I was curious, and would like to know from computer scholars in this list: how much of Haskell would be possible in machines with really low CPU and memory? Which features would be feasible for a compiler to implement, and for programmers to use? Thanks, Maurício

8 14

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

22 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 22 Oct '07

22 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 22 Oct '07

22 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 21 Oct '07

21 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