- Haskell-Cafe - Haskell.org

ANN: hakyll-1.3
by Jasper Van der Jeugt 30 Jan '10

30 Jan '10

Hello, Today I'd like to announce the release of hakyll-1.3. Changes since 1.2: - Categories were added (as opposed to tags). You can find some information in this tutorial[1]. - createListing and createListingWith functions were added, as a way of having a more high-level way to create listings. All tutorials have been updated to work with listings now, a short explanation is available here[2]. In short, this basically replaces the old and verbose renderAndConcat/createCustomPage workflow. Changes since 1.1: - Rewrote caching system. - Rewrote templating system. - 4x speed improvement, mostly because of the Data.Binary library. You can get the latest version from hackage[3]. All feedback/criticism/comments are welcome. Kind regards, Jasper Van der Jeugt [1]: http://jaspervdj.be/hakyll/tutorial6.html [2]: http://jaspervdj.be/hakyll/tutorial3.html#custom-pages [3]: http://hackage.haskell.org/package/hakyll

1 0

Why cannot i add the `let` declaration ?
by zaxis 30 Jan '10

30 Jan '10

find_the_day sDay 0 = sDay find_the_day sDay nDay = if (is_trade_day $ nextDay sDay) then find_the_day (nextDay sDay) (nDay - 1) else find_the_day (nextDay sDay) nDay nextDay sDay = addDays 1 sDay The above code works fine. But the following always reports `compiling error`: find_the_day sDay 0 = sDay find_the_day sDay nDay = let nextDay = addDays 1 sDay if (is_trade_day $ nextDay) then find_the_day nextDay (nDay - 1) else find_the_day nextDay nDay Any suggestion is appreciated! ----- fac n = foldr (*) 1 [1..n] -- View this message in context: http://old.nabble.com/Why-cannot-i-add-the-%60let%60-declaration---tp273818… Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

4 5

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