May 2011 - Haskell-Cafe

Re: [Haskell-cafe] Is fusion overrated?
by Facundo Domínguez 18 May '11

18 May '11

> which is capable of producing elements one-by-one. So the whole thing > probably should run in constant space as well. Besides reducing the amount of GC calls, performance would also improve because the GC calls that remain are cheaper. The original program may run in constant space, but the fused program may use even a smaller constant space. Which in turn means that whenever the GC needs to make a pass, it is faster. Facundo

1 0

Is fusion overrated?
by Roman Cheplyaka 18 May '11

18 May '11

If one thinks about Haskell data structures as of ordinary data structures, fusion seems a great deal -- instead of producing intermediate lists and possibly running out of memory, we just run a loop and use constant amount of space. But Haskell data structures are quite different -- they are produced as demanded. Consider the example from the Stream Fusion paper[1]: f :: Int → Int f n = sum [ k ∗ m | k ← [1..n], m ← [1..k ] ] Assuming the sum is a strict left fold, it consumes elements of lists one-by-one and runs in constant space. The list part can be transformed to foldr (++) [] $ map (\k -> map (\m -> k*m) [1..k]) [1..n] which is capable of producing elements one-by-one. So the whole thing probably should run in constant space as well. Of course I don't claim that fusion is useless -- just trying to understand the problem it solves. Are we saving a few closures and cons cells here? [1] Stream Fusion. From Lists to Streams to Nothing at All. Duncan Coutts, Roman Leshchinskiy, Don Stewart. -- Roman I. Cheplyaka :: http://ro-che.info/ Don't worry what people think, they don't do it very often.

6 5

Haskell lib in non-Haskell program
by Eric Y. Kow 18 May '11

18 May '11

Hi all, I'd like to share my experiences packaging a Haskell program so that it can be used as a library by a non-Haskell application. I hope somebody might be able to (A) confirm that I'm doing the right thing or better still (B) suggest some corrections and/or simplifications. My objectives are: 1. For the non-Haskell application to use my library 2. ... without any Haskell infrastructure on the machine I think this means I want a shared library [1,2] although I'm a little bit fuzzy on the issue. I am not particularly concerned about the size of my executable or libraries. Including the Haskell RTS and my package deps is acceptable if that's what it takes to meet my primary and secondary objectives. I am targeting Windows and MacOS X. For Windows, my approach is to build a giant DLL with all the Haskell stuff statically linked in. For MacOS X I am using the `-dynamic` flag to compile all my dependencies (actually, I just set shared: True in cabal config) as well as the `-shared` flag. I am also now using GHC 7.0.3 with the latest (at the time of this writing) Haskell Platform (2011.2.0.1) [1] http://hackage.haskell.org/trac/ghc/wiki/SharedLibraries [2] http://www.haskell.org/ghc/docs/latest/html/users_guide/using-shared-libs.h… The whole thing ---------------------------------------------------------------------- You can see my efforts so far with darcs get --lazy http://code.haskell.org/GenI cd GenI cabal install cd geniwrapper make MacOS X users should be able to download http://erickow.com/tmp/MinimalGenI-OSX.tar.gz and run a test-mac.sh script which compiles a program with GCC using GenI, runs it and outputs some JSON string. Exposing some C functions and using them ---------------------------------------------------------------------- So far, I think I know how to expose some of library as C functions and to compile a little program written in C that uses this library. ghc --make -fvia-C MinimalGenI # provides some C functions via FFI exports ghc -c StartEnd.c # http://www.haskell.org/ghc/docs/latest/html/users_guide/win32-dlls.html ghc test-c.c MinimalGenI.o MinimalGenI_stub.o StartEnd.o\ -package GenI -package utf8-string\ -o test-c.o I notice that -fvia-C is going away, but I'm going to ignore this fact for now and assume/hope that doing without it will be easy Building a Windows shared library ---------------------------------------------------------------------- As I understand it, it is possible to build a Windows DLL, albeit one containing the Haskell RTS and all my Haskell libraries statically linked in. Users can download the DLL and link it to their Visual Basic programs without having to touch GHC. The extra work involved looks like this: ghc MinimalGenI.o MinimalGenI_stub.o StartEnd.o\ -package GenI -package utf8-string\ -shared -o MinimalGenI.dll ghc test-c.c MinimalGenI.dll -o test-c2 Note that building test-c.c with ghc does not meet my second objective of being able to combine Haskell lib with non-Haskell program sans Haskell infrastructure. However, I think I know how to do it for MacOS X and that the procedure would be more or less the same. I have not looked into it. [3] http://www.haskell.org/ghc/docs/latest/html/users_guide/win32-dlls.html Building a MacOS X shared library ---------------------------------------------------------------------- For MacOS X, I would almost like to generate a gigantic file like the Windows DLL. But maybe that's the wrong thing to want. I do almost exactly the same thing, except that instead of distributing a single giant file, I track down a whole bunch of dependencies and copy over the dylib files for them. Note that as a prerequisite, this requires reinstalling a lot of packages with --enable-shared (I just edit ~/.cabal/config and set shared to True). ghc MinimalGenI.o MinimalGenI_stub.o StartEnd.o\ -package GenI -package utf8-string\ -dynamic -shared -o MinimalGenI.dylib ghc test-c.c MinimalGenI.dylib -o test-c2 As an alternative to building with GHC, I can compile test-c.c and link with MinimalGenI.dylib directly with GCC. It's a little bit hairy. What I did was to run ghc with -v3 to see what gcc commands it was running, clean them up and package them in a script (test-mac.sh attached). It's a little bit voodoo-ish, a lot of flags that I don't really understand the significance of, and some libraries I'm not 100% clear on why I need the static versions for. Also I find it slightly odd that I can't seem to just merge the first two steps of the process, producing/assembling assembly code for test.c. In any case, it seems to work... Packaging the MacOS X shared library ---------------------------------------------------------------------- I'm trying to distribute my Haskell library in a way that does not require the user to install anything beyond XCode. To do this, I track down the dynamic libraries for all the packages I'm using and their dependencies. Unfortunately, the way I did it was basically trial and error (find all dylib and hand remove the ones that seem totally irrelevant; get a friend to test it on a raw machine). Rather than the dumb approach used in the attached dist-mac.sh, it should be relatively easy to write a small Haskell script to recurse down the package dependency tree and tell me exactly which files I need to copy. Maybe such a tool exists already. If this procedure is right, and if somebody should write such a script (maybe already part of the cabal-macosx package?) then I bet creating app bundles for your MacOS X Haskell GUI tools should be quite straightforward as well. Thanks for reading! -- Eric Kow <http://erickow.com>

1 0

Random thoughts about typeclasses
by Robert Clausecker 18 May '11

18 May '11

Hello! I found out, that GHC implements typeclasses as an extra argument, a record that stores all functions of the typeclass. So I was wondering, is there a way (apart from using newtype) to pass a custom record as the typeclass record, to modify the behavior of the typeclass? I thought about something like this: f :: Show a => [a] -> String f = (>>= show) -- So, f becomes something like this? __f :: ClassShow a -> [a] -> String __f (ClassShow __show) x = x >>= __show -- And if I call the function, it looks somewhat like this: g :: [Int] -> String g = f __g = __f instanceShowInt -- But is it possible to do something like this? g2 = __f (ClassShow (return . fromEnum)) Tis is just a random thought, some compilers like JHC implement them by another way. But would this theoretically be possible? Yours, FUZxxl

4 3

Exception for NaN
by Grigory Sarnitskiy 18 May '11

18 May '11

How do I make my program stop whenever it gets somewhere NaN as a result during a calculation? If there is no appropriate flag for ghc maybe there exist flags for C to use in optc. I don't want NaN to propagate, it is merely stupid, it should be terminated.

13 19

Re: [Haskell-cafe] why doesn't ghc give you a type signature that works ?
by Ivan Lazar Miljenovic 18 May '11

18 May '11

(Re-CC-ing the list) On 18 May 2011 15:16, <briand(a)aracnet.com> wrote: > On Wed, 18 May 2011 13:52:46 +1000 > Ivan Lazar Miljenovic <ivan.miljenovic(a)gmail.com> wrote: > >> What's happening is that the type involves the FFTWReal class. >> However, this isn't immediately visible to ghci as it isn't in scope, >> but it can figure out that it's found in Math.FFT.Base. As such, you >> need to import that module as well (as opposed to just the Math.FFT >> class you have already imported). >> > > Well now, that makes perfect sense doesn't it ? > > I think my problem is that I think if I import the top-level module then the sub-modules should also be visible, provided I use the full name, or in the case of a qualified name, something link FFT.Base.FFTWReal. > > Clearly this is not the case, but why not ? Is it just the convention that haskell chose, or is there a reason for it ? Consider Data.ByteString vs Data.ByteString.Lazy; the have the exact same API but for completely different types. Also, it's quite often for package foo to have module Data.Foo, and then module bar extends it with module Data.Foo.Bar; should importing Data.Foo also bring in Data.Foo.Bar? What happens if bar isn't installed? -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com IvanMiljenovic.wordpress.com

1 0

why doesn't ghc give you a type signature that works ?
by briand＠aracnet.com 18 May '11

18 May '11

for example: I will ask the glorious compiler, and it says: *Main> :t calcFFT calcFFT :: (Math.FFT.Base.FFTWReal r) => V.Vector (Complex r) -> V.Vector (Complex r) I then put the signature in my code, reload it, and: Not in scope: type constructor or class `Math.FFT.Base.FFTWReal' It seems very strange to me that the fully qualified module name doesn't work, nor does any combination thereof, e.g. FFT.FFTWReal, FFT.Base.FFTWReal, etc... I'm importing FFT as: import qualified Math.FFT as FFT I'm not sure if that causes the problem. Generally speaking this happens to me quite a lot, and I've never tried to understand what's going on, because the signature is not required. I've decided to try now :-) Obviously I'll need some help. Thanks, Brian

4 3

fishing for ST mutable Vector examples
by brad clawsie 17 May '11

17 May '11

hi all i was wondering if anyone could post some minimal examples on using mutable Vectors in the ST monad. i've been digging around in the usual places but haven't been able to find anything to get me over the hump thanks in advance brad

8 10

opening windows on a mac via ghci?
by Conal Elliott 17 May '11

17 May '11

Has anyone figured out a way to get libraries that open windows to work with ghci? With libraries like glut I get the body of a window, but no frame, and the process wedges. I guess the problem has to do with lack of .app bundle. If so, perhaps a work-around might involve running ghci in an app bundle--though I'm just speculating from vast ignorance. - Conal

2 1

ANNOUNCE: preview release of diagrams EDSL for declarative drawing
by Brent Yorgey 17 May '11

17 May '11

I am extremely pleased to announce a "developer preview" release of the diagrams framework [1] for declarative drawing. This is a well-thought-out, well-documented, working release with all core functionality in place, but with many planned features still missing (for example, support for rendering text and higher-level tools for constructing curves). If you are interested in - trying out a new way of producing vector graphics, - providing feedback to help drive ongoing development, or - getting involved and contributing some code yourself, please give it a try! On the other hand, if you are looking for a complete, full-featured package that will let you jump right into producing the graphics you need, you may want to wait for the 1.0 release. If you are familiar with the diagrams package [2] already on Hackage, this is a complete rewrite which has been in the works for over a year and a half. What is it? ----------- Diagrams is an embedded domain-specific library (EDSL) for creating diagrams, illustrations, and other sorts of vector graphics. The overall vision is for diagrams to become a viable alternative to systems like MetaPost, Asymptote, and PGF/TikZ. Diagrams is: - Declarative: you specify what a diagram is, not how to draw it. - Compositional: diagrams can be combined in many ways to produce more complex diagrams. Diagrams are scale- and translation-invariant, so you never have to worry about a "global" coordinate system, only "local" ones. - Embedded: the full power of Haskell, including every library on Hackage, is available to help construct and manipulate diagrams. - Extensible: extending diagrams with additional or higher-level functionality is as simple as writing a Haskell module. - Flexible: diagrams is designed from the ground up to be as generic and flexible as possible. Features include: - Pluggable rendering backends -- creating a new rendering backend is as simple as writing a type class instance. - Arbitrary vector spaces -- the core diagrams library data types and primitives work for any vector space, so given a suitable rendering backend you can produce diagrams of any dimension, or even more exotic things... Cool, how can I try it out? --------------------------- Start by reading the quick tutorial [3], which has detailed information about how to install the necessary packages and will introduce you to the fundamentals of the framework. Or, for the truly impatient: cabal install diagrams-core diagrams-lib diagrams-cairo How can I contribute? --------------------- There are lots of ways you can contribute! First, you may want to subscribe to the project mailing list [4], and/or come hang out in the #diagrams IRC channel on freenode.org. - Cairo is the only well-supported backend at the moment, but you might create another backend or contribute to an existing project [5]. - The standard library is in need of additional features. Visit the Google Code site [6] for a list of open tickets. - Create a higher-level module built on top of the diagrams framework (e.g. tree or graph layout, generating Turing machine configuration diagrams, Penrose tilings ... your imagination is the only limit!) and submit it for inclusion in a special diagrams-contrib package which will be created for such higher-level user-contributed modules. - Use diagrams to create some cool graphics and submit them for inclusion in a gallery of examples (to be created soon). - Start your own project built on top of diagrams and let us know how it goes! - Last but certainly not least, just try it out for your pet graphics generation needs and contribute your bug reports and feature requests. Happy diagramming! Brought to you by the diagrams team: - Brent Yorgey - Ryan Yates with contributions from: - Sam Griffin - Vilhelm Sjöberg - Luite Stegeman - Kanchalai Suveepattananont - Scott Walck [1] http://code.google.com/p/diagrams/ [2] http://hackage.haskell.org/package/diagrams [3] http://projects.haskell.org/diagrams/tutorial/DiagramsTutorial.html [4] http://groups.google.com/group/diagrams-discuss [5] http://code.google.com/p/diagrams/wiki/BackendProjects [6] http://code.google.com/p/diagrams/

3 3