- Haskell-Cafe - Haskell.org

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

23 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 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

Why doesn't Hackage link to Haddock documentation anymore?
by Johan Tibell 21 Oct '07

21 Oct '07

Maybe I'm seeing things but from what I remember packages that used to have links to Haddock documentation in their exported modules list no longer has. It's a super useful feature! What happened to those packages? -- Johan

4 4

On the verge of ... giving up!
by Vimal 20 Oct '07

20 Oct '07

Dear Haskellers, I have been trying my best to read about Haskell from the various tutorials available on the internet and blogs. I havent been following YAHT properly, so its always been learning from 'bits and pieces' scattered around. For most languages (like C/C++/Ruby/Python), the above approach has helped me. But for Haskell, it is failing. I like learning by comparison with other similar languages. This approach worked for me when I tried learning Python+Perl together. The nicer syntax and easier object-orientedness made me leave Perl behind and pursue Python. I also tried it for Haskell (Lisp+OCaml+Haskell together). The next step I usually take in learning a language is, not to go by the topics found in textbooks, but by taking real world examples and then blindly try to solve it using that language as a tool. For e.g, I tried writing a terminal GTalk client for Python when I was learning it, and learnt so many features that way. I used to call this 'learning by need', and it worked, to the extent that I never knew how to take 'input' from the user, but knew how to write Objects in Python! (Since I never used input in that example :) I didnt want to repeat that mistake, so I made sure I would learn IO in Haskell, which initially turned out to be a disaster, due to the 'Moands' which sounded like 'Go Mads' to me. Then, I set out to learn Monads + Category Theory from a Math perspective. And since I haven't been introduced to abstract math (like Groups, etc.), I found this a little difficult. However I tried my best to understand the tiniest bit and waited for the tiniest spark that would enlighten me. It didn't work out. --snip-- Okay, so you might be wondering as to whats the whole point of this mail? Well, I am almost on the verge of giving up on something I really like to learn, just because I didn't go in the right order! So, I requested my institute to buy Dr. Graham Hutton's book. I would be getting hold of that quite soon, and am willing to start from the beginning. Meanwhile, could anyone suggest if there was anything wrong in my approach to learning Haskell/the other languages? I agree that the learning methodology is something personal and I have to find out what best suits me, but I would like to hear something from you, Haskellers, too. I have no need to hurry anything at this point of time. But after being introduced to the tiniest bit of Haskell, and after seeing such a large and active community here, and #haskell, I had the plan of conducting a Haskell Workshop, in our department (sometime in Feb next year, the dates have not been finalized). I just hope that I should be able to reach a substantial amount of familiarity with Haskell by that time! Sorry for the long mail, and pardon me if it was too boring. I just put my thoughts on <strike>paper</strike> a mail :) I did have a couple of ambitious projects in my mind when to help me learn Haskell. They were: 1. An online judge system (Like http://spoj.pl) I had already done one for contests that were held during our Technical festival here, using php. The ideas are laid out. All I had to focus on was learning Haskell. 2. A solver for the Peg-Solitaire. This was more of an academic interest. I have seen Richard Bird's presentation on 'How to write a functional pearl, with an example' and was quite impressed by it. But the actual modelling might be slightly tricky here, and I am yet to start off with it. Many thanks for your patience, Cheers, -- ~Vimal IIT Madras RLE :) encode = map (length &&& head) . group decode = concatMap (uncurry replicate)

34 78

Filesystem questions
by Andrew Coppin 20 Oct '07

20 Oct '07

I notice that getDirectoryContents appears to return its results in alphabetical order. Is this behaviour actually guaranteed? Related: Is there a way to get rid of "." and ".." in the results? (Obviously this causes directory recusion to malfunction.) I can of course manually filter them out, but it's annoying. Finally, why do doesDirectoryExist "C:" doesDirectoryExist "C:\" both yield False? (This frequently trips up programs that try to check that a destination folder exists.)

11 19

Pixel plotter
by Andrew Coppin 20 Oct '07

20 Oct '07

> http://darcs.haskell.org/~lemmih/hsSDL/ <http://darcs.haskell.org/%7Elemmih/hsSDL/> How do I use this? I've seen instructions floating around somewhere that if a library has a "Setup.hs", you're supposed to do runhaskell Setup configure runhaskell Setup build runhaskell Setup install However, the first command prints a huge stream of text and then complains about "can't find sh". (Well, why would you? It's Windows...)

5 6

Re: [Haskell] Fingerprints and hashing
by Bulat Ziganshin 20 Oct '07

20 Oct '07

Hello Simon, Thursday, October 11, 2007, 1:42:31 PM, you wrote: > For various applications (including identifying common > sub-expressions, and version tracking in GHC), I'd like a Haskell > library that supports simple fingerprint operations. lots of hash-related links was collected at http://www.encode.ru/forums/index.php?action=vthread&forum=1&topic=413 -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

Suspected stupid Haskell Question
by Big_Ham 20 Oct '07

20 Oct '07

Is there a library function to take a list of Strings and return a list of ints showing how many times each String occurs in the list. So for example: ["egg", "egg", "cheese"] would return [2,1] I couldn't find anything on a search, or anything in the librarys. Thanks BH. -- View this message in context: http://www.nabble.com/Suspected-stupid-Haskell-Question-tf4639170.html#a132… Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

12 19

Re: [Haskell-cafe] Polymorphic (typeclass) values in a list?
by TJ 20 Oct '07

20 Oct '07

Henning Thielemann: > > class Renderable a where > > render :: a -> RasterImage > > > > scene :: Renderable a => [a] > > This signature is valid, but it means that all list elements must be of > the same Renderable type. Yes, that's exactly the restriction I'm unhappy about. > You could let the user plug together the alternatives for Renderable. That > is, declare the class Renderable and let the user define and instantiate > > data Figure > = Point Something > | Line Something > | Polygon Something But if I already have the types Point, Line, and Polygon, and I want to create a "union type" Figure as above, then my code will look like this: data Point = Point Something data Line = Line Something data Polygon = Polygon Something data Figure = FPoint Point | FLine Line | FPolygon Polygon aFigure = FPoint Point Something aListOfFigures = [FPoint Point Something, FPolygon Polygon Something, FLine Line Something] > > Is there a way of achieving what I want to do? Existentials maybe? I'm > > still learning the basic stuff and don't grok existentials at all, but > > I even if I use those, I'll still have to wrap things up in a > > constructor, won't I? > > I assume, that you could use > http://www.haskell.org/ghc/docs/latest/html/users_guide/type-extensions.htm… That's a nice page :) From a quick reading, the best I came up with was this: data R = forall a. Renderable a => V a instance Show R where render (R a) = render a Which is precisely what I meant when I said that I'd still have to wrap things up in a constructor. Is this hidden type variable thing what "existential types" mean? OT: forall just introduces a new type variable, right? Thanks, TJ

3 2

Do you trust Wikipedia?
by PR Stanley 19 Oct '07

19 Oct '07

Hi Do you trust mathematical materials on Wikipedia? Paul

22 31

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

19 Oct '07

Udo Stenzel wrote: > Simon Marlow wrote: >> So a package that depends on 'base' (with no upper version bound) *might* >> be broken in GHC 6.8.1, depending on which modules from base it actually >> uses. Let's look at the other options: >> >> - if we rename base, the package will *definitely* be broken >> >> - if the package specified an upper bound on its base dependency, it will >> *definitely* be broken > > - if you provide a 'base' configuration that pulls in the stuff that > used to be in base, the package will work I don't know of a way to do that. The name of the package is baked into the object files at compile time, so you can't use the same compiled module in more than one package. > I hate betting, but I'd like to know if... > > - it is okay to give GHC 6.4/6.6 a castrated configuration of the base > libraries to remove the conflict with recent ByteString? Sure, that's what I suggested before. Moving modules of an existing package from 'exposed-modules' to 'hidden-modules' is safe (I wouldn't recommend removing them entirely). > - when GHC 6.8 comes out containing base-3, will it be possible to > additionally install something calling base-2 with both being > available to packages? In theory yes - the system was designed to allow this. In practice we've never tried it, and base-2 might not compile unmodified with GHC 6.8. > - If so, will existing Cabal packages automatically pick up the > compatible base-2 despite base-3 being available? Only if they specify an upper bound on the base dependency, which most don't, but it's an easy change to make. Cheers, Simon

17 54

Re: [Haskell] Announce: generating free theorems, online and offline
by ajb＠spamcop.net 19 Oct '07

19 Oct '07

[Ccing to haskell-cafe; please direct any replies there instead of haskell] G'day all. First of all, once again well done to Sascha on a great tool. Just a few comments. Quoting Janis Voigtlaender <voigt(a)tcs.inf.tu-dresden.de>: > - support for type classes > (e.g., enter "elem" and note the generated respects-restrictions) This is a great feature, and it'll be even better when constructor classes are done. Some of these respects-restrictions arent as useful as they might be, because they don't take into account easily-predictable invariants. For example, the type: (Eq a) => [a] -> [a] generates the following restriction: g respects Eq if forall x :: t1. forall y :: t1. (==) x y = (==) (g x) (g y) forall x :: t1. forall y :: t1. (/=) x y = (/=) (g x) (g y) Thats correct, but redundant, because (x == y) = (g x == g y) if and only if (x /= y) = (g x /= g y). Crucially, you can work this out from the definition of Eq, because (/=) has a default implementation defined in terms of (==) alone. The type (Monoid a) => [a] -> a gives: forall t1,t2 in TYPES(Monoid), g :: t1 -> t2, g respects Monoid. forall x :: [t1]. g (f x) = f (map g x) The class restriction occurring therein is defined as follows: g respects Monoid if g mempty = mempty forall x :: t1. forall y :: t1. g (mappend x y) = mappend (g x) (g y) forall (x, y) in lift{[]}(g). g (mconcat x) = mconcat y Again, mconcat is redundant. Even more curiously, though, map appears in the theorem, but lift{[]} appears in the class restriction. Cheers, Andrew Bromage

8 21

Re: [Haskell] ANNOUNCE: Lazy SmallCheck 0.1
by Janis Voigtlaender 19 Oct '07

19 Oct '07

That's pretty cool. If you are not yet aware of it, you might want to compare this with the EasyCheck library for Curry. They directly use functional logic programming for test generation, where you use exceptions for simulating logical variables. Here are some slides of a talk I heard recently: http://www.informatik.uni-kiel.de/~jac/data/DarkSecret.pdf (in German, unfortunately) Matthew Naylor wrote: > Announcing Lazy SmallCheck 0.1, a library for exhaustive, > demand-driven testing of Haskell programs. > > Lazy SmallCheck is based on the idea that if a property holds for a > partially-defined input then it must also hold for all fully-defined > instantiations of that input. Compared to `eager' input generation > in SmallCheck, Lazy SmallCheck may require significantly fewer > test-cases to verify a property for all inputs up to a given depth. > > There is a webpage for Lazy SmallCheck: > > http://www-users.cs.york.ac.uk/~mfn/lazysmallcheck/ > > There you'll find a more detailed description, a worked example, a > comparison with SmallCheck on a number of benchmarks, and link to > download the library. > > The library was developed together with Fredrik Lindblad during his > recent visits to York. > > Suggestions, experiences and bug reports are welcome! > > Matthew. > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell > -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:voigt@tcs.inf.tu-dresden.de

1 0

data Bin = Zero | One
by PR Stanley 19 Oct '07

19 Oct '07

>Hi >data Bin = Zero | One As suggested by someone on this list. It's a really neat idea although I'm wondering how I can apply this to my int to binary function. The Zero or One declaration is saying that Bin is a data type that can hold either a one or a zero. I tried testing this with a very simple Bin -> Bin function and the Integral values 0 and 1 but ran into difficulties. Any ideas what I'm doing wrong here? Incidentally, does the general syntax above come from the old BNF notation? Cheers, Paul

2 1

Functional specification of DFS
by Vimal 19 Oct '07

19 Oct '07

Hello Haskellers, Yesterday, my professor had asked this question in a quiz: "Give a functional description of Depth First Search on a graph G. Use lisp." The first thing I wrote was: Let DFS(G, root) return the list of edges in the dfs spanning tree of G, rooted at root. Let n = |V| in: :) The naive algorithm of keeping a visited 'array' and recursive solution is what came to my mind. But, if we look at DFS as a mapping from G -> List of Spanning trees of G rooted at root, then we have an exponential (n**(n-2) ?) number of them, so, finding the one that satistifies the properties of a DFS spanning tree, might not be tractable. So, if we modify the specification of DFS(G, root) as DFS(G, root, intermediate_path), we get: DFS(G, root, path) = Union ( {(root, v)} U DFS(G, v, path U {root})) ) for all v not in path, and (root, v) exists in G. DFS is invoked as: DFS(G, root, {root}) The problem with this is that changes to "path" must be persistant across calls. i.e., {(root, v)} U DFS(G, v, {v, root} + recursive calls} U {(root, w)} U DFS(G, v, {v, root}, + nodes added in recursive calls}) etc. So, the question is: Is it possible to have a purely functional and tractable description of DFS? I did a Google on "Haskell DFS", and landed up with a paper [1], that also says that Graph Algorithms have been difficult to implement in a purely functional style. They use mutable arrays to achieve the same. I am getting a small idea using foldls and Monads to achieve this. Since, we have to take the return value of the previous instance of the function call, and then pass it on to the next. dfs initial_visited_list >>= \spanning_tree -> dfs (merge spanning_tree initial_visited) >>= \spanning_tree -> etc... I will try to write it down on paper and see if it works out. References: [1]: www.cse.ogi.edu/~jl/Papers/dfs.ps Do you have any thoughts on this? Thanks, -- ~Vimal RLE :) encode = map (length &&& head) . group decode = concatMap (uncurry replicate)

2 3

Tutorial: Curry-Howard Correspondence
by Tim Newsham 19 Oct '07

19 Oct '07

A tutorial on the Curry-Howard Correspondence in Haskell: http://www.thenewsh.com/%7Enewsham/formal/curryhoward/ Feedback appreciated. Tim Newsham http://www.thenewsh.com/~newsham/

14 27

Re: [Haskell-cafe] On the verge of ... giving up!
by Andrew Coppin 19 Oct '07

19 Oct '07

Steven Fodstad wrote: > > FWIW, other people feel about Haskell the way you feel about calculus > and the continuation monad, and your opinions of these other powerful, > but difficult, tools is what got you into this mess. On the contrary, other people's misinterpretation of my opinions on these matters is what got me into this mess. I could go into a lengthy explanation, but I'll probably just be misunderstood again. So let's leave it here. > academics don't like hearing that their life's work is useless. > Being positively surrounded by people who think Haskell is pointless, I certainly have I fair idea how that feels...

1 0

Bug in runInteractiveProcess?
by John Goerzen 18 Oct '07

18 Oct '07

Hi everyone, I have been trying to implement a Haskell-like version of shell pipelines using runInteractiveProcess. I am essentially using hGetContents to grab the output from one command, and passing that to (forkIO $ hPutStr) to write to the next. Slow, but this is just an experiment. This works OK to link together two external commands, but deadlocks when linking together three processes. After staring at straces all afternoon, I think I have found the culprit. I observed that when I have three commands linked together, the second never sees EOF on its input. This even though I saw an explicit close on the other end of the pipe from the Haskell side. Why is this, I wondered? I stared at the source for the C runInteractiveProcess function for a bit, but then the answer was right there: this function does not sanitize FDs. What that means is that the write end of the stdin pipe for command 2 was open in the Haskell process. The Haskell process then forked off for command 3 later on. This write end of the stdin pipe for command 2 was never closed in the command 3 child environment. Therefore, closing it in the Haskell thread did not cause command 2 to get an EOF. Does that make sense? Many systems will just try to close *all* FDs except the ones they need after a fork(). Another approach would be to maintain a global list of FDs that the Haskell thread is using, and close all of them except the pipe ends in the child. Without something like this, it is not possible to use runInteractiveProcess more than twice simultaneously in a single program. That renders it almost useless for some tasks. Does this make sense to everyone? If so, I'll submit the bug on GHC. -- John

7 18

Re: [Haskell-cafe] Tutorial: Curry-Howard Correspondence
by Dan Weston 18 Oct '07

18 Oct '07

_|_ does not provide a witness to a theorem in any consistent logic (otherwise everything could be proved from it), yet it inhabits every type in Haskell. If the only invalid type instance is _|_, then a necessary and sufficient test for the C-H correspondence be the existence of a type instance that halts. Non-strict constructors would seem to mess that up. From http://en.wikipedia.org/wiki/Curry%E2%80%93Howard#Types "The problem of finding a ?-expression with a particular type is called the type inhabitation problem. The answer turns out to be remarkable: There is a closed ?-expression with a particular type only if the type corresponds to a theorem of logic, when the ? symbols are re-interpreted as meaning logical implication." By inhabit, they clearly mean no occurrence (recursively) in the type instance of _|_. I think the extra wrinkle you are introducing with constructors like Prop to wrap types is justified only insofar as the boxed and unboxed types are isomorphic, but they are not unless the constructor is strict in all its arguments. Just as _|_ :: a does not qualify as justifying theorem a, so in isomorphism Prop _|_ :: Prop a should also not qualify. If all constructors were strict, Prop _|_ = _|_ and all is fine. I am posting this to the haskell-cafe list because I am not at all sure that my understanding is right, and I don't want you to change your tutorial if it's not. Dan Weston Tim Newsham wrote: >> Also, I was wondering if the constructor and/or function arguments >> should be marked strict. >> >> Otherwise, types can be inhabited by defined arguments. Since Prop is >> not strict in its argument, we could have the (false) theorem >> >> andAlwaysTrue :: forall p q . p :/\ q >> andAlwaysTrue p q = And (Prop undefined) (Prop undefined) >> >> This halts for all p and q since Prop and And are not strict. > > Hmm.. I'm wondering to what degree this would make a difference. > I'm not actually running any of these programs. I'm just compiling > them and relying on the type checker to validate the types (and > check the proofs). If I understand this correctly, adding "!" > wont affect the behavior of the type checking phase. > >> Dan Weston wrote: >>> That is a great tutorial. Thanks! But in the last two sentences of >>> the introduction you say: >>> >>> > We just need to find any program with the given type. >>> > The existence of a program for the type will be a proof >>> > of the corresponding proposition! >>> >>> Maybe you should make explicit that >>> >>> 1) the type is inhabited >>> >>> undefined :: forall p . p >>> >>> does not prove that all propositions are true >>> >>> 2) the function must halt for all defined arguments >>> >>> fix :: forall p . (p -> p) -> p >>> fix f = let x = f x in x >>> >>> does not prove the (false) theorem >>> >>> (p => p) => p >>> >>> even though (fix id) is well-typed and id is certainly not undefined >>> (though fix id is). >>> >>> Tim Newsham wrote: >>>> A tutorial on the Curry-Howard Correspondence in Haskell: >>>> http://www.thenewsh.com/%7Enewsham/formal/curryhoward/ >>>> >>>> Feedback appreciated. >>>> >>>> Tim Newsham >>>> http://www.thenewsh.com/~newsham/ >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe(a)haskell.org >>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>>> >>>> >>> >>> >> >> > > Tim Newsham > http://www.thenewsh.com/~newsham/ > >

2 1

ANNOUNCE: xmonad 0.4
by Don Stewart 18 Oct '07

18 Oct '07

The xmonad dev team is pleased to announce the 0.4 release of xmonad! http://xmonad.org xmonad is a tiling window manager for X. Windows are arranged automatically to tile the screen without gaps or overlap, maximising screen use. Window manager features are accessible from the keyboard: a mouse is optional. xmonad is written, configured and extensible in Haskell. Custom layout algorithms, key bindings and other extensions may be written by the user in Haskell, in config files. Window layouts are applied dynamically, and different layouts may be used on each workspace. Xinerama is fully supported, allowing windows to be tiled across several physical screens. Features: * Simple, intuitive user interface * Stable, fast and small memory footprint * Automatic window tiling and management * First class keyboard support: a mouse is unnecessary * Full support for tiling windows on multi-head displays * Full support for floating windows * XRandR support to rotate, add or remove monitors dynamically * Per-workspace layout algorithms * Per-screens custom status bars * Easy, powerful customisation and reconfiguration * Large extension library * Extensive documentation and support for hacking This is a big release, with every feature we originally proposed for xmonad implemented. Since xmonad 0.3, the following notable improvments have appeared: * Powerful "rules" system: config files may specify rules about how particular applications are handled. For example, gimp might always be placed in the floating layer, or firefox always placed on workspace 2. Gnome dock apps (such as kicker or gnome-panel) might always be placed in a status bar gap and unmanaged. * User-specified workspace tag types (not restricted to numeric keys). E.g. "web" or "www" are valid workspace tags now. * Layouts algorithms serialisable. Current workspace state preserved across restarts/reconfiguration, including user-written modules' state * User written code sandboxed from the core applicuation further, making it safer to experiment with new extensions * 100% code coverage of logic core of xmonad by its testsuite, thanks to QuickCheck and HPC. * More hooks to make writing expressive extensions easier * mod-m to shift focus to the `master' window * many new binary distributions, for various flavours of Linux and BSD, OSX is also well supported. * extensions: xmonad comes with a huge library of extensions (3 times the size of xmonad itself), contributed by viewers like you. Extensions enable pretty much arbitrary window manager behaviour to be implemented by users, in Haskell, in the config files. For more information on using and writing extensions, see the webpage. Get it! More information, screenshots, documentation, tutorials and community resources are available from the xmonad home page: http://xmonad.org The 0.4 release, and its dependencies, are available from hackage.haskell.org, here: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xmonad Brought to you by the xmonad team: Spencer Janssen Don Stewart Jason Creighton Andrea Rossato David Roundy with code contributions from: Brandon Allbery Chris Mears Shachaf Ben-Kiki Eric Mertens Alec Berryman Neil Mitchell Gwern Branwen Devin Mullins Joachim Breitner Daniel Neri Alexandre Buisse Stefan O'Rear Nick Burlett Simon Peyton Jones Peter De Wachter Hans Philipp Annen Aaron Denney Karsten Schoelzel Nelson Elhage Michael Sloan Shae Erisson Ivan Tarasov Joachim Fasting Alex Tarkovsky Michael Fellinger Christian Thiemann David Glasser Joe Thornber Kai Grossjohann Matsuyama Tomohiro Dave Harrison Daniel Wagner Juraj Hercek Ferenc Wagner Sam Hughes Jamie Webb Miikka Koskinen Brent Yorgey David Lazar nornagon Lucas Mai timthelion Robert Marlow Klaus Weidner As well as the support of a cast of hundreds on the #xmonad and #haskell IRC channels, and the wider Haskell, FP and window manager communities. Thanks to everyone for their support!

2 2

Stack overflow in ghci
by Maurício 18 Oct '07

18 Oct '07

Hi, I get this error message when testing a function in ghci: *** Exception: stack overflow I admit I didn't care about efficiency when I wrote that function, but I'm almost sure it is not supposed to eat all my memory. Do I need to say something to ghci if I want it to use all available memory? Thanks, Maurício

3 2

Functional Programming Books
by Dan Piponi 18 Oct '07

18 Oct '07

I was just putting together my Amazon wish list and was wondering if there are any great books on Haskell and/or functional programming that people think are must-reads. Okasaki's "Purely Functional Programming", Pierce's "Types and Programming Languages" are frequent recommendations. Smullyan's "To Mock a Mockingbird" seems like it might be a good example from the lighter end. Are there any other classics I should know about?

5 4

generic programming tutorial?
by Greg Meredith 18 Oct '07

18 Oct '07

Haskellians, i feel like i'm chasing a rabbit down the rabbit hole, but here goes. i'm currently redoing my implementation of an evaluator for a reflective process calculus, using Haskell instead of OCaml, this time. i thought i'd give a James Cheney's FreshLib a whirl to - test out the state of the nominal machinery in Haskell - see if the nominal stuff works, practically, with my reflective account of nominal machinery i've discovered that FreshLib makes essential use of a early version of generic Haskell features. i need to bone up on generic Haskell, quickly. i've got the papers. i need to see what's being released and supported in the mainstream Haskell codebase. Is there documentation for this, or should i grovel source? 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

1 0

Re: [Haskell-cafe] Suspected stupid Haskell Question
by manu 17 Oct '07

17 Oct '07

> The problem there is that nub is O(n^2). Is there a place where one can look up the complexity of Standard Libraries functions ? E.D

2 1

Performance problem with random numbers
by ntupel 17 Oct '07

17 Oct '07

Dear all, I have implemented a small module to generate random items with a given probability distribution using the alias approach [1] and unfortunately compared to similar implementations in C++ or Java it is about 10 times slower. I have to confess that I am still in the early stages of writing Haskell programs so there is hopefully something I can do about it and I hope some helpful soul on this list can give me a hint. I have attached my implementation and a small testing routine which runs in about 5 seconds on my machine (when compiled with -O2) whereas my Java-Implementation finishes in about 0.48 seconds. Profiling indicates that the time is mostly spend in System.Random.random and System.Random.randomR so I wonder if these are slow or what else might cause the relative slowness of my implementation. Many thanks for your responses, Thoralf PS: I would also appreciate any feedback about the module from a design perspective. I bet I miss lots of good Haskell idioms. ---------------- [1] The alias methods moves probability mass of a non-uniform probability distribution around to create a uniform distribution. Lets say you have three items "a", "b", and "c" with distribution [0.2, 0.1, 0.7] then a uniform distribution would assign 1/3 to each so "a" and "b" need to be "filled up" with exactly the same probability mass that "c" has too much. Then 2 uniform random numbers are generated. The first one to pick an item and the second one to pick either the item itself if the value is in the original part or the alias otherwise. A much better explanation can be found on the web somewhere. Anyway it should not matter with regards to the performance problem I have.

10 24

OzHaskell?!?
by Manuel M T Chakravarty 17 Oct '07

17 Oct '07

There is AngloHaskell and now AmeroHaskell. Doesn't that call for OzHaskell? http://haskell.org/haskellwiki/OzHaskell Manuel

2 2

job opportunity
by jeff p 17 Oct '07

17 Oct '07

Hello, Here are the essential details... Location: NYC Industry: finance Salary: enough to live comfortably in Manhattan Hard Requirements: Must be able to work in the USA (we can't get you a worker's visa). Must be an expert level Haskell user; must be comfortable with monads, monad transformers, type level programming (i.e. MPTC, overlapping and undecidable instances), and lazy evaluation (i.e. know how to find and eliminate space leaks). Must have a desire to use modern PL research in the real world. Soft Requirements: Experience with low-level Haskell programming (i.e. FFI). Experience with Linux and Cygwin/Windows. Knowledge/experience in dependently typed programming. Knowledge/experience in logic programming. If anyone is interested, please contact me to find out more. thanks, Jeff

1 0

Re: [Haskell] IN Doubt...
by ajb＠spamcop.net 17 Oct '07

17 Oct '07

[Moved to haskell-cafe] G'day all. Quoting Don Stewart <dons(a)galois.com>: > You can't pattern match 'a' and 'a' like that -- there's no implicit > unification. Since we're being nostalgic in other threads, this is #1 on my list of things I miss from Miranda. It's also high on my "things that are damned useful in 1000-line programs but would wreak silent havoc in large applications" list. Cheers, Andrew Bromage

1 0

Help parsing dates and times
by Justin Bailey 17 Oct '07

17 Oct '07

I am trying to parse various date and time formats using the parseTime function found in (GHC 6.6.1) Data.Time.Format. The one that is giving me trouble looks like this: 2008-06-26T11:00:00.000-07:00 Specifically, the time zone offset isn't covered by the format parameters given. I can almost parse it with this: %FT%X.000 But that doesn't take into account the "-07:00" bit. I'm sure this has been solved - can someone point me to the solution? Thanks in advance. Justin

5 9

Equality Question
by PR Stanley 17 Oct '07

17 Oct '07

Hi is const = id? const 'x' 'y' 'x' id 'x' 'x' Cheers, Paul

5 5

System.Posix
by Galchin Vasili 17 Oct '07

17 Oct '07

Hello, In a Hugs environment, I am able to import System.Directory but not to import System.Posix. Here is my environment ... .;{Hugs}\packages\*;C:\ftp\CatTheory\Haskell\SOE\graphics\lib\win32\*. I really want to use the Posix module. Help!!! Kind regards, Bill Halchin

2 4

Distributed haskell using Hadoop
by Brad Clow 17 Oct '07

17 Oct '07

I was looking around for a haskell solution for distributing a computation across multiple machines and couldn't find anything that looked current and alive. I found out that the Hadoop project (java based) can interact with binary executables via stdin and stdout. So I have set up a Hadoop cluster of 5 machines, wrapped my Haskell code to accept data via stdin and write results to stdout and successfully executed it on the cluster. I would prefer a more Haskell orientated solution and welcome any suggestions. If not maybe this will be of use to others. Regards brad

3 2

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

16 Oct '07

Claus Reinke wrote: > but calling "split-base" "base" goes directly against all basic > assumptions of all packages depending on "base". The new base will have a new version number. There is no expectation of compatibility when the major version is bumped; but we do have an informal convention that minor version bumps only add functionality, and sub-minor version bumps don't change the API at all. So a package that depends on 'base' (with no upper version bound) *might* be broken in GHC 6.8.1, depending on which modules from base it actually uses. Let's look at the other options: - if we rename base, the package will *definitely* be broken - if the package specified an upper bound on its base dependency, it will *definitely* be broken In the design we've chosen, some packages continue to work without change. Specifying a dependency on a package without giving an explicit version range is a bet: sometimes it wins, sometimes it doesn't. The nice thing is that we have most of our packages in one place, so we can easily test which ones are broken and notify the maintainers and/or fix them. Another reason not to change the name of 'base' is that there would be a significant cost to doing so: the name is everywhere, not just in the source code of GHC and its tools, but wiki pages, documentation, and so on. Yes I know we've changed other names - very little in packaging is clear-cut. Cheers, Simon

8 17

Re: [Haskell-cafe] ANNOUNCE: metaplug
by Axel Mannhardt 16 Oct '07

16 Oct '07

Hello, There is one limitation to this, however. compileCall expects to compile a > dynamic via GHC.dynCompileExpr; > what this means is your resource must be monomorphic (for Typeable to > work.) As of right now, the easiest > way I can see to get around this is to simply define a datatype like such: > > data Plugin { > rsrc :: ... -- your type here > } deriving Typeable I have the same problem, although from a different direction. I am only interested in an eval-myDynamicFunction functionality not general modules, so I did it on a per function basis, using hs-plugins eval. A typeable data wrapper would be fine for me, although I have not yet found a non-ugly way to import needed modules for the plugin, as the plugin source would not be necessarily in the same place as the API. But thats rather an implementation detail. The real problem is, that I do not know, if there is an appropriate way to represent functions with a dynamic parameter count. As of now, I think it would need a bigger amount of hacking than it is worth to get rid of the workarounds I already have, but it would be interesting anyway. > (unsafeCoerce# is an option but there's not a version > of compileCall to support this as of right now. I might add it if it seems > needed.) > As I am relatively new, and since I have not found any introduction what unsafeCoerce is actually capable of (and how), I have ignored this possibility. Could someone give me some pointers? (the most useful thing I found is http://osdir.com/ml/lang.haskell.glasgow.bugs/2005-03/msg00048.html ) The approach I stopped working at was: type TestSpecs = (String, String, String) data FunctionTest = forall a b . (Show a, Show b, Eq b) => FunctionTest (String , [a], (a ->b), [b]) deriving Typeable readFunctionTest :: TestSpecs -> IO (Either [String] (Maybe FunctionTest)) readFunctionTest ( params,fn,predicted) = eval_ str ["FunctionTest"] ["-i"++libDir] [] [libDir] where str = "FunctionTest("++show fn++", "++params++", " ++fn++", "++predicted++")" applyFunctionTest :: FunctionTest -> [Bool ] applyFunctionTest (FunctionTest (_ ,parameters,function,predicted) ) = zipWith (==) (map function parameters) predicted ..what works for general Functions with one Parameter. The wrapper ensures that the function takes one value to produce another value comparable to the other given value. So far, this looks ok to me, I can 'read' a function once and apply it to multiple tests. However, if the function has more than one curried parameter, it has to be extended. I see the following approaches: -Do everything inside the eval (returning a [Bool] for example). That works, and I use it right now, but apart from being ugly, the function has to be read more than once. This might be a non-practical issue though. -Introduce constructors for each parameter count (up to a limit). FunctionTest2 (String, [(a,a')], (a->a'-> b), [b]) applyFunctionTest (FunctionTest2 ...{-this might be generalizeable-} That is a lot more redundant and not as general as the inside-eval approach, but the function has to be read only once. -Convert any functions into ones that take one list/tuple parameter within the eval (assume there is no type ambiguity for simplicity). Partial application is not the goal here anyway and information about the parameter count could be obtained from the "parameter"-parameter or from additional information in the function String itself. But for that a wrapper has to be added to the code inside eval that turns a function with unknown parameter count into the one actually exported. The type of this transformer function could be distinguished at eval compile time, but that means the implementation would have to be included in each eval... uncurry3 fn (a, b, c) = fn a b c uncurryN = --would be defined using template Haskell or recursive data structures or something else I do not know yet --simpler as a list uncurryL fn [] = fn uncurryL fn (x:xs) = uncurryL (fn (fromValue x)) xs -- but then the values would have to be wrapped for type ambiguity: data Value = IntV Int | ... I had a look on some techniques to deal with dynamic parameter count, but they are either decided at runtime (as my understanding of QuickCheck and its recursive data types is) or they do not represent functions with unknown parameter count but only process one at a time (as Printf does). Tell me if I am wrong. So, I end up with three possibilities how to do the job (although I have not tried to implement all of them), but I am unhappy with each. How would one express a type "a->...->b" in Haskell (GHC)? Are you able to express the second approach without the redundant FunctionTestN definitions? I am willing to do ugly things, as long as I can restrict the effects to that particular place. Thanks, Axel

1 0

Of phantom types and type extentions
by Thomas M. DuBuisson 16 Oct '07

16 Oct '07

All, I've been casually developing a PacketBB (i.e. Generalized Manet Packet Format) library in Haskell. I think I have a need to pass state information as a phantom type - I'll step through the issue now. With the 'AddressBlock' (S5.2.1 packetBB draft 8), network addresses are abbreviated as sets of bytes (potentially just one byte each, with a head or tail identical with other addresses). How many bytes are in the set is determined, in part, by the type of address stored (ex: IPv4 or IPv6). Thus, when serializing, I need to provide this information. Saying this again, but in (simplified) code: data NetworkAddress a => AddressBlock a = AddrBlkWire { lenHd :: Word8, hd :: [Word8], lenTl :: Word8, tl :: [Word8], nrAddrs :: Word8, addrs :: [Word8] } | AddrBlkAbstract [a] data (NetworkAddress a) => SomeHigherLevelStruct a = SHLS (AddressBlock a) Word32 Word8 -- length (addrs x) == ("TotalAddressLength" - lenHd - lenTl) * nrAddrs I can think of several ways to convert between AddrBlkWire and ByteStrings: 1) Make separate instance of 'Binary' for each data type element of NetworkAddress. instance Binary (AddressBlock IPv4) where get = ... put = ... instance Binary (AddressBlock IPv6) where get = ... put = ... This solution immediately causes problems with every higher level structure you wish to serialize. For example, now you have to have individual instance for SHLS, you can't do: instance (NetworkAddress a) => Binary (SomeHigherLevelStruct a) where ... 2) You can pass another argument into a custom 'get' routine. I see this as a hack that makes me break a good naming convention. getNetworkAddress :: Int -- bytes per address -> Get NetworkAddress 3) If you don't worry about decoding, only encoding, then an extra field in the data structure can fill the void of an extra argument. Also a hack. I'm hoping someone here has a better solution. Perhaps I am making a mountain out of a mole hill, or perhaps this requires one of those type system extensions I have yet to look hard at. The solution I would want looks like this: class NetworkAddress a where addressByteSize :: a -> Int instance (NetworkAddress a) => Binary (AddressBlock a) where get = do lenH <- get h <- replicateM get (fromIntegral lenH) lenT <- get t <- replicateM get (fromIntegral lenT) nr <- get let addrSize = addressByteSize (undefined :: a) bytes = (addrSize - lenH - lenT) * nr addrs <- replicateM get (fromIntegral bytes) return ... The line 'addrSize = ' is what I don't know how to write. How does one call an instance of a type class without knowing the type at compile time? Thanks, Tom -- "The philosophy behind your actions should never change, on the other hand, the practicality of them is never constant." - Thomas Main DuBuisson

2 1

Re: [Haskell-cafe] do
by Peter Verswyvelen 16 Oct '07

16 Oct '07

jerzy.karczmarczuk(a)info.unicaen.fr wrote: >> Yes, *different approach*. So, there *are* differences. Compilers, >> anyway, >> are special applications. I wanted to see - responding to Brandon - a >> "normal" Haskell program, which does IO without monads, that't all. >> The problem is then when you hide something, you hide. It is possible to >> superpose a kind of monadic framework on unique worlds, files, etc. in >> Clean, but the reverse operation goes beyond my horizons. >> Some examples, anybody? >> Jerzy Karczmarczuk Ah yes, I see what you mean now. I have no idea, I guess only unsafePerformIO will allow you to do something like that... But that will completely break referential transparency. But I really don't know. What do the experts have to say?

4 7

Pixel plotter
by Andrew Coppin 16 Oct '07

16 Oct '07

I write a lot of programs that build bitmapped images. (Some of you may remember the Chaos Pendulum Simulator...) Currently, all of these programs work by writing the final image data to a PPM file on disk. (Because that's the only way I can figure out to do something *useful* with the data!) What I'd *like* to be able to do, in priority order: 1. Display images on the screen. 2. Save images as PNG files. (PPM eats too much space!) 3. Animate images on the screen. 4. With double-buffering. 5. Not break horribly when rendering in multiple threads. As far as I know, all of this is *possible* with Gtk2hs right now - it's just vastly more complex than making a single function call. So what I'd like to do is write a small library which will enable me to do each of the above tasks in 1 function call. However, I'm getting nowhere fast with this. Anybody have any suggestions? PS. I've investigated existing APIs and I'm not seeing anything that looks useful. Lots of support for drawing lines and arcs and so on, but not for plotting individual pixels.

8 9

Re: [Haskell-cafe] do
by jerzy.karczmarczuk＠info.unicaen.fr 16 Oct '07

16 Oct '07

Peter Verswyvelen writes about non-monadic IO, unique "external worlds": > But... isn't this what the Haskell compiler & runtime do internally when > IO monads are executed? Passing the RealWorld "singleton" from "action" to > "action"? I never looked into any Haskell compiler. Chalmers, or York, don't remember, used continuations, this seems a bit different from the Clean approach, but I don't really know the gory details. > To me, no real > difference exists between IO monads and Clean's uniques types; it's just a > different approach to tackle the same problem. Yes, *different approach*. So, there *are* differences. Compilers, anyway, are special applications. I wanted to see - responding to Brandon - a "normal" Haskell program, which does IO without monads, that't all. The problem is then when you hide something, you hide. It is possible to superpose a kind of monadic framework on unique worlds, files, etc. in Clean, but the reverse operation goes beyond my horizons. Some examples, anybody? Jerzy Karczmarczuk

2 1

ANNOUNCE: Haskell Selenium bindings, version 0.2.1
by Aaron Tomb 16 Oct '07

16 Oct '07

Hi, I'm pleased to announce the first external release of a set of Haskell bindings for the Selenium automated web testing system (specifically, the Selenium Remote Control). These bindings make it possible to use Haskell to write test scripts that automatically exercise arbitrary web sites by controlling a web browser. More information on Selenium is available here: http://www.openqa.org/ You can get the tagged release from Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ selenium-0.2.1 Or you can keep up with the development version from darcs (which currently has no changes from 0.2.1): darcs get http://code.haskell.org/selenium Many thanks to Don Stewart for code and design contributions. Aaron

1 0

Re: [Haskell-cafe] do
by PR Stanley 16 Oct '07

16 Oct '07

Thanks for the very clear explanation. More questions: What is the role of ">>"? How is ">>" different to ">>="? I am aware that ">>=" is used for sequencing parsers but that's all I know about it. Thanks, Paul At 22:28 13/10/2007, you wrote: >On 10/13/07, PR Stanley <prstanley(a)ntlworld.com> wrote: > > Hi > > "do", what's its role? > > I know a few uses for it but can't quite understand the semantics - > > e.g. do putStrLn "bla bla" > > So, what does do, do? > >In this example, do doesn't do anything. do doesn't do anything to a >single expression (well, I think it enforces that its return value is >a monad...). It's only when you give it multiple expressions that it >"rewrites" them into more formal notation. For example: > > do putStrLn "bla" > putStrLn "blah" > >Will be rewritten into: > > putStrLn "bla" >> putStrLn "blah" > >It introduces a block of "sequential actions" (in a monad), to do each >action one after another. Both of these (since they're equivalent) >mean print "bla" *and then* print "blah". > >do also allows a more imperative-feeling variable binding: > > do line <- getLine > putStr "You said: " > putStrLn line > >Will be rewritten into: > > getLine >>= (\line -> putStr "You said: " >> putStrLn line) > >Looking at the do notation again: execute getLine and bind the return >value to the (newly introduced) variable 'line', then print "You said: >", then print the value in the variable line. > >You can think of the last line in the block as the return value of the >block. So you can do something like: > > do line <- do putStr "Say something: " > getLine > putStr "You said: " > putStrLn line > >In this example it's kind of silly, but there are cases where this is useful. > >Luke

9 17

Hosting of Haskell project
by Magnus Therning 15 Oct '07

15 Oct '07

I recently had reason to do some encoding-related coding and noticed that Haskell was somewhat lacking (I could only find code for base64, on the other hand there are two implementations of it :-). I've almost reached a state where I wouldn't be ashamed of sharing the code so I looked into my options of free hosting. It seems I only have one option for publishing the code: - Request a project on code.haskell.org. I could only find one option for a "homepage" for the project: - Create a page on the Wiki. There seems to be no option when it comes to tracking bugs. :-( I could also not locate any option for publishing haddock pages. :-( Have I missed anything? /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus．therning＠gmail．com http://therning.org/magnus The British have "the perfect temperament to be hackers--technically skilled, slightly disrespectful of authority, and just a touch of criminal behavior". -- Mary Ann Davidson, Oracle's Security Chief

8 12