November 2010 - Haskell-Cafe

Compiler constraints in cabal
by Reiner Pope 13 Nov '10

13 Nov '10

Hi, I have a library, hmatrix-static, on Hackage. Version 0.3 (the current version) compiles with ghc-6.12. Let's say I want to upgrade my library using new features in ghc-7.0, and then release these upgrades as version 0.4. Is there any way to state in my cabal file that this new version will no longer compile under ghc-6.12? The reason I would like to state this is so that a user with ghc-6.12 can do 'cabal install hmatrix-static' (or do a cabal install of a program depending on hmatrix-static) and see that cabal will install version 0.3 rather than attempt to install version 0.4 and fail. Thanks for your help. Reiner

7 10

Type-Directed Name Resolution for Records?
by John Smith 13 Nov '10

13 Nov '10

Two significant points which have emerged from the TDNR thread are: -The wiki page combines two orthogonal proposals: type-directed name resolution, which requires no special syntax, and the x.f syntax, which does not require TDNR. -Implementing both proposals may be a desired fix for the record system, but their use in the rest of the language is more controversial. I would therefore like to propose that TDNR (both parts thereof) be implemented for record accessors. In the fullness of time, the community may come to some consensus regarding the implementation of either or both of these features in the rest of the language.

1 0

xml packages
by Permjacov Evgeniy 13 Nov '10

13 Nov '10

First question. As I saw in sources, both hxt and haxml uses [Char]'s. this is very inefficient. I want to know, does any effective parser for haskell, written in haskell, exists. Efficient means using ByteString to store strings and possibly building representations that shares one string for all similiary named elements. If there is no, is anyone interested in writing one? Second question. I'd like to have a package for read-write-edit SVG graphics. I think, xslt (both transformations and formatting object) are interesting too. Is anyone considering writing such packages?

4 3

a problem about Regex in Real World Haskell
by wolf python london 13 Nov '10

13 Nov '10

hi ,folks , I'm a newbie of haskell and learn haskell using the textbook "Real World Haskell". in the page 201, ghci> "good food" =~ ".ood" :: [String] my output is here https://gist.github.com/675024 it doesn't match what the textbook gives . And I found the ebook of Real World Haskell doesn't match it ,either(just like my output ) . I was wondering How I can fix this problem about Regex. much thanks ~ -- ________________________ wolf python london(WPL) Do as you soul should do ! ________________________

2 2

HUnit Control.Exception assertFailure?
by Mark Spezzano 13 Nov '10

13 Nov '10

Hi, I'm trying to follow some examples of HUnit from a webpage. Basically I want my _application_ code to call the "error" function when a certain condition is met (namely when a supplied String to a function is longer than 80 characters). I want my _test_ code to "catch" this error. Unfortunately the example code that I'm following uses the older style of Exception handling. Does anyone know how to catch this exception using the newer Control.Exception module? Basically I want to 1. Call error msg when String length > 80 for some function 2. Catch thrown error from step 1 and do absolutely nothing. (i.e. the "expected failure" was caught) 3. If the error is uncaught (in step 2; for whatever reason) then call "assertFailure somemsg" and my _test_ code should fail since the error it was expecting to occur didn't happen. Thanks, Mark Spezzano

1 0

Type Directed Name Resolution
by John Smith 13 Nov '10

13 Nov '10

Type-directed name resolution, as originally proposed for Haskell', has now been proposed for GHC. Obvious benefits of this are that conflicting function names from imported modules can be used without qualification (verbose) or pseudo-Hungarian renaming (verbose, and requires that you control the source, and perform the same renaming in all dependencies). This is important for both readability and programming in the large, particularly where records are concerned, as the duplicate name problem cannot be alleviated with typeclasses, and it is often desirable to have the same field names for many records in the same module. http://hackage.haskell.org/trac/ghc/ticket/4479 http://hackage.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResoluti…

30 66

Serialization of (a -> b) and IO a
by C. McCann 13 Nov '10

13 Nov '10

Oops, forgot to send this to the list... sorry, Sjoerd. On Thu, Nov 11, 2010 at 11:54 AM, Sjoerd Visscher <sjoerd(a)w3future.com> wrote: >> You would lose many uses of equational reasoning in your programs. Have you >> every substituted 'x * 2' for the expression 'x + x' in one of your programs, >> or vice versa? You can no longer do that, because someone may be serializing >> the function you're writing, checking how it's implemented, and relying it. > > Yes, but it would not break any existing code. It would only break code that knowingly did the wrong thing. Or code that unknowingly depends transitively on code that does the wrong thing. In that regard it would be much like unsafePerformIO, and about as trustworthy. Better off just having any such "serialize" be safely in IO, and let people who want to live dangerously just use unsafePerformIO to get around it. >> We already have a weak case of this, since (\x -> undefined x) can be >> distinguished from undefined using seq, but that can be hand-waved away by not >> worrying about bottoms so much. That isn't going to work for serialize. > > Why not? I'd venture that perhaps because seq only behaves differently when one possible outcome is _|_. An unsafe serialize could distinguish between two non-bottom values, which means the sketchy behavior could be free to wreak havoc in code that's not crashing. For instance, assuming serialize can be applied to functions of any type, it would probably be trivial to write a function (isExpr :: a -> Bool) that reports whether an arbitrary term is a primitive value or the result of some expression, which then lets you write a function with type (forall a. a -> a) that is NOT equivalent to id, which could then be passed freely into any other piece of code you like. That sounds like buckets of fun, doesn't it? - C.

6 12

cabal update error
by Daniel Díaz 13 Nov '10

13 Nov '10

Hi all, I just installed the Haskell Platform, and when I try "cabal update", I have the following output: > Downloading the latest package list from hackage.haskell.org > cabal: failed This error does not give me information about what is wrong. Has anyone had this error before? I would appreciate an explanation (or possible explanation), rather than an "update it manually". Thanks in advance. -- Daniel Díaz

3 3

Serialization of (a -> b) and IO a
by Jesse Schalken 12 Nov '10

12 Nov '10

Is it possible to serialize and deserialize a function to/from binary form, perhaps using Data.Binary, for example? What about an IO action? If so, is there a way the serialized representation could be architecture-independent? I have been shown how useful it can be to store functions inside data structures, and while looking at data serialization for the purpose of persistence I wondered "since functions are just values in Haskell, why can't we persist them, too?". To me the idea has interesting implications. For example, an arbitrary program could simply be represented by a serialization of `IO ()`. In fact, you could load any program into memory from a file and use Control.Concurrent.forkIO to run it, and later kill it, giving you the beginnings of an operating environment. If such a serialization is architecture independent then to my understanding you have the beginnings of a virtual machine. You could break your program into pieces and store them in a database and load them when needed, or even pull updates to each piece individually from down the web etc, enabling interesting methods of software distribution. It would make very cool stuff possible. I have had a look at hs-plugins, but it is unclear how to derive a simple pair of functions `(a -> b) -> ByteString` and `ByteString -> Either ParseError (a -> b)`, for example, from the functionality it provides, if it is possible at all. I guess such a thing requires thorough digging into the depths of GHC, (or maybe even LLVM if an architecture independent representation is sought, but I don't know enough to say.). Perhaps this is more a question for those interested and knowledgable in Haskell compilation (and, to some extent, decompilation). If not Haskell, are there any languages which provide a simple serialization and deserialization of functions?

14 25

an evil type hangs GHC
by Petr Pudlak 12 Nov '10

12 Nov '10

Hi, I was playing with the following example I found in D.A.Turner's paper Total Functional Programming: > data Bad a = C (Bad a -> a) > > bad1 :: Bad a -> a > bad1 b@(C f) = f b > > bad2 :: a > bad2 = bad1 (C bad1) To my surprise, instead of creating a bottom valued function (an infinite loop), I managed to send the GHC compiler (ver. 6.12.1) to an infinite loop. Could anybody suggest an explanation? Is this a GHC bug? Or is this "Bad" data type so evil that type checking fails? Thanks, Petr

4 4