- Haskell-Cafe - Haskell.org

How to hold common data
by scott west 13 May '04

13 May '04

Hello all, I'm new to haskell and was just wondering if there was any efficient or standard way to store and modify some sort of state data. The functional nature of haskell has me confused in this respect! Basically what I want to achieve is an interactive program that allows you to edit some tables, and thus hold some data. I dont' need to be spoonfed an answer, but a general guideline would be very helpful :) Thanks for any help you could provide! Regards, Scott

3 2

Re: [Haskell-cafe] How to hold common data
by MR K P SCHUPKE 13 May '04

13 May '04

simplest way... use a recursive function that feeds itself the state as one of its arguments...

3 2

Surprising bugs
by Mark Carroll 13 May '04

13 May '04

I clearly don't understand Haskell very deeply yet because I dealt with a couple of interesting types of bug this week. One sort was where, if I have, f :: SomeType -> Stuff ... f = whatever g :: Stuff ... g = f someValue ...then I can get an error that suggests that maybe I'm violating the monomorphism restriction if I put in f's type but not g's. If I put both in, it becomes happy. Another sort was where, if I had an algebraic parametric type (is that the name? Ord a => Foo a b c, etc.) then I couldn't have, say, a Maybe (Foo a b c), where sometimes I called it with a (Just foo) and sometimes with a Nothing, because with the Nothings it would complain about, erm, some ambiguity to do with Ord a. However, it would be fixed if I made the Maybe X argument into two arguments, Bool -> X, the Bool indicating if the X was meant to have been a Nothing or a Just X. I hope both (or either!) of those made sense. I don't have the code immediately to hand to reproduce the details, but I just thought I'd try to recall what they were because I found these compiler complaints interesting. I don't fully understand what's happening, and I'm sure a newbie would be quite bewildered. (-: -- Mark

1 0

Monadic Composition
by Jorge Adriano Aires 12 May '04

12 May '04

Hello, I needed to compose monadic functions, since I couldn't find anything in Control.Monad so I defined my own. I first came up with a left associative version: compLM [f1,..., fn] a = (f1 a >>= f2) >>= ... >>= fn > compLM :: Monad m => [a->m a] -> (a->m a) > compLM mfs a = foldl (>>=) (return a) mfs Later a right associative version, which I believe to be more efficient, particularly when some computation returns fail: compRM [f1,..., fn] a = \x->f1 x >>= (\x->f2 x >>= ... >>= \x->fn x) a > compRM :: Monad m => [a->m a] -> (a->m a) > compRM = foldr (\f g-> (\x ->f x >>= g)) return This higher order function seems quite useful to me and not trivial, so I expected it to be available. When this happens I wonder if I'm missing something. Am I complicating things? Is it actually available (or some other that does the trick) ? Or is it just me who finds this usefull enough to be in the libs? J.A.

2 2

Cyclic Dependencies
by Georg Martius 12 May '04

12 May '04

Hi, I have some problems with cyclic dependencies. Module Foo: data Foo = Foo { bar :: Bar } Module Bar: class BarClass b where barfun :: b -> Foo -> Foo data Bar = forall b . (BarClass b) => Bar b Obviously I have to import both modules mutually. My workaround was to add a further type variable to BarClass. class BarClass' b f where barfun :: b -> f -> f data Bar' f = forall b . (BarClass' b f) => Bar b This seams to be fine, but in my case it is a bit more compicated. I need a Read instance of Foo. Therefor I have to implement the Read instance for the existential type Bar by my own and need to know about the instanced of BarClass. Unfortunately, the instances of BarClass need Foo and I have a cycle again. Thanks, Georg

1 0

Visualising a type class hierarchy
by Andre Pang 12 May '04

12 May '04

Hey all, Does anyone know of a good way to visualise ("graph") a type class hierarchy, including one with multiple-parameter type classes? The traditional "inherits from" arrows used in graphs of object-oriented classes doesn't deal very well with type classes. A simple case, such as: class Super a class Super a => Sub a instance Super SuperType instance Super SubType instance Sub SubType works fine, but once you get into situations such as: class SuperMulti a b class SubMulti a b c | a b -> c instance SuperMulti a Foo => SubMulti a Bar c I haven't found elegant ways of visualising this at all: how do you draw arrows from SuperMulti to SubMulti, for instance? Has anyone else had a go at this? -- % Andre Pang : trust.in.love.to.save

1 0

Re: [Haskell-cafe] Toy application advice wanted
by John Hughes 10 May '04

10 May '04

> But Scheme lets you change things if you want to! (The Haskell > afficianados gasp). Let's face it...in most long-running applications, > data changes a lot during the lifetime of a program. So somehow, you have > to manage the repercussions of state changes. Haskell does this with > monads. (I'm still wrapping my brain around them, but...) Apparently > monads plus some syntactic sugar are like functions that return a value > and the next function, which in turn returns a value and the next > function, etc. so that referential transparency is maintained. This is a > heckuva lot of work to do (set! foo 'bar). I hope I'm not far off base > with this. Gosh, this sounds complicated! I think there's a much simpler way to see it. In almost any language, some expressions have side-effects, and some don't. Use expressions with side-effects carelessly, in the wrong place, and you can screw up. In Haskell, expressions with side-effects have a type that says so (IO <type>), and that in turn lets the type-checker restrict where you use them (hence the many questions "How do I get an <alpha> from an IO <alpha>?" -- the point is, you can't). So you avoid screwing up. Not particularly complicated, not particularly costly. writeIORef foo Bar :: IO () -- empty result, with a side-effect. OK, there's more to it than this, once you start using other monads than IO or ST, and especially once you start overloading code on the underlying monad. But as an initial understanding this is enough. John Hughes

1 0

Toy application advice wanted
by mikeb＠manor.org 10 May '04

10 May '04

Hi folks, I've got an interesting task this week for my job. (Note that this will undoubtably last for longer than a week). I'm evaluating several high-level languages as development vehicles for our next suite of applications. The languages I'm currently considering are Scheme, Erlang, and Haskell. Scheme and Haskell have fairly wide acceptance in their particular roles (Scheme as the "pretty" lisp, supporting higher-order functions and mostly strict [until you roll your own laziness with macros], and Haskell the absolute purest language with no side effects and fully lazy evaluation). Erlang has a really nice distributed computing model, and has a nice union of non- and side-effect qualities (although it's completely strict). The toy application I've "designed" for myself is a simple GUI-based app that can load a Sun .au format sound file, display its waveform in a window, perform some simple filtering, play the sound for the user, and then save the changed sound file back out to disk. If I get familiar enough with the respective environments I'd like to add zooming in/out and scrolling to the waveform display. This application should allow me to see all kinds of different characteristics of the language/implementation, such as performance (how fast can the filter run), I/O (how fast can I load/save data to disk), OS interaction (how easy can I "play" the audio), user acceptance (how easy is it to do GUI programming) and of course the software engineering goals of modularity, correctness, and simplicity. The end goal is for me to have three working programs, in three different languages, so that I can present to my boss the performance/software engineering characteristics of each system to choose our next development language. So I'm writing you to solicit help. I have an amortized four days (32 hours!!!) to implement this simple application in Haskell. Can anyone point me to example code, supporting libraries, tutorials, etc. that are in this area of development? If I have to dumb down some of my application in order to make a great discovery about a language, that's fine. I'm expecting some great differences between these three programs. Any advice/pointers/flames welcome. Thanks in advance. Mike -- Mike J. Bell This is all just my opinion. "Outside of a dog, a book is man's best friend. Inside it's too dark to read." mikeb(a)manor.org

12 14

HDirect, [unique], troubles again!
by Vincenzo aka Nick Name 07 May '04

07 May '04

In my quest for a fuse binding for Haskell, which I really need at the moment, I have the following definition working: module HSFuse { interface stat{}; typedef int getattrT([string] char *,stat); typedef struct fuseOps { [ref] getattrT * getattr; } fuseOps; void fuse_main(int argc,[in,string,size_is(argc)]char** argv,[ref] fuseOps * op); }; but when I substitute "ref" with "unique", because some operations can be null, I get the errors below. The problem is that in the generated hs file there is data FuseOps = FuseOps {getattr :: GetattrT} which completely ignores my type declaration! Did I do something wrong? Commands invoked and errors follow, thanks for attention: ihc -fhs-to-c -fuse-ints-everywhere -c HSFuse.idl ghc -package hdirect -fglasgow-exts HSFuse.hs -c HSFuse.hs:136: Couldn't match `GHC.Base.String -> Stat -> GHC.IOBase.IO GHC.Base.Int' against `GHC.Ptr.Ptr (GHC.Base.String -> Stat -> GHC.IOBase.IO GHC.Base.Int)' Expected type: GHC.Ptr.Ptr (GHC.Ptr.Ptr (GHC.Base.String -> Stat -> GHC.IOBase.IO GHC.Base.Int)) -> GHC.Ptr.Ptr (GHC.Base.String -> Stat -> GHC.IOBase.IO GHC.Base.Int) -> GHC.IOBase.IO () Inferred type: GHC.Ptr.Ptr (GHC.Ptr.Ptr (GHC.Base.String -> Stat -> GHC.IOBase.IO GHC.Base.Int)) -> (GHC.Base.String -> Stat -> GHC.IOBase.IO GHC.Base.Int) -> GHC.IOBase.IO () In the second argument of `HDirect.writeunique', namely `writeGetattrT' In the definition of `writeFuseOps': writeFuseOps ptr (FuseOps getattr) = let pf0 = ptr pf1 = HDirect.addNCastPtr pf0 0 in HDirect.writeunique (HDirect.allocBytes (GHC.Real.fromIntegral sizeofGetattrT)) writeGetattrT pf1 getattr

2 1

greencard and callbacks
by Vincenzo aka Nick Name 07 May '04

07 May '04

I realize that I myself might have already asked this question to some of you, but I am really confused now. Can I have some opinion on "what is the right way to implement callbacks from C to haskell"? Will I have to learn the FFI and stop it, or is there some tool to automate the process? I need to bind a single function which takes a record of callbacks, and that's all. Can greencard support callbacks? If yes, can someone provide a simple example? I thought to do: import Foreign.GreenCard %#include<stdio.h> %fun doit :: Int -> (Int -> Int) -> IO () %code printf("%d",arg2(arg1)); which does not work, as someone might already have expected :) Thanks all Vincenzo

2 3