January 2010 - Haskell-Cafe

where is the eros distribution
by Thomas Hartman 30 Jan '10

30 Jan '10

I was inspired by the google tech talk and would like to install and play with eros, but the http://darcs.haskell.org/packages/Eros/dist/ address pointed to at http://www.haskell.org/haskellwiki/Eros appears to be obsolete.

3 2

Re: [Haskell-cafe] begginers' questions
by Han Joosten 29 Jan '10

29 Jan '10

knyttr wrote: > > 1. suppose I have a function like this > > fun x y z = ... > fun x y [] = ... > fun x [] [] = ... > where > ... > > the "where" term will be applied just to the last definition. is it > possible to force it to all "fun" definitions? > The last two parts of your definition of fun will never be reached. The order of the definition is relevant. The first 'match' will be used. In this case, even if the third parameter of fun is an empty list, the part fun x y z =... is a match. In this case, changing the order to fun x [] [] = ... fun x y [] = ... fun x y z = ... would make more sence. however, there still is overlap. (ghc could generate a warning for this) now the where part: there are several options: fun x y z | z == [] = ... | y == [] = ... | otherwise = ... where ... or using a case expression... fun x y z = case (x,y,z) of (_ , _ , []) -> ... (_ , [] , [_:_]) -> ... (_ , [_:_], [_:_]) -> ... where ... pattern matches do not overlap this way. you could use this pattern matches also in the previous solution. Then your second question: > 2. how can I change a field in a list in the most easy way? the only > solution I found is below. I am not very happy with it - it does too many > operations just to change one field. > > changeIn array index value = (take (index-1) array)++[value]++(drop index > array) > > Remember, in haskell you do not 'change' values in variables. Thers is no such thing as a variable. You probably want a function that takes a list, an index and a value. It produces a list with all elements from the first list, only the n-th element is replaced with the given value. I would specify this as follows: f x:xs i v | i == 1 = v:xs | i > 1 = x : (f xs (i-1) v) but there are probably dozens of other ways to do this. While you are new to Haskell, do not worry too much about performance. (ghc will surly surprise you =^D) The main thing is to think functions. If you do that, you will appreciate Haskell for sure. -- View this message in context: http://old.nabble.com/begginers%27-questions-tp27377905p27378623.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

2 1

problems installing cabal on windows
by Han Joosten 29 Jan '10

29 Jan '10

I recently upgraded to GHC 6.12.1 on my windows system. Now I have trouble getting cabal right. I read the forums, and I got the cabal.exe for windows. I think I followed the upgrade instructions. However I do not get it all to work. THis is my version of Cabal: C:>cabal --version cabal-install version 0.6.2 using version 1.6.0.2 of the Cabal library However, when I try to install any library, I get: C:>cabal install graphviz cabal: failed to parse output of 'ghc-pkg dump' I get the feeling that I miss some step during installation, but I cannot figure out what that should be. I am the only user of my windows machine, and I have admin rights. Any suggestions are welcome! Han Joosten -- View this message in context: http://old.nabble.com/problems-installing-cabal-on-windows-tp27363309p27363… Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

3 3

Hierachical abstraction
by Andrew Coppin 29 Jan '10

29 Jan '10

OK, this is going to be a long one... Let's start with parsers. A monadic parser library (e.g., Parsec) gives you a set of primitive parsers. It also supplies functions to construct more complex commonly-used parsers. And then it provides functions for constructing even more complex parsers. (E.g., Parsec's expression parser builder.) Let's call the most basic primitive parsers level-0. Then we have level-1 functions, which construct parsers from level-0 parsers. And later we have level-2 functions which call the level-1 functions to construct even more sophisticated parsers. And so on and so forth, to unlimited depth. (The parser library itself has a limited depth, but the library can have clients that build functions on top of functions.) And so, in the end, the user calls a level-64 function, and gets a parser that does the required task. And that's great. The only problem is, the parser you get is a black box. You can't see what's inside it or what it's going to do. You can only run it. (Or combine it with other parsers.) Why is that a problem? Well, suppose you want to pass the finished parser through some kind of optimiser to rearrange its internal structure. Ah. You can't. It's a black box. Veering off onto a tangent for a moment... It seems to me that this is an inevitable consequence for any monadic parser. After all, the bind method runs some parse primitive, but it then feeds the result to a general function, which can undertake some arbitrarily complex Turing-complete calculation to decide what parse primitive to run next. Hell, I can write a parser that parses a description of a grammar, dynamically constructs a parser for that grammer, and then runs it! There's no way in hell that some static optimiser can hope to optimise the meta-parser so that it always generates optimal parsers. Even in theory it's utterly impossible. I wonder if you can make a parser combinator library which is *not* monadic? And, if you could, in what way would that limit the kinds of things you can parse? Anyway, coming back on topic... Let's suppose that instead of parsers, we've interested in queries. Suppose I'm writing some kind of relational database engine library, and I want to optimise queries before running them. The obvious solution is to design some kind of algebraic data type which can represent every possible level-0 query primitive. I can then write level-1 functions that construct level-0 data structures, and level-2 functions that call the level-1 functions, and so on, and at the end the caller will get a (presumably complex) level-0 description, which my optimiser can then go away and chew on. Now suppose I want to perform optimisations on the higher-level structure of the query. Currently, I can't. The hierachy of abstractions gets flatterend to level-0 in the process of the call stack, so my optimiser can only see the final level-0 representation. The obvious solution would be to design an algebraic data type for every level of the hierachy you want to analyse, complete with a function for converting to the next level down. As I understand it, this is how GHC works. It starts with raw Haskell source code, which it mashes around, and eventually converts into Core. The Core representation is then fiddled around with further, and eventually turned into STG. The STG gets poked and prodded, and converted to C--. And that eventually becomes raw assembly. The thing is, these are all radically different representations of the program. You can't mix (say) Haskell and STG together. And nor would you want to, given that they're such wildly different abstractions. [I notice in passing that, apparently, you can now FFI into C--, which is interesting...] However, consider the initial Haskell input. Initially it reflects what the programmer typed in. But GHC gradually desugars this into some minimal subset of the full Haskell language, before actually converting it to Core. That means that [picking an example out of thin air] initially an expression might contain the if/then/else construct, but at some point [I presume] this is desugared into a case expression. And that must mean that there are parts of the GHC codebase where it is permissible for an expression to contain if/then/else, and other parts where this is not permissible (and the code expects this construct to not be present). Is it possible to encode this kind of expectation into the type system? Or does GHC just tacitly rely on the fact that source code takes a predetermined path through the compiler engine? (That works for a monolithic product like a compiler, but it wouldn't be so hot for a library that 3rd parties can poke and prod arbitrary data into.) I'm basically looking at a problem which is like this. There are primitive constructs, and there are more sophisticated abstractions built from these, and I would like to come up with a system where abstractions are first-class, new abstractions can be added, and for any particular data structure, you can statically guarantee which abstractions are or aren't present. Has anybody ever looked at a general solution to something like that? [I'm going to stop talking now...]

5 9

Include creation date in Haddock documentation
by Dennis Walter 29 Jan '10

29 Jan '10

Hi all, I wonder if it is possible to have Haddock include the date and time at which the documentation was generated. Ideally this should only occur on index.html, but to have it in any file (e.g. in the footer) would be OK, too. I couldn't find any information about dates in the documentation. Documentation is created via Cabal: cabal haddock --executables --hyperlink-source Right now I include a token in the Cabal "description" field of the package, and sed-replace it afterwards, which is of course ugly. Thanks!

2 1

Community.haskell.org is down
by Neil Mitchell 29 Jan '10

29 Jan '10

http://downforeveryoneorjustme.com/community.haskell.org/ Thanks, Neil

1 0

imaging textbooks?
by Dan Mead 29 Jan '10

29 Jan '10

Hey all Can anyone recommend a good textbook on computer vision or image processing? I don't care if it favors Haskell or not, I'm just trying to find a good text. -Dan

4 3

Input request: which interface for Web Application Interface
by Michael Snoyman 29 Jan '10

29 Jan '10

I've made a few more changes to WAI since my last update. Namely, request and response headers are now their own datatype. As with Method, HttpVersion and Status, they both provide constructors for "everything else" and have functions to convert to/from bytestrings. This makes the package a bit more consistent, as well as giving us some more type safety and perhaps even some (negligible) performance gains. (Thanks again to Mark for the idea.) Another feature that will be added is a wrapper module. This will provide convenience functions for accessing the request body and generating a response body via other methods. For example, it will provide a lazy I/O interface for the request body and generating a response from a lazy bytestring. (Thanks to Nicolas for the idea.) The reason that it has not been written yet is because I have two options available for the request and response body interfaces. One is a direct copy of Hyena's enumerators, sans impredicative types. The other is a simpler I/O interface. Here are the benefits of each as I see it: Hyena enumerators: Provide accumulating parameter support. Provide mechanism for early response termination. Probably makes the server side of the request body simpler to program. Simple interface: More obvious how to use it. Makes the application side of the request body simpler to program. You can see the code for each in github: Enumerator: http://github.com/snoyberg/wai/blob/enumerator/Network/Wai.hs Simple: http://github.com/snoyberg/wai/blob/master/Network/Wai.hs I'm currently leaning to the enumerator approach, since it should be simple application side to wrap the enumerator into a more tractable interface. However, I'd like to hear people's opinions on this. To get an idea of how this changes code, I'm attaching a diff of the two branches, which includes a simple HTTP server and application. I'm also aware that documentation is sorely lacking right now; once we come to a decision on this piece of the interface, I'll add the wrapper functions and comment appropriately. Commenting at this stage would be putting the cart before the horse. Michael

1 0

big problems with MS Access backends
by Günther Schmidt 29 Jan '10

29 Jan '10

Hi, I need to use MS Access as a DB-backend. To make it not too easy there are tables with Umlaut Strings in some of the columns. Using HDBC-ODBC the Umlauts get merely garbled, I believe because MS-Access delivers in some sort of UTF-16 and HDBC-ODBC seems to manage that fine safe for the Umlauts, which get garbled. And Takusen crashes outright. Are there other haskellers out there which were in the same situation, ie. MS-Acess and Umlauts (or other none-ascii) and been able to solve this? I sure tried ... Günther

2 1

Non-termination of type-checking
by Matthieu Sozeau 29 Jan '10

29 Jan '10

Dear Haskellers, while trying to encode a paradox recently found in Coq if one has impredicativity and adds injectivity of type constructors [1] I stumbled on an apparent loop in the type checker when using GADTs, Rank2Types and EmptyDataDecls. > {-# OPTIONS -XGADTs -XRank2Types -XEmptyDataDecls #-} > module Impred where The identity type > data ID a = ID a I is from (* -> *) to *, we use a partial application of [ID] here. > data I f where > I1 :: I ID The usual reification of type equality into a term. > data Equ a b where > Eqrefl :: Equ a a The empty type > data False This uses impredicativity: Rdef embeds a (* -> *) -> * object into R x :: *. > data R x where > Rdef :: (forall a. Equ x (I a) -> a x -> False) -> R x > r_eqv1 :: forall p. R (I p) -> p (I p) -> False > r_eqv1 (Rdef f) pip = f Eqrefl pip > r_eqv2 :: forall p. (p (I p) -> False) -> R (I p) > r_eqv2 f = Rdef (\ eq ax -> > case eq of -- Uses injectivity of type constructors > Eqrefl -> f ax) > r_eqv_not_R_1 :: R (I R) -> R (I R) -> False > r_eqv_not_R_1 = r_eqv1 > r_eqv_not_R_2 :: (R (I R) -> False) -> R (I R) > r_eqv_not_R_2 = r_eqv2 > rir :: R (I R) > rir = r_eqv_not_R_2 (\ rir -> r_eqv_not_R_1 rir rir) Type checking seems to loop here with ghc-6.8.3, which is a bit strange given the simplicity of the typing problem. Maybe it triggers a constraint with something above? > -- Loops > -- absurd :: False > -- absurd = r_eqv_not_R_1 rir rir [1] http://thread.gmane.org/gmane.science.mathematics.logic.coq.club/4322/focus… -- Matthieu

4 4