- Haskell-Cafe - Haskell.org

Consequences of implementing a library in Haskell for C consumption?
by Justin Bailey 04 Sep '08

04 Sep '08

I am thinking of writing a simple library in Haskell which would be useful in a number of different scenarios, and not always with programs written in Haskell. That makes me think the library should be C-compatible and able to link with C programs. Reading over chapter 9 of the GHC manual ("Foreign function interface"), it seems simple to do. However, what are the consequences of such an implementation? Would any program using my library need to link the entire GHC runtime? The library will not expose any higher-order functions or other business. It would be straightforward but tedious to write in C, which is why I'd rather use Haskell. Thanks in advance for any thoughts. Justin

2 1

Parsec 3 Description
by John Van Enk 04 Sep '08

04 Sep '08

I'm looking for a document describing the differences between Parsec 3 and Parsec 2. My google-foo must be off because I can't seem to find one. Does any one know where to find that information? -- /jve

3 4

Compiler's bane
by Andrew Coppin 04 Sep '08

04 Sep '08

Hi guys. I'm writing a simple interpretter for a small extended-lambda-calculus sort of language. And I'd just like to say... RECURSIVE LET-BINDS! GAAAAH!!! >_< No other part of the program has consumed nearly as much brain power as me trying to figure out when it is and isn't safe to replace a variable with its RHS. To illustrate: let x = f x; y = 5 in x y A simple-minded interpretter might try to replace every occurrance of "x" with "f x". This yields let y = 5 in (f x) y ...and x is now a free variable. OOPS! Trying to tease out exactly under which conditions you can and cannot perform the substitution is utterly maddening. Since this is a Haskell mailing list and as such it is populated by vast numbers of people with PhDs and so forth... does anybody happen to know the *correct* solution to this conundrum? Before I become clinically insane...? o_O By the way... To all those people who work on projects like GHC and so on, who have to get this stuff right "for real": you have my infinite respect!

10 29

[POPL logo design contest]
by Don Stewart 04 Sep '08

04 Sep '08

This sounds relevant to our interests... ----- Forwarded message from Swarat Chaudhuri <swarat(a)cse.psu.edu> ----- Date: Thu, 04 Sep 2008 09:13:55 -0400 From: Swarat Chaudhuri <swarat(a)cse.psu.edu> To: types-list(a)lists.seas.upenn.edu Subject: [TYPES] POPL logo design contest [ The Types Forum, http://lists.seas.upenn.edu/mailman/listinfo/types-list ] Dear POPL community members: We know that you are all holding your breath for POPL 2009; here's some diversion to take your mind off the wait. We are planning to select a logo for POPL---after all, if the Olympics can have one, why not us? Accordingly, we announce the first-ever Contest on POPL Logo Design and Implementation (not to be confused with the other, gentler PLDI). Participants should send submissions in jpg, gif or png formats to Swarat Chaudhuri (swarat at cse.psu.edu) by November 20, 2008. The submission should contain: 1) A logo that doesn't mention the year (e.g., 2010) of the conference. 2) Logos mentioning the years 2010, 2011, and 2012. The contest will be judged by: * Luca Cardelli (Microsoft Cambridge) * Benjamin Pierce (Penn) * Shriram Krishnamurthi (Brown) We do not currently need high-resolution images, but will request them from the winner(s). From 2010 on, the logo will appear on POPL's webpage---in addition to the winning logo, the POPL 2010 webpage will also link to any other logo the judges find noteworthy. The winner(s) and runners-up will be presented t-shirts and cookies during the PC Chair's presentation at POPL 2009. So here's to citius, altius, etc. Get your design juices flowing! Best, Swarat Chaudhuri (Penn State) Publicity chair POPL 2010-2012 ----- End forwarded message -----

1 0

Haskell and i18n (aka gettext) support
by Gour 04 Sep '08

04 Sep '08

Dear Haskellers, Some time ago the question was asked on gtk2hs mailing list about how to work with *.po files, i.e. how to make Haskell program i18n-aware. (see http://thread.gmane.org/gmane.comp.lang.haskell.gtk2hs/592) The answer was that Gtk2hs does not have gettext support (http://article.gmane.org/gmane.comp.lang.haskell.gtk2hs/593) but that it is something which is needed (http://article.gmane.org/gmane.comp.lang.haskell.gtk2hs/598) but it's not clear how to do it. As potential 'solution the 'i18n' package was mentioned (http://hackage.haskell.org/cgi-bin/hackage-scripts/package/i18n) with the remark that its API is not the most beautiful. Moreover, by looking at i18n's *.cabal file one can see it is labelled as 'experimental'. Moreover, if one inspects GNU gettext manual one can see the list of languages with the explanations how to make the program i18n-ready. The list is, unfortunately, without Haskell: * C: C, C++, Objective C * sh: sh - Shell Script * bash: bash - Bourne-Again Shell Script * Python: Python * Common Lisp: GNU clisp - Common Lisp * clisp C: GNU clisp C sources * Emacs Lisp: Emacs Lisp * librep: librep * Scheme: GNU guile - Scheme * Smalltalk: GNU Smalltalk * Java: Java * C#: C# * gawk: GNU awk * Pascal: Pascal - Free Pascal Compiler * wxWidgets: wxWidgets library * YCP: YCP - YaST2 scripting language * Tcl: Tcl - Tk's scripting language * Perl: Perl * PHP: PHP Hypertext Preprocessor * Pike: Pike * GCC-source: GNU Compiler Collection sources Real World Haskell book is at the door and it will bring army of new Haskell programmers to find out that Haskell misses one of the important items in its "battery set". :-( So, we think that i18n issue or proper gettext support should have a stable and well documented implementation and has to be part of "batteries included" or Haskell Platform (http://www.haskell.org/haskellwiki/Haskell_Platform) However, don't ask me 'how' :-D We got some hints on the IRC yesterday, but considering it is important issue for the whole Haskell community, we are bringing it here so that smarter and more skillful (than ourselves) souls can discuss it. I hope you are not seeing it as critique of the Haskell, but rather as attempt to improve our beloved language with the feature necessary to be included in the arsenal of every general programming language. Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D ----------------------------------------------------------------

2 1

Research language vs. professional language
by Ryan Ingram 04 Sep '08

04 Sep '08

Jonathan, I think we are going to end up just disagreeing on this subject, but I'd like to point out the reasons why we disagree. On Sun, Aug 31, 2008 at 7:27 PM, Jonathan Cast <jonathanccast(a)fastmail.fm> wrote: > This concept of `day-to-day work' is a curious one. Haskell is not a > mature language, and probably shouldn't ever be one. I see where you are coming from here, but I think that train has already started and can't be stopped. I find Haskell interesting as a professional programmer for these four reasons: it's pure, it's functional, it's lazy, and it's got a great compiler. I don't know of any other "mature" language that can fill these shoes; Haskell is the most mature of them. If I'm missing another language that fits my requirements and would be better for day-to-day programming, let me know! The serious competitors I can see are Clean (Hackage blows away anything I've seen from that community) and O'CaML, which is neither pure nor lazy. Meanwhile, Haskell is getting more suitable for regular "professional" use every day. Look at the success of Hackage and the soon-to-be-published "Real World Haskell" book for evidence. Haskell solves many of the problems I have with existing languages today, and makes me a better programmer at the same time. > There will always be new discoveries in purely functional programming, > and as the art advances, features like this ad-hoc overloading hack > (and ACIO) will become obsolete and have to be thrown over-board. This is a good point. However, it seems to me that the pure programming language research is moving towards dependently typed languages, and that progress in Haskell has been more application-side; transactional memory and data-parallel, along with research on various fusion techniques, for example. I also think ACIO is a good theoretical starting point for research on what initialization means, and has potential for work to influence the commutative monads problem in general which could improve the syntax and number of lines of code devoted to working around the verbosity of effectful computations in Haskell. > I'd rather (much rather!) people concerned with day-to-day programming > for writing programs people actually use incorporate Haskell's features > into other, more practical, languages (as those who *actually* care about > such things are) rather than incorporating features from day-to-day > production languages into Haskell. This is already happening, of course; I think ML is going to become pure soon, although I don't think it will ever be non-strict. And I predict that within the next few years, lots of languages will be leaning heavily on the concurrency research that is going on in Haskell right now. But Haskell's community is also growing and becoming more results-oriented. If you want to blame someone for this, Don Stewart is probably your guy :) I'm just one of the johnny-come-latelies who is realizing what a great tool Simon and the rest of the ghc team has built. So, my question for you is: if Haskell is a research language, what direction should it be taking? What changes should be happening at the language (not the library) level that are in the interests of improving the state-of-the-art in functional programming? My goal is to make it not be a joke when I go to work and suggest that we use Haskell for part of our next project. What is yours? -- ryan

7 7

Haskell audio libraries & audio formats
by Eric Kidd 03 Sep '08

03 Sep '08

Greetings, Haskell folks! I'm working on a toy program for drum synthesis. This has lead me to explore the various sound-related libraries in Hackage. Along the way, I've learned several things: 1. There's a lot of Haskell sound libraries, but no agreement on how to represent buffers of audio data. 2. Some of the most useful sound libraries aren't listed in Hackage's "Sound" section, including HCodecs, SDL-mixer and hogg. 3. The Haskell OpenAL bindings are great, but ALUT has been removed from MacOS 10.5. Of course, a pure-Haskell version of ALUT would be pretty easy to write, and it could be used as a fallback. 4. '[[a]]' is _not_ a good representation for multi-channel audio data. Manipulating even 10 seconds of audio is noticeably slow. 5. HCodecs is probably the best library for reading WAVE files. It uses 'DiffUArray Int a' to represent audio data, and not '[[a]]'. It also supports MIDI and SoundFont, which is quite handy. 6. YampaSynth looks really cool, and it might be possible to turn it into a reusable MIDI synthesizer library for use with HCodecs. This would be extremely useful: it would provide a basis for all kinds of crazy MIDI-based programming in Haskell. At the end of this e-mail, you can find a list of Haskell sound libraries and their supported audio formats. What would the ideal Haskell sound API look like? Personally, I would love to see: a. Something like HCodecs's Data.Audio as the basic sound format. Data.Audio is an array-based API, and it supports converting between a wide range of common sample formats. I don't know how fast this is, but it already exists, and it's used by YampaSynth. b. OpenAL for sound playback, with a portable version of ALUT. This may require writing a pure-Haskell version of ALUT. c. Utility functions to convert Data.Audio to OpenAL.AL.Buffer. d. An easy-to-use API for audio processing. It might be possible to start with something like Jack's 'mainMono' and 'mainStereo' functions, which map a function over an audio stream. Other nice-to-have features might include: e. A standard MIDI format, based on either the HCodecs package or the midi package. (HCodecs is used by YampaSynth, and the midi package is used by alsa-midi.) f. A modular version of YampaSynth which can convert MIDI data structures into Data.Audio values. It looks like Haskell could be a really sweet audio programming environment with just a bit of integration work. What do folks think? Are there other libraries I should look at more closely? Other features that should be included in an ideal audio API? Thank you for your advice and feedback! Cheers, Eric Haskell audio libraries Reading and writing sound files: HCodecs: (Audible a) => DiffUArray Int a hsndfile: MArray with Float and Double HSoundFile: [[Double]] ALUT: OpenAL.AL.Buffer WAVE: [[Int32]] Playing sounds: OpenAL: Ptr UInt8, Ptr Int16, 1-N channels SDL-mixer: ForeignPtr ChunkStruct, ForeignPtr MusicStruct Sound processing libraries: dsp: Array a, [a] jack: Operates via mapping functions mainMono :: (CFloat -> IO CFloat) -> IO () mainStereo :: ((CFloat, CFloat) -> IO (CFloat, CFloat)) -> IO () MIDI-based: HCodecs: Reads and writes MIDI files midi: Reads and writes MIDI files alsa-midi: Uses midi library YampaSynth: Stand-alone program Special-purpose APIs only (FFIs, etc.): hCsound: CsoundPtr hsc3: UGen No public sound-buffer API: hbeat: The relevant source files are missing! hogg: Very low-level API for Ogg internals only libmpd: No sound buffer API sonic-visualizer: No sound buffer API truelevel: Stand-alone program (uses WAVE) wavconvert: Stand-alone program

6 14

analyzing modules import/export
by Han Joosten 03 Sep '08

03 Sep '08

I am currently involved with a Haskell project to create a toolset for a formal language. The toolset contains a parser, a typechecker and s range of other features. The Haskell code currently consists of about 20 modules. I am new in the project, and my impression is that a lot of code does not reside in the proper module. I would like to be able to get a good feeling in how the modules are structured, and how they are consumed by other modules. This would enable me to clean up a little bit. I use eclipsefp. Do you know of any way to get insight of the structure of modules? is any tooling available? Any suggestions would help a lot! Thanx for reading. Han Joosten -- View this message in context: http://www.nabble.com/analyzing-modules-import-export-tp19297359p19297359.h… Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

2 1

joyent, solaris and ghc
by Jason Dusek 03 Sep '08

03 Sep '08

Is anyone on the list using GHC on Joyent's Solaris (x86_64) setup? If so, I would love to know whether it was easy/hard and what the process is. -- _jsn

2 1

Re: [Haskell-cafe] Is it usual to read a Maybe (IORef a) ?
by minh thu 03 Sep '08

03 Sep '08

2008/9/3 Lennart Augustsson <lennart.augustsson(a)gmail.com>: > I think you should think about why your application needs IORef at all. Do > you really need mutation? And why isn't STRef good enough. Using IORef is > really the last resort. This is for an interactive application (3D mesh editing, the data structure is the half edge structure). So the user can add points, edges, faces, delete them, ... Thu

1 0