May 2004 - Haskell-Cafe

Audio signal processing in Haskell
by Henning Thielemann 02 Jul '04

02 Jul '04

As I can see a question similar to mine was already raised here: http://www.haskell.org/pipermail/glasgow-haskell-users/2004-February/006305… I also encountered the elegance that Haskell's laziness provides for signal processing. I use lists for the signals. With help of Haskore I put together a small song and it needed 5 minutes for rendering the quite simple music of about 30 seconds. Don't care about the exact numbers but I find it rather slow. What is the most promising strategy to speed up the computation without loosing the elegance of Haskell's lists? 1. Upgrading GHC from 6.0 to the current version? 2. Use of simplification rules? How can I find out what new rules may be useful? The several dumps that GHC can generate are a bit hard to understand. :-( Is there some more detailed information about what rules GHC already applies than what one can get with -ddump-simpl-stats and -ddump-rules? 3. More strictness? Is a custom list structure with strict entries and maybe with only one constructor (thus always infinite) a considerable alternative? This would disallow the use of lots of functions that deal with lists, including State monad functions. 4. A list of arrays? Then signal processes with feedback like an echo are much more difficult.

2 3

[Haskell-cafe] ANNOUNCE: Haskell Communities & Activities Report (6th ed., May 2004)
by Arthur van Leeuwen 25 May '04

25 May '04

Just a bit more than half a year after the previous edition, I am pleased to announce on behalf of the many contributers that the Haskell Communities and Activities Report (6th edition, May 2004) http://www.haskell.org/communities/ is now available from the Haskell Communities home page in several formats: PDF, for screenreading as well as printing, HTML, for those of you who prefer not to deal with plugins or external viewers, and PostScript, for those of you who have nice quick printers that do not grok PDF. Many thanks go to all the people that contributed to this report, both directly, by sending in descriptions, and indirectly, by doing all the interesting things that are reported. I hope you will find it as interesting a read as we did. If you haven't encountered the Haskell Communities and Activities Reports before, you may like to know that the first of these reports was published in November 2001. Their goal is to improve the communication between the increasingly diverse groups, projects and individuals working on, with, or inspired by Haskell. The idea behind these reports is simple: Every six months, a call goes out to all of you enjoying Haskell to contribute brief summaries of your own area of work. Many of you respond (eagerly, unprompted, and well in time for the actual deadline ;) ) to the call. The editor collects all the contributions into a single report and feeds that back to the community When we try for the next update, six months from now, you might want to report on your own work, project, research area or group as well. So, please put the following into your diaries now: ---------------------------------------- End of October 2004: target deadline for contributions to the October 2004 edition of the HC&A Report ---------------------------------------- Unfortunately, many Haskellers working on interesting projects are so busy with their work that they seem to have lost the time to follow the Haskell related mailing lists and newsgroups, and have trouble even finding time to report on their work. If you are a member, user or friend of a project so burdened, please find someone willing to make time to report and ask them to `register' with the editor for a simple e-mail reminder in the middle of October (you could point us to them as well, and we can then politely ask if they want to contribute, but it might work better if you do the initial asking). Ofcourse, they will still have to find the ten to fifteen minutes to draw up their report, but maybe we can increase our coverage of all that is going on in the community. Enjoy, communicate, and program! Arthur van Leeuwen -- /\ / | arthurvl+hcar(a)cs.uu.nl | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt / \/__ | you can dare to be yourself | Dance like there's nobody watching

1 0

[Haskell-cafe] Solving differential equations in terms of power series
by Henning Thielemann 24 May '04

24 May '04

I've attached a Haskell module demonstrating the beauty of solving ordinary differential equations in terms of power series. A power series is expressed by the (infinite) list of its coefficients. What do you think about that?

2 1

Re: [Haskell-cafe] Re: Lazy XML handling
by MR K P SCHUPKE 24 May '04

24 May '04

>The standard representation should be a tree datatype Why not separate the parser and tree builder, have the parser stream the tags out, and define the tag stream as the interface to a DOM builder... parse :: String -> [(XmlTreeDepth,XmlElement)] buildDOM :: [(XmlTreeDepth,XmlElement)] -> DOM Thats how I would do it anyway. I appreciate the comments about efficency, I was really talking about simplicity. The algorithms on the steam can be quite simple, and hence avoid bugs. I would still want to dispense with the DOM, which if you think about the system thus: Parser -> [stream] -> DomBuilder -> DOM - operations on DOM You can push the operations on the dom via a structural transformation back through the DomBuilder, such that they operate directly on the stream... In other words the user composes the functions as if they are operating on a real DOM... only the DOM is never constructed and the operations are applied direct to the stream output of the parser. make sense? Keean.

2 1

RE: [Haskell-cafe] Working with Network
by Niklas Broberg 23 May '04

23 May '04

Marco Righele wrote: >Ideally each session would work more or less as follows: > >do (hdl,hn,pn) <- accept socket > text <- hGetContents hdl > inputs <- parse text > replies <- sequence $ map reply inputs > sequence $ map (hPrint hdl) replies > ... > >Where parse and reply are IO functions that produce and consume some kind >of higher level representation of the text that the client sent. >Of course this won't work because the code will first try to read all the >input and then to write back all the replies. I think that if I had two >different handles for input and output I wouldn't have this problem, am I >right ? Is there a way to handle such situation without having to read the >input text in chunks ? This for example would allow me to use a library >like Parsec to parse the input (that looks like works on string and not on >handles) It looks like the lazy read problem rears its ugly head again. =) Try the following: do (hdl,hn,pn) <- accept socket text <- hGetContents hdl if text == text then return () else return () inputs <- parse text replies <- sequence $ map reply inputs sequence $ map (hPrint hdl) replies ... The conditional will force 'text' to be read in full, which will free the handle for writing. /Niklas _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

1 0

Working with Network
by Marco Righele 22 May '04

22 May '04

Hello everybody. I'm trying to learn to use Sockets with Haskell, so I started playing with a small app that waits for a client and start an interactive session, i.e. waits for some input, answers to it, wait for some more etc. Ideally each session would work more or less as follows: do (hdl,hn,pn) <- accept socket text <- hGetContents hdl inputs <- parse text replies <- sequence $ map reply inputs sequence $ map (hPrint hdl) replies ... Where parse and reply are IO functions that produce and consume some kind of higher level representation of the text that the client sent. Of course this won't work because the code will first try to read all the input and then to write back all the replies. I think that if I had two different handles for input and output I wouldn't have this problem, am I right ? Is there a way to handle such situation without having to read the input text in chunks ? This for example would allow me to use a library like Parsec to parse the input (that looks like works on string and not on handles) Thanks, Marco

1 0

Neural Nets
by schrum2＠southwestern.edu 22 May '04

22 May '04

Hello all. I was wondering if anyone knows of ways to implement neural nets in Haskell, and if there are any sites or projects that you could direct me to. I'm specifically interested in how to represent the neural net in Haskell, and then how to represent the neural net as genes in a genetic algorithm.

2 1

Re: [Haskell-cafe] Re: Lazy XML handling
by Niklas Broberg 21 May '04

21 May '04

MR K P Shupke wrote: >Can you give me an example where processing HAS to be in a different order? No, but I can give an example where a list based encoding is less sufficient. I'm coming from a completely different view here, namely that of using Haskell not to query or transform but to create XML. I'm currently in a project[1] trying to fix a working implementation of Haskell Server Pages[2], i.e. using Haskell as a server-side scripting language for dynamic webpages. Clearly the most used mode of operation in this setting is constructing an XML tree rather than querying or transforming an existing one. With this in mind, the list based encoding would be less efficient than a treelike datatype. Building the XML tree is likely to be done bottom-up, and adding a parent to a subtree would be O(n) with a list, but O(1) with a tree datatype. Building a whole tree from the bottom up is O(n^2) for a list, but O(n) for the tree datatype. MR K P Shupke wrote: >The nested lists does not allow any extra flexibility in traversal, at the >cost of >greater complexity. The one case it is simpler is if you want to look up a >single >node by its 'tree address' - This is more complex with the list-rep, as you >have to count nodes at a given level, skipping irrelevent nodes... The fact that the list based representation is indeed more complex is in my opinion a clear indication that it should not be the standard. Compare this to Haskell strings where the standard is the simple but ineffective [Char], but where there is another more efficient representation, PackedString, if you really need it. Simplicity and ease of understanding is not to be taken lightly. By using a tree datatype representation you also get pattern matching directly on the structure of the tree, a very useful feature to have. MR K P Shupke wrote: >The list rep is very good at data extraction, if you want to extract a >sub-tree >of a given type you just ignore all tags until you find one of the correct >type, then output all tags until the depth returns to the level of the >initial >tag. That might possibly be a programmatic advantage, though I don't see how it would be more difficult with a tree datatype. In any case it is no more efficient, both are O(n). As far as I can tell there is no single area where the list representation would outperform a tree datatype, other than the special case of lazy streaming. My suggestions are thus: The standard representation should be a tree datatype, both because it is more general and efficiently supports a wide range of operation modes (construction, querying, transformation, rendering), and also because that is what lies closest to the intuition of XML. However, the ability to stream large XML structures lazily is clearly useful and is difficult to achieve using a tree datatype. Why not add it as a specialisation? The standard representation would be a datatype XML living in Data.XML (or similar), and the specialized would be a type XMLStream living in Data.XML.Stream. There should of course also be functions to convert between the types. Comment away, /Niklas [1] http://www.dtek.chalmers.se/~d00nibro/hsp/ [2] http://www.research.microsoft.com/~emeijer/Papers/HSP.pdf _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

1 0

GHC and libc
by Per Larsson 21 May '04

21 May '04

When I compile my haskell program (on a linux machine) with GHC and send it to a colleague he can't run it because he has a somewhat older version of libc. Is there a GHC switch that I have missed that enables you to statically link the parts of libc that is used by the haskell program? Alternatively have someone other tips for solving this problem? (I'm reluctant to force all my colleagues to install GHC, because of the size and long installation time, and I can't let them use Hugs because I've used some GHC-only features in my program.) Per Larsson

5 6

c2hs and gtk+hs problem
by scott west 18 May '04

18 May '04

Hello all, I've recently attempted to get the gtk+hs bindings operational, with evidently no success. They both compile fine, but when trying to "make all" the examples in the gtk+hs tree, it gives up with: /usr/local/lib/c2hs-0.12.0/ghc6/libc2hs.a(C2HS.o)(.text+0x32): In function `__stginit_C2HS_': : undefined reference to `__stginit_CForeign_' /usr/local/lib/c2hs-0.12.0/ghc6/libc2hs.a(C2HSBase.o)(.text+0x28): In function `__stginit_C2HSBase_': : undefined reference to `__stginit_MarshalUtils_' /usr/local/lib/c2hs-0.12.0/ghc6/libc2hs.a(C2HSMarsh.o)(.text+0x32): In function `__stginit_C2HSMarsh_': : undefined reference to `__stginit_CString_' /usr/local/lib/c2hs-0.12.0/ghc6/libc2hs.a(C2HSMarsh.o)(.text+0x3c): In function `__stginit_C2HSMarsh_': : undefined reference to `__stginit_MarshalUtils_' /usr/local/lib/c2hs-0.12.0/ghc6/libc2hs.a(C2HSMarsh.o)(.text+0x50): In function `__stginit_C2HSMarsh_': : undefined reference to `__stginit_MarshalAlloc_' /usr/local/lib/c2hs-0.12.0/ghc6/libc2hs.a(C2HSMarsh.o)(.text+0x5a): In function `__stginit_C2HSMarsh_': : undefined reference to `__stginit_Ptr_' /usr/local/lib/c2hs-0.12.0/ghc6/libc2hs.a(NewStorable.o)(.text+0x28): In function `__stginit_NewStorable_': : undefined reference to `__stginit_Storable_' collect2: ld returned 1 exit status Does anyone have any possible ways to resolve this? Thanks for any help!! Regards, Scott

4 4