February 2009 - Haskell-Cafe

Is using Data.Dynamic considered a no-go?
by Peter Verswyvelen 13 Feb '09

13 Feb '09

Haskell seems to have pretty strong support for dynamic casting using Data.Typeable and Data.Dynamic. All kinds of funky dynamic programming seems to be possible with these "hacks". Is this considered as being as bad as - say - unsafePerformIO? What kind of evil is lurking here? Cheers, Peter

6 8

Re: [Haskell] Google Summer of Code 2009
by Jamie 12 Feb '09

12 Feb '09

What I would like to see is H.264 video codec in Haskell. H.264/MPEG-4 is getting very popular nowadays and it would be great to have encoder and decoder in haskell. Can use x264 (encoder) and ffmpeg (en/de coder) as a base to start with. Jamie

20 38

Re: Type families not as useful over functions
by oleg＠okmij.org 12 Feb '09

12 Feb '09

John Ky wrote: > Is there a way to define type r to be all types except functions? Perhaps the following article How to write an instance for not-a-function http://okmij.org/ftp/Haskell/typecast.html#is-function-type answers your question. It shows several complete examples.

1 0

Is this related to continuations somehow?
by Andrew Wagner 12 Feb '09

12 Feb '09

So, I was reading a bit about continuations the other day, and, since I've been thinking about good ways of expressing chess strategies in Haskell, I thought that I'd play around a bit with something like continuations for game-playing strategies. The idea is that you have combinators that allow you full access to the strategies which remain to be applied. In this way, strategies can "activate" and "de-activate" other strategies. Here's a simple little toy app for Tic-Tac-Toe (Naughts and Crosses): http://codepad.org/nN9JsxFK You can run main on 'example', and see that it searches every line and fails. And, as you can see, it aborts after finding a win in example2. This would be easily extensible to say things like "if you've seen a blocking move, and you don't have a win, then play the blocking move", and of course the other deep intricacies of the game. My question is, is this, in fact, related to continuations somehow? Could continuations simplify it? Or am I doing something completely different?

1 0

Re: Google Summer of Code 2009
by Matthew Elder 12 Feb '09

12 Feb '09

> So in general, think hard about missing capabilities in Haskell: > > * tools > * libraries > * infrastructure > > that benefit the broadest number of Haskell users or developers. > > Another route is to identify a clear niche where Haskell could leap > ahead of the competition, with a small investment. > > -- Don > One capability I would love to see as a SoC project is the ability to generate javascript (a small subset) as an additional output target from ghc. Something like this was already done with yhc here<http://www.haskell.org/haskellwiki/Yhc/Javascript>but if it could be ported to GHC and cabalized, this would really be a boon to the web dev community; javascript is quickly becoming one of the most predominant languages used for GUI creation (mainly via the web). -- Need somewhere to put your code? http://patch-tag.com Want to build a webapp? http://happstack.com

1 0

Re: [Haskell-cafe] Google Summer of Code 2009
by Andrzej Jaworski 12 Feb '09

12 Feb '09

> If you have ideas for student projects that you think would benefit the > Haskell community, now is the time to start discussing them on mailing Here is an idea that if done right might bootstrap Haskell real world applications with the help of greed and adrenaline:-) The ignition: (0) Bind Haskell to an automatic trading platform [API] (1) write real-time streamer and stock scanner. [PType] should offer more than was demonstrated in [F#] (2) Join [apps] from any angle (3) Consider a [DSL] for data analysis or write an [EasyLanguage] [API] http://www.interactivebrokers.com/en/p.php?f=programInterface&ib_entity=llc [F#] http://channel9.msdn.com/pdc2008/TL11/ [PType] http://research.nii.ac.jp/~hu/pub/aplas04-xu.pdf [apps] http://www.interactivebrokers.com/en/general/poll/ibconsultants.php?accept_… [DSL] http://www.cc.gatech.edu/~saswat/research/one.pdf [EasyLanguage] https://www.tradestation.com/support/books/pdf/EL_Essentials.pdf https://www.tradestation.com/support/books/pdf/EL_FunctionsAndReservedWords…

1 0

Re: [Haskell] Google Summer of Code 2009
by Andrzej Jaworski 12 Feb '09

12 Feb '09

> If you have ideas for student projects that you think would benefit the > Haskell community, now is the time to start discussing them on mailing Here is an idea that if done right might bootstrap Haskell real world applications with the help of greed and adrenaline:-) The ignition: (0) Bind Haskell to an automatic trading platform [API] (1) write real-time streamer and stock scanner. [PType] should offer more than was demonstrated in [F#] (2) Join [apps] from any angle (3) Consider a [DSL] for data analysis or write an [EasyLanguage] [API] http://www.interactivebrokers.com/en/p.php?f=programInterface&ib_entity=llc [F#] http://channel9.msdn.com/pdc2008/TL11/ [PType] http://research.nii.ac.jp/~hu/pub/aplas04-xu.pdf [apps] http://www.interactivebrokers.com/en/general/poll/ibconsultants.php?accept_… [DSL] http://www.cc.gatech.edu/~saswat/research/one.pdf [EasyLanguage] https://www.tradestation.com/support/books/pdf/EL_Essentials.pdf https://www.tradestation.com/support/books/pdf/EL_FunctionsAndReservedWords…

1 0

can't figure out a type
by John Lato 12 Feb '09

12 Feb '09

Hello, I'm working on some code like the following: > class Chunkable c el | c -> el where > cLength :: c -> Int > cHead :: c -> Maybe el I want to be able to map over this type, like this: > cMap :: Chunkable c' el' => (el -> el') -> c -> c' but this isn't quite right. c' shouldn't be any instance of Chunkable, it should be the same instance except parameterized over a different type. Another approach would be something like: class (Functor c) => Chunkable c el ... except that's not right either. I think c has the wrong kind to be a Functor instance. I expect there's something very basic I'm missing. Could anyone point in the proper direction of how to do this? Can this be expressed with associated types, perhaps? Thanks, John Lato

3 6

Re: Graph library, was: Haskell.org GSoC
by Louis Wasserman 12 Feb '09

12 Feb '09

fgl uses pretty much the most beautiful way of abstracting graphs I've seen; a brief review: type Context a b -- a collected representation of a vertex's number, label, and all information on edges going into and out of that vertex match :: Graph gr => Node -> gr a b -> (Maybe (Context a b), gr a b) -- if a vertex is in the graph, extracts its adjacency information in a Context and returns the graph without that vertex (&) :: DynGraph gr => Context a b -> gr a b -> gr a b -- melds a vertex and its adjacency information into the graph I've been doing a huge amount of messing around with graph algorithms recently, and this inductive style of graph querying and modification make several algorithms far more intuitive than most imperative implementations I've seen. In addition, both of these lend themselves well to use in a State monad. Take the following code to extract the connected component of a vertex in an undirected graph: extractComponentM :: DynGraph gr => gr a b -> Node -> State (gr a b) (gr a b) extractComponentM partialComponent v = State (match v) >>= maybe (return partialComponent) expandContext where expandContext cxt = liftM (cxt &) (foldM extractComponentM partialComponent (neighbors' cxt)) extractComponent :: DynGraph gr => gr a b -- the initial graph -> Node -- the node whose component to find -> (gr a b, gr a b) -- the original graph without the component, and the component extractComponent g v = runState (extractComponentM empty v) g That's far more compact -- and intuitive to someone familiar with both fgl and the State monad -- than a standard connected-component finder in an imperative language, speaking as someone who wrote code along these lines imperatively for several years. (Fun fact: I've been working on a nice encapsulation of priority queues as monad transformers to make other common graph algorithms both efficient and make them this pretty to read, too. Any thoughts on that would be appreciated.) I strongly feel that fgl, though it could be improved in some areas, makes a better truly general graph abstraction than anything else I've seen. Areas that could specifically be improved include the stuff that uses LRTrees, and other stuff that isn't especially intuitive, elegant, or even efficient in fgl's implementation. Louis Wasserman wasserman.louis(a)gmail.com

1 0

Re: Google Summer of Code 2009
by John Lato 12 Feb '09

12 Feb '09

Johan Tibell wrote: > On Thu, Feb 12, 2009 at 2:12 AM, Felipe Lessa <felipe.lessa(a)gmail.com> wrote: >> Do we already have enough information to turn >> http://okmij.org/ftp/Haskell/Iteratee/ into a nice, generic, cabalized >> package? I think Iteratees may prove themselves as useful as >> ByteStrings. > > I still haven't figured out what the "correct" definition of Iteratee > would look like. The Iteratee code that Oleg wrote seems to have the > structure of some kind of "two level" monad. I think that's the reason > for the frequent occurrences of >>== and liftI in the code. There > seems to be some things we yet have to discover about Iteratees. > I concur. I've recently been involved with several discussions on this topic, and there are some issues that remain. The "two level monad" part doesn't bother me, but I think the type should be slightly more abstract and I'm not sure of the best way to do so. IMO liftI is used more because of Oleg's particular style of coding than anything else. I don't think it need be common in user code, although it may be more efficient. I think that, if a GSOC project were to focus on Iteratees, it would need to look at issues like these. I can't judge as to whether this is an appropriate amount of work for GSOC, however simply packaging and cabal-izing Oleg's Iteratee work (or Johan's, or my own) is likely of too small a scope. John Lato

3 2