August 2010 - Haskell-Cafe

What is <-
by michael rice 08 Aug '10

08 Aug '10

What is <- ? Couldn't find anything on Hoogle. 1) main = do x <- getLine -- get the value from the IO monad putStrLn $ "You typed: " ++ x 2) pythags = do z <- [1..] --get the value from the List monad? x <- [1..z] y <- [x..z] guard (x^2 + y^2 == z^2) return (x, y, z) From: http://en.wikibooks.org/wiki/Haskell/Syntactic_sugar Do and proc notation Sweet Unsweet Monadic binding do x <- getLIne getLine >>= \x -> putStrLn $ "You typed: " ++ x putStrLn $ "You typed: " ++ x So, Example 2 desugared becomes... [1..] >== \z -> ? Michael

7 9

Combining Gtk2hs and Fieldtrip
by Herng Yi Cheng 08 Aug '10

08 Aug '10

Recently I wrote a 3D graphics viewer using Gtk2hs and Cairo, and it works ok, aside from the fact that it got quite slow when it got to displaying about 1000 polygons. It works something like this: The three-dimensional coordinates of polygons are given, and the program sorts the polygons using a BSP Tree (following the Painter's Algorithm), then it projects the polygons onto the plane of vision and renders each polygon to the screen using Cairo. After some investigation, I realised that my bottleneck was the rendering of polygons, but I could not speed up the rendering using parallel programming since the rendering order is crucial in the Painter's Algorithm. Even if I switched to an algorithm based on Hidden Surface Removal so I could render all my "obscured" polygons at once, Gtk2hs "is single threaded and its functions cannot be called from other threads". Then I heard about FieldTrip, which uses the GPU to process rendering efficiently. I decided to switch to using FieldTrip in conjunction with Gtk2hs to write applications, but it doesn't seem that easy because (i) there doesn't seem to be any version of GHC where Gtk2hs, Glade and Fieldtrip can work together on Windows and (ii) unlike Cairo, there is no Gtk2hs support for Fieldtrip in the sense that there are no Gtk2hs functions that render FieldTrip output to a Gtk2hs widget, like the DrawWindow. The latter would mean that Gtk2hs can't interact easily with FieldTrip. I really like Gtk2hs because it is very comprehensive and its interface can be designed using Glade. Does anyone know if there is a project linking Gtk2hs and FieldTrip? Otherwise, does anyone know if user interfaces can be written using Reactive (since it's linked to FieldTrip) with the usual functionality (e.g. menus, buttons, FieldTrip display reacting to mouseclicks etc)? If that is possible then I might have to switch to Reactive, but I'd miss Glade a lot :) regards, Herng Yi

3 3

lambdacats
by Tony Morris 08 Aug '10

08 Aug '10

Hello, does anyone happen to have the lambdacats page cached? The domain ( arcanux.org) and server have disappeared and the wayback machine doesn't have the images. -- Tony Morris http://tmorris.net/

10 16

Music-related
by Johann Bach 07 Aug '10

07 Aug '10

Midi files or music exported by the typical music editor is "expressionless." A *human* would play that music with slight tempo variations, subtle accents... some notes would be overlapped in time slightly, some separated in time. I want a program that starts with a plain midi file, then via a domain-specific language lets me describe nuances of expression. (Aside: this is mostly an experiment done for curiosity and an excuse to write Haskell code. As a practical matter, since I already play some piano and I am working on improving my music imagination, it makes more sense to put time into music practice and not programming. But hey, I don't always make sense.) Nuances include - stretching or shrinking small units of time, for example single beats within a measure - inserting pauses before or after a beat, or half-beat, or other small unit of time - changing how much sequential notes overlap (in time) or are separated. Be able to do this over a range of time - similar to previous: over a range of time, make notes overlap in time, and vary that overlap from a larger amount to a smaller amount - accenting (making slightly louder) notes at a specific time - put in a crescendo (gradually louder) or decrescendo (gradually softer) over a span of time Examples: stretch time between beats 3 and 4, measure 7: m7 [ 3 --> 4 time:+105% ] Change overlap of beat 3 to following beat by increasing it 100 ms: m7 [ 3 overlap:+100] Over the range of beats 1 to 4, stepping by 1/2 beat, gradually increase the overlap from 100 ms to 200ms: m7 [3 --> 4 (step 1/2) overlap:+100 --> +200] It would be useful to define patterns that are used repetitively. define patternFoo [ 3 --> 4 time:+105% 3 overlap: +100 3 --> 4 (step 1/2) overlap:+100 --> +200 ] Then, m7 [ patternFoo ] Often music has a hierarchy of expressive elements: there is some larger, basic expressive pattern, while individual measures deviate slightly from that. So it is useful to invoke a pattern, then use the language to describe additional changes: m7 [ patternFoo 1 --> 2 overlap:+50 ] In this case, patternFoo already defines an "overlap value" for beat 1, so the additional mention of overlap here is *summed* with the existing value. I want to solicit suggests for the basic data structure to represent the expression descriptors. First, note the job of the software in translating a "flat" midi file into an expressive one can be expressed like this: - For every note in the midi file - find out what overlap applies to that note - find out what dynamic changes apply to that note - find out what time the note occurs at - etc. - finally compute the note's actually begin time, end time, and dynamic So the basic problem to solve is: given a list of expressive element descriptors, and the begin time of a note (specified as a measure and beat), figure out which descriptors are "in effect" at the given time, and sum them. Let's look just at descriptors that stretch or shrink time. Let's say that for measure 7, we have the following two descriptors present: - 1 --> 2 1/2 time:+110% - 2 --> 2 2/3 time:+120% Note: 2 1/2 is "two and a half", 2 2/3 is "two and two-thirds." They overlap in time. I wonder what is the best form to store this information in order to facilitate translating a note? I'm thinking of this: each descriptor becomes a pair of elements: an "on" element and an "off" element. - beat 1: time: +110 ON - beat 2: time: +120 ON - beat 2 1/2: time: +110 OFF - beat 2 2/3: time: +120 OFF For a note at beat X, you run though this list of on/off elements, tracking the total changes to elements like 'time', until you reach beat X.

2 1

Trying to statically link Gtk2Hs application (Windows XP, network drive)
by Peter Schmitz 07 Aug '10

07 Aug '10

In [Haskell-beginners], please see: http://www.haskell.org/pipermail/beginners/2010-August/004949.html Please reply to [Haskell-beginners]; thanks much. -- Peter

1 0

finding out which gcc is hard-coded into a ghc?
by Günther Schmidt 07 Aug '10

07 Aug '10

Hello, how can I find out which gcc a ghc is hard-coded to use and is it possible to override it? Günther

4 3

Haddock New Look Survey results
by Mark Lentczner 06 Aug '10

06 Aug '10

Thank you to all who took the Haddock New Look Survey. We got a 161 responses. Some graphs of the results can be found here: http://www.ozonehouse.com/mark/snap-xhtml/Haddock-Survey-Summary.pdf I've read through all of the comments, and I'd like to share some initial thoughts with you: • Source links are indeed still supported in Haddock, I just happened to generate those sample pages with it turned off. Sorry for any confusion. The functionality remains exactly like it is in Haddock today. • I also failed to turn off all the "alternate style" bits on the index page, and many of you found it, explored the other styles, and then wondered why it failed on the module pages. I had intended for the survey to just give pages in the new style, and missed updating the index page. In the new Haddock, you can specify which "themes" you want to render your documentation with. If you include more than one, the pages have a "style switcher" menu added. The default themes that will come with Haddock include "Classic" which is a pretty faithful recreation of the current look. • Many great suggestions were made about ways to improve the UI experience of Synopsis drawer. Of course, the web is hardly a full featured UI framework, and to implement many of them we would have to decide to move to a much larger JavaScript framework. At present, Haddock attempts to use JavaScript very lightly, and only needs one small .js file. I think we are planning on keeping it that way for now. • Several people mentioned that perhaps we should have "user preferences" for things like where the Synopsis section goes. This is possible (the "style switcher" menu above uses such a preference), but know that a page can only set a cookie for a site. So if we do such things, they will stick per site, and users will have to choose their preference for each new site of Haddock docs they browse to. Fortunately, all of Hackage would count as one site, as does your local machine, and those two settings probably cover the bulk one's use. There were many many good suggestions, reported problems, and observations among the comments. I'm pulling together a short of list with the Haddock team of high priority changes based on these to be completed before the first release. To be sure, this will include: - fixing the layout issues on Firefox & Chrome - improving the expanding/collapsing behavior in module lists The most difficult issue is how to handle the Synopsis. As evident both from the multiple choice question in the survey, and from the comments, there is no clear consensus. While 2/3rds of you like the Synopsis drawer, there is a wide range of how it should look and operate. Another 1/5th want it back where it was, in-line with the page. There were many other suggestions as well. I'm going to go have to spend some time mulling what to do. Finally, thanks for the huge amount of positive feedback. When working on open source, often on speculation that it is what the community will want, it is really great to hear that you've done good! I realize that there is no way that such a change as this can please everyone 100%, but I'm glad to see that we are, on the whole, people are really happy with the work. - Mark Mark Lentczner http://www.ozonehouse.com/mark/ mark(a)glyphic.com irc: mtnviewmark

1 0

Re: using Network.CGI
by Anders Kaseorg 06 Aug '10

06 Aug '10

On Fri, 6 Aug 2010, Andrew U. Frank wrote: > i think this limits what network.cgi can be used for: it will work only > on systems, where the output from the ghc can execute. That’s not a limitation of Network.CGI; it’s just the way CGI always works, no matter what language you use. http://en.wikipedia.org/wiki/Server-side_scripting > specifically, this means, i cannot move the executable to an android > mobile phone and use it there (assuming that there is a web server, e.g. > i-jetty, which understands cgi (does it?)). is this correct? You’d need a Haskell compiler that targets Android; I don’t know whether such a thing exists yet. (Of course, keep in mind that if the CGI script is running on another computer, such as <http://andersk.mit.edu/greet.cgi> , you will still be able to visit it and use it from a browser running on Android. That’s the point of CGI; only the server needs to know how to run the code.) Anders

1 0

Does Hackage have a connection to some SFT package (Significant FFT coefficients) ...
by caseyh＠istar.ca 06 Aug '10

06 Aug '10

Does Hackage have a connection to some SFT package (Significant FFT coefficients) and/or can one get the SFT from FFTW without generating all the coefficients?

1 0

real-time audio processing [Was: can Haskell do everyting as we want?]
by Stephen Sinclair 06 Aug '10

06 Aug '10

On Aug 3, 8:31 pm, Jeremy Shaw <jer...(a)n-heptane.com> wrote: > The only area I have had any trouble with Haskell is doing realtime > music synthesis. And only because the garbage collector is not > realtime friendly. That is not unfixable though. However, I am > thinking that the best way to do realtime synthesis with Haskell is to > use it to create a DSL that uses LLVM to create code at runtime so > that the realtime code is outside the scope of the normal RTS and > garbage collector. I'm also very interested in this topic---how to apply a general- purpose functional language to real-time needs, even if it is in a domain-specific way. Indeed, it mostly comes down to memory management and the fact that functional concepts like closures and laziness require a lot of dynamic allocation and garbage collection. Certainly, one solution is to provide a real-time-friendly memory manager. However, it's interesting to notice that, as proven by FAUST [1], a huge amount of DSP algorithms can be expressed functionally in a real- time-compatible way by describing them as static diagrams of connected blocks. These can be efficiently compiled to imperative code with no dynamic memory allocation required. So yes, if such a language were available as an embedded DSL in Haskell (one effort can be found here [2]), it could be generated at run-time using LLVM and called out to. Alternatively, it would be very cool if it were possible to generate code statically at compile time, just like in FAUST. I can imagine this being very useful, especially if it could be generalized to operate on datatypes other than floating points, and had easy access to data structures provided by non-RT portions of the code. If there are mutability requirements, it could be made to run in the ST monad with a pre-allocated workspace. Of course _modifying_ such structures at run-time is always a dynamic thing by definition, although there is the possibility of dynamically generating a replacement block diagram while an one existing one runs, and using an atomic pointer swap to switch them without causing interruptions. In any case, as far as I know the only thing in the way is that it's impossible to tell GHC to compile a section of code in such as way as to guarantee avoidance of memory management. Compilers and runtime- systems always seem to be either RT- or non-RT-friendly, but never seem to support the idea of code *portions* that have differing requirements. My point is, RT code _can_ be expressed functionally, even if the RT-ness imposes certain expressivity restrictions. It would be very cool to be able to mark sections of code as following such a "sub-language" and be guaranteed that the compiler will generate GC-free code for a particular function, if possible, or otherwise fail. Even if such a sub-language were no more expressive than C, it would be nice to be able to write it in Haskell instead of dropping down to C, so that data can be easily shared with non-RT parts, and Haskell's type checker could be exploited. It seems strange to me that with technology like Haskell and GHC we still depend on using C to express these last remaining droplets of real-time determinism requirements--- strange, since I think of higher-level languages like Haskell to be supersets of the capabilities of C---and annoying, because it means having to deal with the complexities of language interoperability, just for a few low-level components of an application. I realize some of this has probably been discussed in conjunction with FRP. I'm aware of one paper on RT-FRP that talks about requiring an RT-friendly sub-language [3], but I don't pretend to follow it completely. I'm almost sure it also has something to do with arrows, but I have very little idea what they are, since I'm still just "getting" monads at this point in my personal Haskell understanding. I hope someone more knowledgeable about these things on this list might be able to comment on their relation to real-time determinism. [1] http://faust.grame.fr/ [2] http://claudiusmaximus.goto10.org/cm/2009-12-04_heist_dataflow_algebra.html [3] http://www.haskell.org/frp/rt-frp.pdf

7 8