August 2010 - Haskell-Cafe

[ANNOUNCE] (and request for review): directory-tree v0.9.0
by Brandon Simmons 10 Aug '10

10 Aug '10

Greetings Haskellers! directory-tree is a module providing a directory-tree-like datatype along with Foldable and Traversable instances, along with a simple, high-level IO interface. You can see the package along with some examples here (apologies if the haddock docs haven't been generated yet) : http://hackage.haskell.org/package/directory-tree This primary change in this release is the addition of two experimental "lazy" functions: `readDirectoryWithL` and `buildL`. These functions use `unsafePerformIO` behind the scenes to traverse the filesystem as required by pure computations consuming the returned DirTree data structure. I believe I am doing this safely and sanely but would love if some more experienced folks could comment on the code. These changes (and this whole revamping of this originally very simple module) were inspired by the fact that a few people seemed to really like this API, and this recent reddit post lamenting the perceived difficulty of writing a `du`-like function in haskell. http://www.reddit.com/r/haskell/comments/cs54i/how_would_you_write_du_in_ha… One could write such a function using directory-tree as follows (sorry if the monadic compositional style is foreign): > import System.Directory.Tree > import qualified Data.Foldable as F > import System.IO > import Control.Monad > > du :: FileName -> IO () > du = print . F.sum . free <=< readDirectoryWithL (hFileSize <=< readHs) > where readHs = flip openFile ReadMode Thanks for reading and for any input, especially performance suggestions or opinions on my unsafe function usage. I hope this is useful to someone. SIncerely, Brandon Simmons http://coder.bsimmons.name/

2 3

StablePtr overhead?
by Gregory Collins 10 Aug '10

10 Aug '10

Hi all, Can anyone explain what the overhead of using StablePtrs is? Specifically I am interested in knowing the time/space complexity of the various Foreign.StablePtr operations and how many memory indirections are involved when using deRefStablePtr. G -- Gregory Collins <greg(a)gregorycollins.net>

2 1

Re: [Haskell-cafe] iPhone/Android and Haskell [Was: Embedded funcional programming?]
by Liam O'Connor 10 Aug '10

10 Aug '10

Our best bet is to compile to ARM native code and then use the NDK to talk to the Java APIs. Cheers. ~Liam

8 15

Unused import warnings.
by Lyndon Maydwell 10 Aug '10

10 Aug '10

Hi Cafe. I have written some QuickCheck properties in my source and am using these for testing, however, when I compile my program I get warned about unused imports: > Warning: Module `Test.QuickCheck' is imported, but nothing from it is used Is there a way to suppress these warnings for a particular module by using a pragma directive or something similar? Thanks! - Lyndon

3 6

zip-archive performance/memmory usage
by Pieter Laeremans 10 Aug '10

10 Aug '10

Hello, I'm trying some haskell scripting. I'm writing a script to print some information from a zip archive. The zip-archive library does look nice but the performance of zip-archive/lazy bytestring doesn't seem to scale. Executing : eRelativePath $ head $ zEntries archive on an archive of around 12 MB with around 20 files yields Stack space overflow: current size 8388608 bytes. The script in question can be found at : http://github.com/plaeremans/HaskellSnipplets/blob/master/ZipList.hs I'm using the latest version of haskell platform. Are these libaries not production ready, or am I doing something terribly wrong ? kind regards, Pieter -- Pieter Laeremans <pieter(a)laeremans.org> "The future is here. It's just not evenly distributed yet." W. Gibson

6 6

Couple of questions about *let* within *do*
by michael rice 10 Aug '10

10 Aug '10

From: Learn You a Haskell =================== Remember let bindings? If you don't, refresh your memory on them by reading this section. They have to be in the form of let bindings in expression, where bindings are names to be given to expressions and expression is the expression that is to be evaluated that sees them. We also said that in list comprehensions, the in part isn't needed. Well, you can use them in do blocks pretty much like you use them in list comprehensions. Check this out: import Data.Char main = do putStrLn "What's your first name?" firstName <- getLine putStrLn "What's your last name?" lastName <- getLine let bigFirstName = map toUpper firstName bigLastName = map toUpper lastName putStrLn $ "hey " ++ bigFirstName ++ " " ++ bigLastName ++ ", how are you?" =================== Questions: 1) Is there an implicit *in* before the last line above? 2) Within a do "in" the IO monad (or any other monad), can a *let* do something like this? let x = do -- in a different monad Michael

8 10

QuickCheck and Pairing Heaps
by Matias Eyzaguirre 10 Aug '10

10 Aug '10

Hi, I'm trying to figure out QuickCheck and how to generate arbitrary test data form complex data structures; I thought an interesting experiment would be Pairing Heaps. A pairing heap is essentially just a tree whose nodes obey the heap property (for all nodes A in a pairing whose nodes can be compared, the value of A is greater then the value of any descendants of A). I came with a definition that I think seems reasonable \begin{code} data (Ord a) => Heap a = Heap a [Heap a] \end{code} But I cannot think of a way to generate arbitrary heaps, I see three main issues: 1. Based on the examples I have seen, I understand how you could define arbitrary so that it uses frequency to choose either a leaf or a branch, but how would you generate a variable number of children? 2. That would hardcode the probably size of the heap, how would you define an arbitrary heap that was dependent on some sort of size parameter? 3. The way I see it, you could generate arbitrary heaps of type A (where A is an instance of Arbitrary and Ord), but how would you make sure that each node of the generated tree was heapy (the max of all its descendants)?

2 1

Re: [Haskell-cafe] Couple of questions about *let* within *do*
by Felipe Lessa 10 Aug '10

10 Aug '10

On Tue, Aug 10, 2010 at 2:40 PM, Bill Atkins <batkins57(a)gmail.com> wrote: > They're not really statements, they're just named expressions and are still subject to lazy evaluation. > > In: > > let x = putStrLn "Name" >> getLine > putStrLn "Welcome" > x Yes, 'putStrLn "name" >> getLine' is an expression. However, the whole line 'let x = putStrLn "Name" >> getLine' inside the do-block is an statement. Althought the word 'let' is used in both cases, they are defined in different places of the grammar (see the links of my previous mail). So when you write do ... let ... -- stmt ... you are using a let statement. You can use a let expression in a do-block as well: do ... let ... in ... -- expr ... Note, however, that you must indent the 'in' part, as you would need to indent an if expression inside a do-block. do ... do {... let ... -- expr gets parsed as ;let ... -- stmt in ... -- ;in ... -- ??? ... ;...} Cheers, -- Felipe.

1 0

More Flexible Monad Transformer OR Bad Coding Style
by aditya siram 09 Aug '10

09 Aug '10

Hi all, I was experimenting with monad transformers and realized that the stacking order of the monads can remain unknown until it is used. Take for example the following code: import "mtl" Control.Monad.State import "mtl" Control.Monad.Writer import "mtl" Control.Monad.Identity test :: (MonadWriter [Char] m, Num t, MonadState t m) => m () test = do put 1 tell "hello" main = do x <- return $ runIdentity $ runStateT (runWriterT test) 1 -- test :: WriterT String (StateT Int Identity) y <- return $ runIdentity $ runWriterT $ runStateT test 1 -- test :: StateT Int (WriterT String Identity) z <- runWriterT $ runStateT test 1 -- test :: StateT Int (WriterT String IO) (((), Int), String) print x print y print z *Main> main (((),"hello"),1) (((),1),"hello") (((),1),"hello") Until test is called in 'main' we don't know the order of monads. In fact even the base monad is not know. All we know is that it uses the State and Writer monad. In each call to 'test' in main we can determine the stacking order and the base monad yielding different results. This seems to be a more flexible way of using monad transformers but I haven't seen this in code before so is there anything wrong with this style? -deech

6 7

Some Haskell mode extensions
by Christopher Done 09 Aug '10

09 Aug '10

Hi there, I've written some very simple Emacs modules for making using Haskell in Emacs a little bit nicer: http://github.com/chrisdone/haskell-mode-exts You can download the project with git, or pick and choose individual files: http://github.com/chrisdone/haskell-mode-exts/raw/master/haskell-navigate-m… http://github.com/chrisdone/haskell-mode-exts/raw/master/haskell-align-impo… http://github.com/chrisdone/haskell-mode-exts/raw/master/haskell-sort-impor… http://github.com/chrisdone/haskell-mode-exts/raw/master/haskell-installed-… More documentation about installed module completion here, I need to do another module for syntax-aware import editing, but this module is already quite usable: http://www.chrisdone.com/posts/2010-08-07-emacs-haskell-installed-packages.… I have a few more in the works and more planned, e.g. (some of which may already have been implemented somewhere, but): 1) syntax aware import line editing (think: tabbing between sections, toggling qualified on/off, etc.) 2) controlling cabal through inferior-haskell-mode (already done this, but I need to make it portable) 3) tidying up of inferior-haskell (it wastes a lot of space) 4) more interactiveness with inferior-haskell e.g. "you need -XExtension" should really just prompt me whether I want to add it to the file or enable it in ghci, and then do it. (When you're in the middle of working, adding extensions to the top of the file is laborious.) 5) automatic integration with etags and some improvement to its little issues 6) a high-level .cabal file editing mode 7) unit testing integration And so on. There's loads that can be done. I'm just implementing the stuff I want, and if some of it's useful in general, maybe it can be absorbed into the general haskell-mode distrib. The haskell-emacs mailing list is down at the moment, so I thought I'd post here. Cheers!

1 0