[Haskell-cafe] Toy application advice wanted

Duncan Coutts duncan.coutts at worcester.oxford.ac.uk
Mon May 3 19:12:23 EDT 2004


On Mon, 2004-05-03 at 16:52, mikeb at manor.org wrote:
> The toy application I've "designed" for myself is a simple GUI-based app
> that can load a Sun .au format sound file, display its waveform in a
> window, perform some simple filtering, play the sound for the user, and
> then save the changed sound file back out to disk.  If I get familiar
> enough with the respective environments I'd like to add zooming in/out and
> scrolling to the waveform display.

Here's my positive experience with GUI programming in Haskell;
I've been hacking on gtk2hs recently - the Haskell bindings for Gtk+
2.x. Yesterday I wrote toy program as a demo. It's a viewer for GHC's
timing profile log files. It parses a log file, populates a tree view
with the data and allows you to vary a cut-off threshold on the data. It
took about 4hrs to write and comes to less than 250 lines of code in two
modules. The parsing is a bit slow (15sec to parse >850k log) because I
used my patented zero-optimisation(tm) technique. :-) There are plenty
of not-too difficult techniques for making the parsing go faster if you
care about performance. (eg use a lexer and parsec or happy)

If I were going to try and do your toy app I'd consider these things:
Haskell's standard IO facilities are primarily text-oriented and
designed for convenience rather than performance. If performance is
important I'd look at some of GHC's low-level IO facilities:
http://www.haskell.org/ghc/docs/latest/html/libraries/base/GHC.IO.html#v%3AslurpFile
Eg load the whole file into memory and then use the marshaling
facilities of Haskell's FFI to read the records out of your file. (I'm
guessing here that .au files are basically a binary file with a header
followed by an array of records)

For playing a sound file either pipe it to an external command line
player utility - see POpen for this, or you'll have to bind to some
existing C library that plays .au files. This would be harder (ie take
longer) but doable, see hsc2hs or c2hs for preprocessors that help with
creating bindings for C libraries.

For the GUI I'd obviously recommend Gtk+ and gtk2hs. If you need a
cross-patform GUI, there's wxHaskell - which also has a nicer mid-level
wrapper library at the moment. gtk2hs will allow you to use Glade which
makes designing the GUI much easier and quicker. For the waveform
display you can either draw directly into a DrawWindow or draw into a
Pixmap (an off-screen buffer) and then display the pixmap in a
DrawWindow or GtkImage widget.

> This application should allow me to see all kinds of different
> characteristics of the language/implementation, such as performance (how
> fast can the filter run), I/O (how fast can I load/save data to disk), OS
> interaction (how easy can I "play" the audio), user acceptance (how easy
> is it to do GUI programming) and of course the software engineering goals
> of modularity, correctness, and simplicity.

I'd say that modularity, correctness, and simplicity are Haskell's
strengths while low-level high performance bit shifting is not. No
doubt, Haskell would allow you to build elegant type-safe abstractions
for dealing with large binary files, but that's an investment that's
hard to justify for a prototype and getting good performance would
require careful thought.

Duncan



More information about the Haskell-Cafe mailing list