- Haskell-Cafe - Haskell.org

A question regarding reading CPP definitions from a C header
by Ömer Sinan Ağacan 07 Oct '13

07 Oct '13

Hi all, Let's say I want to #include a C header file in my Haskell library just to read some macro definitions. The C header file also contains some C code. Is there a way to load only macro definitions and not C code in #include declarations in Haskell? What I'm trying to do is I'm linking my library against this C library but I want to support different versions of this C library, so I want to read it's version from one of it's header files. The problem is the header file contains some C code and makes my Haskell source code mixed with C source before compilation. Any suggestions would be appreciated, Thanks, --- Ömer Sinan Ağacan http://osa1.net

3 4

Lenses that work with Arrows
by Tom Ellis 07 Oct '13

07 Oct '13

Dear all, I introduce a very simple extension to the Lens datatype from Control.Lens that allows it to work with Arrows: https://gist.github.com/tomjaguarpaw/6865080 I would particularly like to discuss this with authors of Control.Lens to see if such an idea is suitable for inclusion in their library. I have also started a Reddit discussion here: http://www.reddit.com/r/haskell/comments/1nwetz/lenses_that_work_with_arrow… Tom

2 3

Lifting IO actions into Applicatives
by Michael Snoyman 07 Oct '13

07 Oct '13

I'm wondering if anyone's run into this problem before, and if there's a common solution. In Yesod, we have applicative forms (based originally on formlets). These forms are instances of Applicative, but not of Monad. Let's consider a situation where we want to get some user input to fill out a blog post datatype, which includes the current time: data Blog = Blog Title UTCTime Contents myBlogForm :: Form Blog myBlogForm = Blog <$> titleForm <*> something <*> contentsForm The question is: what goes in something? Its type has to be: something :: Form UTCTime Ideally, I'd call getCurrentTime. The question is: how do I lift that into a Form? Since Form is only an Applicative, not a Monad, I can't create a MonadIO instance. However, Form is in fact built on top of IO[1]. And it's possible to create a MonadTrans instance for Form, since it's entirely possible to lift actions from the underlying functor/monad into Form. So something can be written as: something = lift $ liftIO getCurrentTime This works, but is unintuitive. One solution would be to have an ApplicativeIO typeclass and then use liftIOA. My questions here are: 1. Has anyone else run into this issue? 2. Is there an existing solution out there? Michael [1] Full crazy definition is at: http://haddocks.fpcomplete.com/fp/7.4.2/20130922-179/yesod-form/Yesod-Form-…

15 22

Any precedent or plan for guaranteed-safe Eq and Ord instances?
by Ryan Newton 07 Oct '13

07 Oct '13

Hello all, Normally, we don't worry *too* much about incorrect instances of standard classes (Num, Eq, Ord) etc. They make the user's program wrong, but they don't compromise the type system. Unfortunately, with the LVish parallel programming library we do have a situation where incorrect instances of Eq and Ord can cause the "types to lie". In particular, something that claims to be a pure, non-IO type, can actually yield a different result on different runs, including throwing exceptions on some runs but not others. So what's the best way to lock down "SafeEq" and "SafeOrd" instances, taking control away from the user (at least with -XSafe is turned on)? We could derive our own SafeEq and SafeOrd instances based on GHC.Generics. BUT, that only helps if we can forbid the user from writing their own incorrect Generics instances when Safe Haskell is turned on. It looks like GHC.Generics is currently marked as "TrustWorthy": http://www.haskell.org/ghc/docs/7.4.1/html/libraries/ghc-prim-0.2.0.0/GHC-G… So.... could we get GHC.Generics marked as "Unsafe" and enable some more limited interface that is "Trustworthy"? (Allowing the user ONLY to do 'deriving Generic'). This would be similar to the new policy in GHC 7.8 of only allowing derived Typeable instances... -Ryan

11 22

Music update
by Mark Lentczner 07 Oct '13

07 Oct '13

Some might remember me asking about music packages a while back... An update: I ended up using Euterpea, which in turn uses both Codec.Midi and Sound.PortMidi. My working environment was to have my code loaded up in ghci, play MIDI into a software MIDI bus, and pipe that into MainStage 3 which ran the synths. The piece I was working on premiered last night at a concert in Wellington, NZ. The live recording will take a while, but you can hear a studio synth recording (from the above setup) here: https://soundcloud.com/mtnviewmark/plain-changes-2-all-synth-mix The code for the piece is all open source: https://github.com/mzero/PlainChanges2. In particular, there is a somewhat improved MIDI player<https://github.com/mzero/PlainChanges2/blob/master/src/Sound/MidiPlayer.hs> in there. Enjoy! - Mark P.S.: Yes, and now that that's done with, I can get on with the next Haskell Platform release!

3 3

[ANNOUNCE] Penny - double-entry accounting
by Omari Norman 07 Oct '13

07 Oct '13

I'm pleased to make the first public announcement of the availability of Penny, a double-entry command-line accounting system. Penny is inspired by Ledger, an excellent program in its own right. Ledger's websites and sales pitches are much better developed than those for Penny, so first take a look at Ledger's website to see if the concepts behind this program interest you: http://www.ledger-cli.org/ With that in mind, here is what distinguishes Penny from Ledger: * Smarter report formatting. When using Ledger I rarely bothered to reformat the reports because I could never remember how to use the cryptic formatting strings. Penny automatically formats reports to fit the width of your screen. You can easily add or remove information in your reports. * Use of color. Color is baked into Penny, making reports easier to read. It takes advantage of 256-color terminals where available. * Adherence to double-entry accounting principles. Ledger will allow you to enter unbalanced transactions. Penny never allows this. Even infinitesimally unbalanced transactions will render your entire ledger invalid. * Different handling of commodities. In part because of the strict adherence to double-entry accounting principles, Penny handles commodities (e.g. transactions involving multiple currencies, or currency and equities) differently than Ledger. Some might regard Penny's handling of commodities to be a pain, but I think it results in a system that is more predictable, has no corner cases, and is easy to test. * More orthogonal command-line interface. For example, in Ledger, you use one set of options to filter postings by date, and a different set of options to control the dates of postings that are shown in the register report. Penny uses identical options for these two purposes; what these options mean depends on where they appear on the command line. In addition, in Penny you can build filtering expressions of arbitrary complexity, using either infix or reverse polish notation. * Automated import of postings. You can import postings from your bank as long as it gives you OFX files. Many financial institutions supply OFX files, as it is the format used by Quicken and by the now-defunct Microsoft Money. Penny can also help automate a great deal of the process of reconciling your ledger with bank statements. This removes an enormous amount of the drudgery that is associated with maintaining a ledger. * Exposes a Haskell API. This is actually the primary reason I wrote Penny. I run several automated checks on my ledger. Doing this in Ledger was growing difficult because I had no standalone parser for the ledger files. With Penny I can easily write additional small programs to check up on the consistency of my ledger (for instance, to make sure I'm not using invalid accounts, or to make sure that a particular account has postings within a given time period.) The power of Haskell makes this much easier than it would be if I used a dynamically typed language like Haskell or, as I used to do with Ledger, a random assemblage of shell, Awk scripts, Haskell, and more. Another child of Ledger that is written in Haskell is hledger: http://hledger.org/ hledger is a great program; if you like it, please continue using it. In addition to what you can glean from the bullets above, here are some key ways Penny differs from hledger: * hledger is at least partially compatible with Ledger; Penny is incompatible with Ledger. There currently is no program to convert Ledger files to the format Penny uses (I once wrote such a program to convert my Ledger files to Penny; after that the program was of no use to me and the file format has since changed, rendering that code useless.) * hledger has a web interface. Penny does not and I doubt it ever will. * hledger has a robust community; Penny does not. * hledger supports more of Ledger's feature set with features such as timelog support, periodic reports, and balance assertions. Penny does not have these features. * hledger uses floating-point types to represent amounts: http://hackage.haskell.org/package/hledger-lib-0.21.3/docs/Hledger-Data-Typ… Penny uses only integers: http://hackage.haskell.org/package/penny-0.30.0.0/docs/Penny-Lincoln-Bits-Q… This page summarizes why that matters: http://stackoverflow.com/questions/3730019/why-not-use-double-or-float-to-r… * Penny is BSD3; hledger is GPL. And an entirely subjective comparison that may be biased: Penny is designed from the ground up to use Haskell's static type system and its module system to its maximum advantage, which makes Penny easier to use as a base for your own programs to check your ledger, and which reduces bugs. Penny has been in development for over a year now, and I use it to maintain my financial records. A set of QuickCheck tests, in conjunction with maximum exploitation of Haskell's static type system, help ensure the correctness of the code. However, as with all free software, Penny comes with no warranty. Use it at your own risk. Please report any bugs you find in the programs or the documentation to omari(a)smileystation.com. Penny is written only for UNIX-like operating systems. Currently it should build against Haskell Platform 2013.2.0.0. If it doesn't work on your Linux or Mac OS X system, please let me know. Get Penny using "cabal install penny" or look here: http://hackage.haskell.org/package/penny Website with manpages: http://massysett.github.io/penny/ Github: https://github.com/massysett/penny Enjoy. Omari

2 1

Converting MPTC+fundeps to type family / problem with polymorphic constant. Roles?
by Ryan Newton 07 Oct '13

07 Oct '13

The "abstract-par" class has used multi-parameter type classes with fundeps: http://hackage.haskell.org/package/abstract-par-0.3.1/docs/Control-Monad-Pa… And I'm trying to port it to use type families. But the following combination seems to be completely unusable for me right now: class ParFuture m => ParIVar m where new :: forall a . m (Future m a) You can see the error when you try loading this file at this line: https://github.com/iu-parfunc/lvars/blob/b60cafb941ea8f2f333ada9b5206cd2121… "Future" is a type-function from the superclass. I can't seem to use "new" in any way at any type without getting: Control/Par/Class.hs:161:9: Could not deduce (Future m a ~ Future m a0) from the context (ParIVar m, FutContents m a) bound by the type signature for newFull_ :: (ParIVar m, FutContents m a) => a -> m (IVar m a) at Control/Par/Class.hs:151:13-74 NB: `Future' is a type function, and may not be injective The type variable `a0' is ambiguous Possible fix: add a type signature that fixes these type variable(s) Expected type: m (IVar m a) Actual type: m (Future m a0) In the expression: (new :: m (IVar m a)) In a pattern binding: _ = (new :: m (IVar m a)) In an equation for `newFull_': newFull_ a = do { return undefined } where _ = (new :: m (IVar m a)) Failed, modules loaded: none. Ok, so it seems like the type of "new" may just be intrinsically unusable. There is no way, by constraining the output of the "new" function for the type system to infer what input to the Future type function was. (Type function not reversable / injective.) So am I just stuck? I don't want a dummy, unused argument just to communicate the type information to "new". Is this just a place where *MPTC + fundeps works but type familes do not? *Or is there some way that roles can save the day here? Do I need to *say that the 'a' parameter has a representation role*? Thanks, -Ryan

1 1

Poll & plea: State of GUI & graphics libraries in Haskell
by Conal Elliott 06 Oct '13

06 Oct '13

I'm polling to see whether there are will and expertise to reboot graphics and GUIs work in Haskell. I miss working on functional graphics and GUIs in Haskell, as I've been blocked for several years (eight?) due to the absence of low-level foundation libraries having the following properties: * cross-platform, * easily buildable, * GHCi-friendly, and * OpenGL-compatible. The last several times I tried Gtk2hs, I was unable to compile it on my Mac. Years ago when I was able to compile, the GUIs looked and interacted like a Linux app, which made them awkward and upleasant to use. wxHaskell (whose API and visual appearance I prefered) has for years been incompatible with GHCi, in that the second time I open a top-level window, the host process (GHCi) dies abruptly. Since my GUI & graphics programs are often one-liners, and I tend to experiment a lot, using a full compilation greatly thwarts my flow. For many years, I've thought that the situation would eventually improve, since I'm far from the only person who wants GUIs or graphics from Haskell. About three years ago, I built a modern replacement of my old Pan and Vertigo systems (optimized high-level functional graphics in 2D and 3D), generating screamingly fast GPU rendering code. I'd love to share it with the community, but I'm unable to use it even myself. Two questions: * Am I mistaken about the current status? I.e., is there a solution for Haskell GUI & graphics programming that satisfies the properties I'm looking for (cross-platform, easily buildable, GHCi-friendly, and OpenGL-compatible)? * Are there people willing and able to fix this situation? My own contributions would be to test and to share high-level composable and efficient GUI and graphics libraries on top of a working foundation. Looking forward to replies. Thanks, -- Conal

20 27

Haskellers in Minsk, Belarus?
by Yuras Shumovich 06 Oct '13

06 Oct '13

Hi, I just read an article (sorry, it is in russian: http://habrahabr.ru/post/196454/ ). The idea I found interesting: even in big citied developers complain that nothing happens at their location, but when you try to make an event -- only few of them want to participate. I never participate in events. What is wrong with me/us? So, any haskellers in Minsk, Belarus? What about beer, coffee or co-hacking? I don't have solid idea how to organize an event, but I'm sure haskellers are interesting people, both personally and professionally. Thanks, Yuras

2 1

Re: [Haskell-cafe] Poll & plea: State of GUI & graphics libraries in Haskell
by Paul Liu 05 Oct '13

05 Oct '13

Thanks. I've just built GHC HEAD on Mac OS X Lion, and tested by installing libraries with --enable-shared and loading a GLFW program into GHCi. Using ghci -fno-ghci-sandbox, everything works great including closing and restarting GL window multiple times. Can't wait for the official release of GHC 7.8! On Tue, Oct 1, 2013 at 12:09 PM, Carter Schonwald <carter.schonwald(a)gmail.com> wrote: > thats the linker bug. > > the glfw stuff has been tested on ghc HEAD / 7.7 by folks on #haskell-game > in recent memory. GHCI + foreign libs should work fine now (modulo thread > local storage related thing). > > the historical element doesn't matter any more. > > To the best of my knowledge, all such issues should be gone. Anyone who > cares about making sure GHCI+ gui libs play nice, PLEASE test with HEAD. > > the better this issue is properly tested (which i believe it has been), the > more we can actually prevent it from happening. This requires people to test > with HEAD GHCi now, rather than doing archaeology. > > anyone who cares, please play with GHCI in HEAD. If your lib doesn't work > with ghci, please report a bug. It would be a new bug because it wont' be > the previous reasons it hasnt' worked. > > > tl;dr to the best of my knowledge this issue is resolved in HEAD. Test HEAD. > Help us make sure it stays resolved by testing HEAD. > > thanks > -Carter > > > > > On Tue, Oct 1, 2013 at 1:20 PM, Paul Liu <ninegua(a)gmail.com> wrote: >> >> I reported a problem with statically linked GLFW library on Mac OS X >> Lion in this thread: >> >> http://www.haskell.org/pipermail/haskell-cafe/2012-January/097355.html >> >> I do not know why this is broken on Mac OS X Lion, but not on Linux or >> Windows. There was an EnableGUI hack for GHC 7.2 (and previous >> versions) and OS X version before Lion, but it no longer works. So I'm >> not sure if it is OS X Lion, or GLFW, or GHC, or a combination of them >> that caused this problem. >> >> Regards, >> Paul Liu >> >> On Tue, Oct 1, 2013 at 7:04 AM, Carter Schonwald >> <carter.schonwald(a)gmail.com> wrote: >> > Hey simon, the two issues that have recurrently bit ghci interaction >> > with >> > foreign GUI libs are >> > 1) the ghci linker. This is fixed in head by now having ghci use the >> > system >> > linker >> > 2) some GUI libs require thread local state, and ghci has a flag for >> > that >> > 3) I'm not aware of anyone reporting newly broken libs wrt GUI bindings >> > when 7.6 rolled out. The only fix that's relevant to 7.8 is the >> > dylinker >> > bit, but that would have been a problem historically too. >> > >> > I believe a number of folks in #haskell-game have recently tested point >> > one. >> > (Though I should ask to double check) >> > >> > At the very least, I'm not aware of hearing of such a 7.6 specific ghci >> > breakage before. >> > >> > >> > On Tuesday, October 1, 2013, Simon Peyton-Jones wrote: >> >> >> >> Dear GHC devs >> >> >> >> >> >> >> >> See below (in red). I do not know the details of this, but it sounds >> >> like >> >> a pretty serious problem, and it used to work. Is whatever-it-is >> >> confirmed >> >> fixed in 7.8? Do we have a test that’ll trip if it breaks again? (I’m >> >> guessing that the latter might be hard.) >> >> >> >> >> >> >> >> Thanks >> >> >> >> >> >> >> >> Simon >> >> >> >> >> >> >> >> -----Original Message----- >> >> From: Haskell-Cafe [mailto:haskell-cafe-bounces@haskell.org] On Behalf >> >> Of >> >> Paul Liu >> >> Sent: 30 September 2013 07:18 >> >> To: Conal Elliott >> >> Cc: Haskell Cafe >> >> Subject: Re: [Haskell-cafe] Poll & plea: State of GUI & graphics >> >> libraries >> >> in Haskell >> >> >> >> >> >> >> >> Hi Conal, >> >> >> >> >> >> >> >> I wasn't able to make it to last Saturday's FARM track, but I think >> >> >> >> there was a good chance that Paul would have demonstrated his Euterpea >> >> >> >> music library, which includes a GUI interface (called MUI) written on >> >> >> >> top of GLFW. I wrote its initial implementation (around 2009?) with a >> >> >> >> monadic interface that let you wire together UI components with >> >> >> >> signals (I believe Dan later wrote an arrow interface, but I could be >> >> >> >> wrong). It was actually inspired by the ideas behind your Phooey UI >> >> >> >> library. It should be very easy to extract this part out as a >> >> >> >> standalone package if there is enough interest. >> >> >> >> >> >> >> >> The only issue with it (and all other UI libraries) is that it doesn't >> >> >> >> play nicely in GHCi. It used to work pretty well with GHC 7.2 and 7.4 >> >> >> >> on almost all platforms (Mac needs an extra hack), but GHC 7.6 broke >> >> >> >> Mac (and perhaps Windows too). GHC 7.8 supposedly should fix this >> >> >> >> problem. >> >> >> >> >> >> >> >> BTW, as also the author of the GLFW library on HackageDB, I've done >> >> >> >> barely minimal to keep this Haskell binding afloat. I'm actually >> >> >> >> leaning towards GLFW-b library, which is better maintained, and >> >> >> >> provides similar binding for GLFW C library but with a saner interface >> >> >> >> (no dependency on the OpenGL library, for example). If you don't need >> >> >> >> the two extra things that GLFW does (choice of either dynamic or >> >> >> >> static linking to GLFW C, and an embedded bitmap font), I suggest you >> >> >> >> try out GLFW-b if you are only looking for a think graphics layer with >> >> >> >> input+window+OpenGL. >> >> >> >> >> >> >> >> The only thing keeping GLFW-b from becoming a good foundation for a >> >> >> >> pure Haskell UI lib is IMHO the lack of a light-weight, >> >> >> >> cross-platform, and full-featured font rendering solution. I believe >> >> >> >> many other libraries (including Diagram) are having the same problem. >> >> >> >> >> >> >> >> >> >> >> >> On Thu, Sep 26, 2013 at 8:32 PM, Conal Elliott <conal(a)conal.net> wrote: >> >> >> >> > I'm polling to see whether there are will and expertise to reboot >> >> > graphics >> >> >> >> > and GUIs work in Haskell. I miss working on functional graphics and >> >> > GUIs >> >> > in >> >> >> >> > Haskell, as I've been blocked for several years (eight?) due to the >> >> > absence >> >> >> >> > of low-level foundation libraries having the following properties: >> >> >> >> > >> >> >> >> > * cross-platform, >> >> >> >> > * easily buildable, >> >> >> >> > * GHCi-friendly, and >> >> >> >> > * OpenGL-compatible. >> >> >> >> > >> >> >> >> > The last several times I tried Gtk2hs, I was unable to compile it on >> >> > my >> >> > Mac. >> >> >> >> > Years ago when I was able to compile, the GUIs looked and interacted >> >> > like a >> >> >> >> > Linux app, which made them awkward and upleasant to use. wxHaskell >> >> > (whose >> >> >> >> > API and visual appearance I prefered) has for years been incompatible >> >> > with >> >> >> >> > GHCi, in that the second time I open a top-level window, the host >> >> > process >> >> >> >> > (GHCi) dies abruptly. Since my GUI & graphics programs are often >> >> > one-liners, >> >> >> >> > and I tend to experiment a lot, using a full compilation greatly >> >> > thwarts >> >> > my >> >> >> >> > flow. For many years, I've thought that the situation would >> >> > eventually >> >> >> >> > improve, since I'm far from the only person who wants GUIs or >> >> > graphics >> >> > from >> >> >> >> > Haskell. >> >> >> >> > >> >> >> >> > About three years ago, I built a modern replacement of my old Pan and >> >> >> >> > V >> > >> > >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs(a)haskell.org >> > http://www.haskell.org/mailman/listinfo/ghc-devs >> > >> >> >> >> -- >> Regards, >> Paul Liu > > -- Regards, Paul Liu

8 12