- Haskell-Cafe - Haskell.org

RE: [Haskell-cafe] Best practices for modular programming in Haskell
by Simon Marlow 17 Mar '05

17 Mar '05

On 17 March 2005 06:11, Sean Perry wrote: > Benjamin Pierce wrote: >> >> Other people seem to rely on Haddock to generate interfaces as >> documentation. This is nicer in many ways (e.g., it solves the above >> problem because Haddock elides the right-hand side of a "data" or >> "newtype" declaration if the constructors are not exported by the >> module), but it means that you are stuck browsing interfaces in a >> web browser can't just have a look with emacs. This is especially >> annoying if you want to read the interface in tandem with the >> implementation (because you are trying to understand how the thing >> works internally but want to use the interface to get a high-level >> picture of the functionality it presents to the world). >> > > haddock can also output docbook and you can make info pages from > docbook. Actually the DocBook backend isn't really there yet. It wouldn't be too hard to add a plain ASCII backend to Haddock that generates the interfaces for modules without the implementation - that would address Benjamin's concern to some extent. Cheers, Simon

3 2

Re: Best practices for modular programming in Haskell
by oleg＠pobox.com 17 Mar '05

17 Mar '05

Benjamin Pierce wrote: > For someone coming to Haskell from an OCaml background, one of the hardest > things to get used to is the somewhat more bare bones module system that > Haskell provides. > ... > This works fine as long as what you're exporting is just values, but it's > awkward for types, since there is no way to *declare* a type (e.g., giving > just its kind) without *defining* it. Actually Haskell fully matches the module system of OCaml -- and then adds some. Haskell provides both generative and applicative (recursive) functors. The following two messages elucidate the correspondence http://www.haskell.org/pipermail/haskell/2004-August/014463.html http://www.haskell.org/pipermail/haskell/2004-September/014515.html The end of the first message gives the translation dictionary: from OCaml/ML module terminology to Haskell terminology. I have recently found out that the translation works the other way around, too. Both messages are doubly-literate code: messages can be loaded into OCaml or into a Haskell system. Regarding the specific question of hiding a type: oftentimes declaring a class and exporting it suffices. (forall a.C a => a) is an `abstract' type in Haskell. If the type to abstract has a kind *->*, we can write (forall a.C a => a b), etc. If we really want to prevent the user from ever knowing the details of the implementation, existential quantification (along with the typeclass) does the trick. That trick incidentally permits `self-tuned' data structures, the simple example of which is http://www.haskell.org/pipermail/haskell/2005-February/015356.html

3 2

interesting IO oriented code
by robert dockins 17 Mar '05

17 Mar '05

I while back following the most recent discussion about filepaths and IO generally, I decided to pick up the torch and try my hand at a solution that delt with all the issues. My conception of the problem can be found here: http://www.haskell.org//pipermail/haskell-cafe/2005-January/008955.html However, I quickly got sidetracked by the character encoding issue, and sequential IO operations generally. I have come up with some code that I think is interesting, not least of which because it is somewhat performant. In the spirit of 'release early, release often' I am now making it available. I ended up developing a sequential IO API and a couple of test cases to drive it. I currently have a simple word count and a md5 implementation. There is a darcs repo at: http://www.eecs.tufts.edu/~rdocki01/filepath/ The code relies on multi-parameter typeclasses, fundeps and unboxed tuples, so its GHC only. The good news: 1) The API is semi-manageable. It is based around Producer, Transformer and Consumer functors (at least I think they can be called functors; I'm not real knowledgeable here). I think that with a little more work (and the input of people more experienced at this stuff than I) it could be sugared into a pretty usable API. 2) It is performant (mostly). At least it outperforms other Haskell IO methods I have tried. My 'wc' is about twice as fast as the current shootout version in informal tests (the shootout code is included in the repo). My md5 can sum somewhere between 2-4Mb/Sec on my hardware. 3) Very importantly, the code appears to have reliable constant-space behavior. 4) We are not artificially forced into the IO or ST monads for performance reasons. Explicit state passing is used where necessary, which seems to have the added benefit of helping the compiler to find good optimizations (pure speculation). The bad news: 1) Mostly performant is still not great. My wc takes about 6 times as long as the C version on my machine, and md5 takes about about 80 times as long. (interestingly, the C md5sum takes about 1/5 of the time as C wc!). However, it is within an order of magnitude of a java implementation of md5 (using the standard digest classes). 2) The performance is pretty fragile. Small changes can cause large performance hits for no easily discernible reason. This probably relates to the way particular optimizations do or don't get applied. The situation is hugely complicated by the typeclass-heavy API, I am sure. 3) The stream-observer paradigm is a somewhat difficult programming environment. My next step is to try some actual character encoding implementations (the original purpose after all) and see how that goes. I'd also like to try gzip and gunzip transformer layers. Any ideas for improvements (including patches!) are welcome. Robert Dockins PS the code currently includes a number of vestigial remnants of false starts, and is generally kind of ugly; you are warned.

4 4

FFI export questions
by John Goerzen 17 Mar '05

17 Mar '05

Hi, I'm trying to make a Haskell binding for the FUSE library, http://fuse.sourceforge.net/. The FUSE concept is centered around a struct whose members are pointers to callback functions. Here's the problem: the functions I want to callback to have types like this: vGetLine :: HVFS a -> a -> IO String Now, I can't just pass some sort of opaque pointer to C, because then the exact type of a would be lost. Is there any other method I might try? Thanks, John

2 1

Parse error
by Dmitri Pissarenko 17 Mar '05

17 Mar '05

Hello! In the attachment you will find a file, in which I try to access Java from Haskell using the Java bridge for functional languages. For details see http://sourceforge.net/projects/jvm-bridge/ and http://dapissarenko.com/resources/2005_02_17_eigenvaluesJava/2005_02_17_eig… luesJava.pdf When I try to compile the attached file using ghc +RTS -c -RTS -package javavm -c EigenvalueCalculatorHaskell.hs -o EigenvalueCalculatorHaskell.o I get the error EigenvalueCalculatorHaskell.hs:28: parse error on input `putStrLn' Unfortunately, I have not the slightest idea about how to fix/isolate it (I already commented out almost the whole code). Please tell me what I could try to correct the error. I appreciate ANY hint. Many thanks in advance Dmitri Pissarenko PS: The source code of the files related to EigenvalueCalculatorHaskell.hs is located at http://dapissarenko.com/resources/2005_02_17_eigenvaluesJava/2005_02_17_lik… -- Dmitri Pissarenko Software Engineer http://dapissarenko.com

3 2

Re: [Haskell-cafe] Typeclasses and instances
by Mark Carroll 17 Mar '05

17 Mar '05

Another note, with more help from friends: It turns out that GHC 6.4 will let me do, newtype Floating a => Test a = Test [a] deriving Show x = Test [False, True] but, if I change "newtype" to "data", it then says, No instance for (Floating Bool) I'm not sure I quite understand what's going on. -- Mark

2 1

Re: [Haskell-cafe] Typeclasses and instances
by Mark Carroll 17 Mar '05

17 Mar '05

> newtype Floating a => Vector a = Vector [a] Okay, I now know a little more about this, with help from friends. The obvious Functor instance seems not to work with GHC 6.2.2 but does work with GHC 6.4. With 6.2.2 I can still use GHC's newtype-deriving extension to derive an instance for Functor, I'm just not sure how I can get an explicit instance past 6.2.2 without it complaining about my syntax or not being able to deduce Floating a or b. This isn't a show stopper, I'm just intrigued. -- Mark

1 0

Functional Reactive Programming
by Andrew Cheadle 17 Mar '05

17 Mar '05

Hi Please excuse the broadcast! Does anyone know where I can get hold of the FRP software bundle from Yale that pre-dates AFRP and Yampa, i.e with behaviours and clocked events. We're trying to resurrect some software and want to start with a working code base before migrating it to AFRP. Many thanks Andy ********************************************************************* * Andrew Cheadle email: a.cheadle(a)doc.ic.ac.uk * * Department of Computing http://www.doc.ic.ac.uk/~amc4/ * * Imperial College * * University of London * *********************************************************************

1 0

Best practices for modular programming in Haskell
by Benjamin Pierce 17 Mar '05

17 Mar '05

For someone coming to Haskell from an OCaml background, one of the hardest things to get used to is the somewhat more bare bones module system that Haskell provides. Naturally, as I've gotten into the Haskell groove I've discovered (or learned from reading other people's code) nice ways of doing *some* of the things that I was used to doing with OCaml modules, but there are still things that I miss. This leads me to wonder how expert Haskell programmers address these issues. For example, here's my biggest current puzzle: What is the best way to expose the *interface* of a module (what would go in the .sig file in ML) to programmers that need to know how to use it? My impression is that there is no universally accepted "best way" to do this. Some people write their modules in the form: module Foo (<exported names>) where <type declarations for exported names> ------------------------------------------------------------- line of dashes <definitions of exported names (and other stuff)> This works fine as long as what you're exporting is just values, but it's awkward for types, since there is no way to *declare* a type (e.g., giving just its kind) without *defining* it. I suppose one could do something like module Foo (T,x) where type T = T_internal x :: T ------------------------------------------------------------- type T_internal = Int x = 5 but it seems clunky. Other people seem to rely on Haddock to generate interfaces as documentation. This is nicer in many ways (e.g., it solves the above problem because Haddock elides the right-hand side of a "data" or "newtype" declaration if the constructors are not exported by the module), but it means that you are stuck browsing interfaces in a web browser can't just have a look with emacs. This is especially annoying if you want to read the interface in tandem with the implementation (because you are trying to understand how the thing works internally but want to use the interface to get a high-level picture of the functionality it presents to the world). Are there other (perhaps better) ways that I'm not aware of? Thanks, Benjamin

2 1

Re: (Newbie) Dynamic Programming, Memoizing Etc.
by oleg＠pobox.com 17 Mar '05

17 Mar '05

Bryce Bockman wrote: > How would you guys memoize the following code. > > simpleCalc :: (Int,Int) -> (Int,Int) > simpleCalc (1,l) = (1,l+1) > simpleCalc (x,l) | (odd x) = simpleCalc (((3*x) + 1), 1 + l) > | otherwise = simpleCalc ((x `div` 2), 1 + l) > > sCalc x = simpleCalc (x,0) > > sCalcListRange a b = map sCalc [a..b] > > sCalcListLengthRange a b = map snd (sCalcListRange a b) > > The key is I need to calculate maximum (sCalcListLengthRange 1 1000000). One observation is that `l' is merely `an iteration counter'. Therefore, the code can be simplified. The other observation is that memoizing all intermediate results may be expensive: the memoization table (a list, for example) will be big and sparsely populated. The cost of indexing in such a list can be significant. Here's a solution that seems to be balancing both costs. One can change the balance by modifying sc_upb. > module Foo where > > import Data.Array > > sc_upb = 100 > sc = listArray (1,sc_upb) $ map sc_calc [1..] > > sc_get i | i <= sc_upb = sc ! i > sc_get i = sc_calc i > > sc_calc :: Int -> (Int,Int) > sc_calc 0 = (0,0) > sc_calc 1 = (1,1) > sc_calc x | odd x = let (r,c) = sc_get (3*x + 1) in (r, c+1) > sc_calc x = let (r,c) = sc_get (x `div` 2) in (r, c+1) > > sCalcListLengthRange' a b = map (snd . sc_calc) [a..b] *Foo> maximum $ sCalcListLengthRange 1 10000 262 (1.57 secs, 82200088 bytes) *Foo> maximum $ sCalcListLengthRange' 1 10000 262 (1.18 secs, 61043084 bytes) there seems to be a benefit.

1 0