- Haskell-Cafe - Haskell.org

Teaching haskell and fuzzy logic to high school students
by claudio 31 Jan '13

31 Jan '13

I'm an Italian IT teacher and I would like to introduce functional programming using haskell. As classroom activity, I would like to build-up a simple fuzzy inference engine. Does anyone know if someone has experience in teaching haskell to high school students or something has already been done with fuzzy logic and haskell? I found only this page: http://www.haskell.org/haskellwiki/AI/Logic/Fuzzy with some information and a link to a pubblication (with fee, I didn't download yet). Thanks Claudio

3 2

Type classes, collections, sum types, closures, and a massive headache
by Bob Hutchison 31 Jan '13

31 Jan '13

Hi, I'm relatively new to Haskell, and consider myself to be towards the beginner side of the scale. Nevertheless, I've got this Haskell program I've been working on that's sitting around 11k lines right now. The pattern has been to let it grow to then knock it back by 'refactoring' or whatever you want to call it… doing it right the second time maybe… or the third time. All I want to get across is that though I consider myself a Haskell beginner I've still managed to produce something that is actually quite complex and of reasonable size in about three months. I'm still getting caught by stuff that I should not be caught by. So. Today I thought it was about time to simplify how new 'things' of a certain kind are added to the system. These things are some a cross between an event and an assertion of a fact in a rule based system. There are many different kinds of these things. I already have more than a dozen commonplace ones, and I expect there's a much larger number of more specialized ones that a user will want to add on their own. While they start out quite differently, they end up satisfying a common interface and follow the identical three or four state lifecycle. This sounded like a type class to me, and in fact, easily implemented as such. Now, this is how I got caught: it seems to be impossible to have collections of things with a common type class if they have different types. How is it that I've written that many lines of code in Haskell and I'm just noticing this now? (If I wasn't so annoyed, I'd look for something clever to reflect how loc count obviously doesn't mean much… but clever seems to be beyond me today). Is this true? Are there any GHC extensions that will let me around this? The immediate problem is mapping an input to the system, some json message containing a reference to the 'thing' (like a key of some kind). I have to take that reference and find the thing and operate on it. All operations are easily accommodated by a type class. However, since I can't have a collection with mixed types even if the types satisfy a type class, I can't quite see how to actually store the things so I can find them. So there are a couple of obvious ways to handle this. I could use an ADT and a sum type of all the known kinds of thing, but I already know that this has to be extended and that's going to be problematic with users doing this on their own. And the type signatures look ugly. So I think that's not the best. I could use an ADT that contains functions that correspond to the functions of the type class, and that close over the 'thing' in question. I think this could be made to work, but I'm concerned with walking into more nasty surprises… If anyone is able to make sense of what I wrote and has any suggestions I'd really appreciate hearing them. Thanks, Bob

5 6

Call for Participation - ACCAT 2013
by Ulrike Golas 31 Jan '13

31 Jan '13

[We apologize if you receive multiple copies of this message.] CALL FOR PARTICIPATION ========== 8th International Workshop on Applied and Computational Category Theory ACCAT 2013 http://accat2013.zib.de/ Satellite Event of ETAPS 2013, Rome, March 17 2013 ========== Scope ===== Since the 1960s, the use of category theory in computer science has been a fruitful one, including applications to different areas such as automata theory, algebraic specification, and programming languages, among others. In recent years, techniques and methods from CT have been adopted as a standard research tool, and considered as such in different venues around the world. The ACCAT workshop on "Applied and Computational Category Theory" has been one of these venues. Since its inception in 2006, ACCAT provided a forum where invited contributors presented their own research on different facets of category theory applied to computer science. Following the tradition, the program of this year edition will include eight invited talks by top researchers in the area: Samson Abramsky Robin B. Cockett Barbara Koenig Ugo Montanari Till Mossakowski Dusko Pavlovic Andrzej Tarlecki Glynn Winskel Despite ACCAT's success, we believe that the current formula of the workshop should be deeply revised. Indeed, we believe that a fully fledged conference is missing where all kinds of applications of category theory to computer science can be presented (like the former CTCS conference, which somehow ended in 2006). Therefore, after the presentations, the workshop will end up with a general discussion among the invited speakers and the attendees. We hope that the outcome of the discussion could be a decision whether to push for such high-level workshop/conference on the application of category theory to computer science, or at least to verify the viability of a further meeting focusing on this issue. For more information, please contact Fabio Gadducci (gadducci(a)di.unipi.it) or Ulrike Golas (golas(a)zib.de) -- Dr. Ulrike Golas Konrad-Zuse-Zentrum für Informationstechnik Berlin Takustr. 7, 14195 Berlin, Germany Tel. +49 30 84185 - 318 golas(a)zib.de -- www.zib.de/golas

1 0

why GHC cannot infer type in this case?
by Dmitry Kulagin 31 Jan '13

31 Jan '13

Hi Cafe, I try to implement little typed DSL with functions, but there is a problem: compiler is unable to infer type for my "functions". It seems that context is clear, but still GHC complains "Could not deduce...". It is sad because without type inference the DSL will be very difficult to use. Could someone explain me why this happens and how it can be avoided? I use GHC 7.4.2 I tried to distill the code to show the problem (and full error message below it). Thank you! Dmitry {-# LANGUAGE GADTs, KindSignatures, DataKinds #-} module TestExp where -- Sequence of DSL's types to represent type of tuple data TSeq where TSeqEmpty :: TSeq TSeqCons :: TypeExp -> TSeq -> TSeq -- All types allowed in DSL data TypeExp where -- Primitive type TInt16 :: TypeExp -- Function type is built from types of arguments (TSeq) and type of result TFun :: TSeq -> TypeExp -> TypeExp -- Sequence of expressions to represent tuple data Seq (t :: TSeq) where SeqEmpty :: Seq TSeqEmpty SeqCons :: Exp w -> Seq v -> Seq (TSeqCons w v) data Exp (r :: TypeExp) where Decl :: (Seq args -> Exp r) -> Exp (TFun args r) Call :: Exp (TFun args r) -> Seq args -> Exp r Int16 :: Int -> Exp TInt16 Add :: Exp TInt16 -> Exp TInt16 -> Exp TInt16 -- Assumed semantics: fun x = x + 2 -- The following line must be uncommented to compile without errors -- fun :: Exp (TFun (TSeqCons TInt16 TSeqEmpty) TInt16) fun = Decl $ \(SeqCons x SeqEmpty) -> Add (Int16 2) x -- eval (Int16 x) = x -- eval (Call (Decl f) seq) = eval (f seq) -- eval (Add x y) = eval x + eval y -- test = eval $ Call fun (SeqCons (Int16 3) SeqEmpty) ----------------- There is full error message: ---------------------------- TestExp.hs:30:53: Could not deduce (w ~ 'TInt16) from the context (args ~ TSeqCons w v) bound by a pattern with constructor SeqCons :: forall (w :: TypeExp) (v :: TSeq). Exp w -> Seq v -> Seq (TSeqCons w v), in a lambda abstraction at TestExp.hs:30:16-33 or from (v ~ 'TSeqEmpty) bound by a pattern with constructor SeqEmpty :: Seq 'TSeqEmpty, in a lambda abstraction at TestExp.hs:30:26-33 `w' is a rigid type variable bound by a pattern with constructor SeqCons :: forall (w :: TypeExp) (v :: TSeq). Exp w -> Seq v -> Seq (TSeqCons w v), in a lambda abstraction at TestExp.hs:30:16 Expected type: Exp 'TInt16 Actual type: Exp w In the second argument of `Add', namely `x' In the expression: Add (Int16 2) x

2 2

"branching" conduits
by Simon Marechal 31 Jan '13

31 Jan '13

Hello, I have found the Conduit abstraction to be very well suited to a set of problems I am facing. I am however wondering how to implement "branching" conduits, and even conduit pools. I am currently in the process of rewriting parts (the simple parts) of the Logstash tool. There is a sample program that I use here: https://github.com/bartavelle/hslogstash/blob/deprecateUtils/examples/Redis… As it can be seen, it uses a "Redis" source, a conduit that decodes the JSON ByteString into a LogstashMessage, a conduit that stores it into Elasticsearch and outputs the result of that action as an Either, and finally a sink that prints the errors. My problem is that I would like more complex behaviour. For example, I would like to route messages to another server instead of putting them into Elasticsearch when the LogstashMessage has some tag set. But this is just an example, and it is probable I will want much more complex behavior soon. I am not sure how to proceed from here, but have the following ideas: * investigate how the Conduits are made internally to see if I can create a operator similar to $$, but that would have a signature like: Source m (Either a b) -> Sink a m r -> Sink b m r and would do the branching in a binary fashion. I am not sure this is even possible. * create a "mvars" connectors constructor, which might have a signature like this: Int -- ^ branch count (LogstashMessage -> Int) -- ^ branching function (Sink LogstashMessage m (), [Source m LogstashMessage]) -- ^ a suitable sink, several sources for the other conduits it would internally create a MVar (Maybe LogstashMessage) for each branch, and put putMVar accordingly to the branching function. When the Conduit is destroyed, it will putMVar Nothing in all MVars. the sources would takeMVar, check if it is Nothing, or just proceed as expected. The MVar should guarantee the constant space property, but there is the risk of inter branch blocking when one of the branches is significantly slower than the others. It doesn't really matter to me anyway. And all the branch Sinks would have to have some synchronization mechanism so that the main thread waits for them (as they are going to be launched by a forkIO). This is the simplest scheme I have thought of, and it is probably not a very good one. I am very interested in suggestions here.

3 3

Announcement - Haskell User Group Frankfurt
by Peter Althainz 31 Jan '13

31 Jan '13

Dear Haskellers, for all who are located near Frankfurt, there is a new Meetup kicked off: http://www.meetup.com/Frankfurt-Haskell-User-Group regards Peter Althainz

1 0

FFI - Approaches to C/C++
by Casey Basichis 31 Jan '13

31 Jan '13

Hi, I'm working on a project in Haskell and C++ where the former is the brains and the latter is for UI, interaction etc. I've read this http://www.altdevblogaday.com/2012/04/26/functional-programming-in-c/ and a number of other haskell posts suggesting the OOP is not the way to go. Without trying to emulate functional programming through templates or boost::phoenix, what approaches do you all favor when designing parts of an application in C++? Patterns to embrace or avoid? Should I just use functions and handle things with name spaces? I was thinking about handling the callbacks with boosts signals and slots 2 I know this is not entirely haskell centric, but it is a question for haskell users. Thanks, Casey -- Casey James Basichis Composer - Cartoon Network http://www.caseyjamesbasichis.com caseybasichis(a)gmail.com 310.387.7540

3 2

Re: [Haskell-cafe] FFI - Approaches to C/C++
by Casey Basichis 31 Jan '13

31 Jan '13

Hi Ertugrul, Thank you for the detailed reply. From what you wrote, partial FFI still seems like the way to go. Unfortunately Ogre isn't the only large library I'm using, so "difficult" several times over sounds like a good way to handicap the project early on. I'm perfectly happy to use Haskell for the strengths that will most benefit my project. I can always go back and try to bring the C++ specific parts into the fold once a prototype is up and running. As it seems there is a great deal of c/c++ to do either way, I would really appreciate so thoughts towards my original question. What practices in C++ are preferred by Haskell users, in the know, for the parts of the app that will not be pure Haskell? Should I be looking to avoid OOP? Dependency Injection? I wont reiterate all the facets of the first post, but it would help me immensely to zero in on a few patterns and strategies that can minimized the damage I inflict in c++ land. Thanks, Casey p.s. With "That used to be true, but the reason has nothing to do with the language. The problem was that the libraries weren't there." What do you mean? Which packages should I be looking at? I am on iOS like I said, its a stage 1 GHC compiler so I don't have access to GHCI or template haskell. >Casey Basichis <caseybasichis at gmail.com> wrote: > >> I'm not entirely sure what you mean. >> >> I'm intending on using Ogre for GUI - for which there is the Hogre >> bindings, but after emailing the DEV about it, I didn't get the >> impression from his advice that I should be using it for production >> code. Here is what he suggested: >> >> "It depends, really. Hogre is good for running Ogre from within >> Haskell, but it has its limitations. The number one thing people have >> been struggling with is handling input with hogre - there's Hois >> (Haskell wrapper for OIS) but it's not perfect (it misses input >> events), and the other option is having to write some C++ glue. Hogre >> is a solid proof of concept and you can do some demos with it, but if >> you're e.g. writing a game it might be a bit of a struggle. In the end >> it's about how much you value being able to write code in Haskell (or >> how allergic to C++ you are)." >> >> I'm on iOS so I imagine those difficulties are compounded. >> >> I am using several other C++ libraries for which there are no existing >> bindings and no Haskell alternative packages that are even remotely >> close. >> >> Are you suggesting it would be better to write all my own FFI bindings >> for all the needed libraries? > >That's not what I'm suggesting. It was just too little information to >properly judge the difficulty of doing everything in Haskell. > >Binding to Ogre (or C++ in general) is indeed difficult. If Hogre >doesn't work or is too limited, your best option might be to write a C >wrapper around the Hogre functionality you need. Another option is to >use SDL/OpenGL directly, which may be easier or harder depending on your >application. > >However, if you can build the bridge between your rendering library and >Haskell, then Haskell is certainly the better choice. > > >> Everything I read suggests that Haskells strengths are in >> transformation and that interaction is not its strong suit. >> >> I am interested in your thoughts and I am open to whatever, but you >> are the first to suggest that the mix is a bad idea. > >That used to be true, but the reason has nothing to do with the >language. The problem was that the libraries weren't there. Nowadays >you can write all sorts of interactive applications in Haskell, >including GUIs, TUIs, games, simulations and web applications. However, >I've long been waiting for useful bindings to Ogre or Irrlicht, but I'm >afraid that it's not going to happen any time soon. > >Ultimately it's your choice. Let me summarize the possiblities: > > * C wrapper around Ogre. Easy integration, but need to write the > rendering code in C/C++. > > * Full FFI bindings to Ogre. Difficult integration, but you can write > your rendering code in Haskell. > > * Partial FFI bindings to Ogre. Integration may be somewhat easy, if > you do the initialization in Haskell and the actual rendering in > C/C++. However, this again requires to write the rendering in > C/C++. > > * Using SDL/OpenGL directly: Everything available for Haskell. May > be difficult, because you need to write OpenGL code. > >I hope, this helps. > > >Greets, >Ertugrul -- Casey James Basichis Composer - Cartoon Network http://www.caseyjamesbasichis.com caseybasichis(a)gmail.com 310.387.7540

2 1

(no subject)
by Casey Basichis 31 Jan '13

31 Jan '13

Hi Ertugrul, Thank you for the detailed reply. From what you wrote, partial FFI still seems like the way to go. Unfortunately Ogre isn't the only large library I'm using, so "difficult" several times over sounds like a good way to handicap the project early on. I'm perfectly happy to use Haskell for the strengths that will most benefit my project. I can always go back and try to bring the C++ specific parts into the fold once a prototype is up and running. As it seems there is a great deal of c/c++ to do either way, I would really appreciate so thoughts towards my original question. What practices in C++ are preferred by Haskell users, in the know, for the parts of the app that will not be pure Haskell? Should I be looking to avoid OOP? Dependency Injection? I wont reiterate all the facets of the first post, but it would help me immensely to zero in on a few patterns and strategies that can minimized the damage I inflict in c++ land. Thanks, Casey p.s. With "That used to be true, but the reason has nothing to do with the language. The problem was that the libraries weren't there." What do you mean? Which packages should I be looking at? I am on iOS like I said, its a stage 1 GHC compiler so I don't have access to GHCI or template haskell. >Casey Basichis <caseybasichis at gmail.com> wrote: > >> I'm not entirely sure what you mean. >> >> I'm intending on using Ogre for GUI - for which there is the Hogre >> bindings, but after emailing the DEV about it, I didn't get the >> impression from his advice that I should be using it for production >> code. Here is what he suggested: >> >> "It depends, really. Hogre is good for running Ogre from within >> Haskell, but it has its limitations. The number one thing people have >> been struggling with is handling input with hogre - there's Hois >> (Haskell wrapper for OIS) but it's not perfect (it misses input >> events), and the other option is having to write some C++ glue. Hogre >> is a solid proof of concept and you can do some demos with it, but if >> you're e.g. writing a game it might be a bit of a struggle. In the end >> it's about how much you value being able to write code in Haskell (or >> how allergic to C++ you are)." >> >> I'm on iOS so I imagine those difficulties are compounded. >> >> I am using several other C++ libraries for which there are no existing >> bindings and no Haskell alternative packages that are even remotely >> close. >> >> Are you suggesting it would be better to write all my own FFI bindings >> for all the needed libraries? > >That's not what I'm suggesting. It was just too little information to >properly judge the difficulty of doing everything in Haskell. > >Binding to Ogre (or C++ in general) is indeed difficult. If Hogre >doesn't work or is too limited, your best option might be to write a C >wrapper around the Hogre functionality you need. Another option is to >use SDL/OpenGL directly, which may be easier or harder depending on your >application. > >However, if you can build the bridge between your rendering library and >Haskell, then Haskell is certainly the better choice. > > >> Everything I read suggests that Haskells strengths are in >> transformation and that interaction is not its strong suit. >> >> I am interested in your thoughts and I am open to whatever, but you >> are the first to suggest that the mix is a bad idea. > >That used to be true, but the reason has nothing to do with the >language. The problem was that the libraries weren't there. Nowadays >you can write all sorts of interactive applications in Haskell, >including GUIs, TUIs, games, simulations and web applications. However, >I've long been waiting for useful bindings to Ogre or Irrlicht, but I'm >afraid that it's not going to happen any time soon. > >Ultimately it's your choice. Let me summarize the possiblities: > > * C wrapper around Ogre. Easy integration, but need to write the > rendering code in C/C++. > > * Full FFI bindings to Ogre. Difficult integration, but you can write > your rendering code in Haskell. > > * Partial FFI bindings to Ogre. Integration may be somewhat easy, if > you do the initialization in Haskell and the actual rendering in > C/C++. However, this again requires to write the rendering in > C/C++. > > * Using SDL/OpenGL directly: Everything available for Haskell. May > be difficult, because you need to write OpenGL code. > >I hope, this helps. > > >Greets, >Ertugrul

1 0

list comprehansion performance has hug different
by Junior White 31 Jan '13

31 Jan '13

Hi Cafe, I have two programs for the same problem "Eight queens problem", the link is http://www.haskell.org/haskellwiki/99_questions/90_to_94. My two grograms only has little difference, but the performance, this is my solution: -- solution 1------------------------------------------------------------ queens1 :: Int -> [[Int]] queens1 n = map reverse $ queens' n where queens' 0 = [[]] queens' k = [q:qs | q <- [1..n], qs <- queens' (k-1), isSafe q qs] isSafe try qs = not (try `elem` qs || sameDiag try qs) sameDiag try qs = any (λ(colDist, q) -> abs (try - q) == colDist) $ zip [1..] qs -- solution 2-------------------------------------------------------------- queens2 :: Int -> [[Int]] queens2 n = map reverse $ queens' n where queens' 0 = [[]] queens' k = [q:qs | qs <- queens' (k-1), q <- [1..n], isSafe q qs] isSafe try qs = not (try `elem` qs || sameDiag try qs) sameDiag try qs = any (λ(colDist,q) -> abs (try - q) == colDist) $ zip [1..] qs the performance difference is: (set :set +s in ghci) *Main> length (queens1 8) 92 (287.85 secs, 66177031160 bytes) *Main> length (queens2 8) 92 (0.07 secs, 17047968 bytes) *Main> The only different in the two program is in the first is "q <- [1..n], qs <- queens' (k-1)," and the second is "qs <- queens' (k-1), q <- [1..n]". Does sequence in list comprehansion matter? And why?

9 16