- Haskell-Cafe - Haskell.org

Re: Threading monads
by Jon Cast 11 Apr '03

11 Apr '03

Jan-Willem Maessen <jmaessen(a)MIT.EDU> wrote: > Actually, though the operations of most monads constrain evaluation > order, an interesting property of the identity monad is that it should > not do so. This observation has led me to think long and hard about > the distinction between monadic and non-monadic computations in > Haskell (admittedly to no real conclusion). Why would you do this? I don't see what conclusion you could come to that would involving discarding the ID monad, so you'd still need to distinguish between different monads. OTOH, the do-notation or other monadic notations don't really add much to the ID monad. So, a non-monadic syntax would still be desirable for this very common special case. So, what could you possibly think would change? Jon Cast

2 1

Re: Threading monads
by Jon Cast 10 Apr '03

10 Apr '03

Mark Carroll <mark(a)chaos.x-philes.com> wrote: > I could give an example, actually, which might make things > clearer. Take one of my unfoldM's: > unfoldM f base = > do fb <- f base > case fb of > Nothing -> return [] > Just (a, b) -> do rest <- unfoldM f b > return (a : rest) > Now, using the Identity monad I can write a wrapper for non-monadic > f's: > myUnfoldr f b = > runIdentity (unfoldM (return . f) b) > which works the same as a regular unfoldr. With a monadic function > and a wrapper that uses the Identity monad, I can offer both monadic > and non-monadic interfaces to the unfolding functionality that is only > implemented once. > Is this a good design idea? Are there better ones? Is myUnfoldr > necessarily less efficient than a "normal" unfoldr that doesn't have > monads underneath constraining evaluation order? Monads don't necessarily constrain the order of evaluation. The ID monad, in particular, is perfectly lazy. So, it doesn't place any more constraints on the order of evaluation than ordinary Haskell does. Furthermore, (although I can't check this atm) I suspect if you ask a Haskell compiler to specialize unfoldM for ID, you'll get a version that acts internally almost exactly like unfoldr---and that produces a myUnfoldr implementation precisely equal to unfoldr. Jon Cast

1 0

Threading monads
by Mark T.B. Carroll 10 Apr '03

10 Apr '03

Occasionally I have a non-monadic function (call it "x") that takes a function (call it "y") as an argument and uses it for stuff. Then, one day I inevitably want to pass it a y that needs to do something monadically: e.g. when I wanted unfoldM instead of unfoldr. So, I have to rewrite x accordingly. If I want to write an x that is open to taking a monadic y but doesn't require it to be monadic, should I maybe write it monadically and provide a wrapper that puts non-monadic y's in the Identity monad? Might this wrapping approach cause less efficient code than writing an alternative non-monadic x for non-monadic y's? Am I making any sense at all? (-: -- Mark

3 2

unfoldM
by Mark T.B. Carroll 09 Apr '03

09 Apr '03

I wanted a monadic unfoldr and couldn't see one so I thought I'd share two possibilities I'd been playing with: unfoldM_a :: Monad m => (b -> Maybe (m (a, b))) -> b -> m [a] unfoldM_a f base = case f base of Nothing -> return [] Just result -> do (a, b) <- result rest <- unfoldM_a f b return (a : rest) unfoldM_b :: Monad m => (b -> m (Maybe (a, b))) -> b -> m [a] unfoldM_b f base = do fb <- f base case fb of Nothing -> return [] Just (a, b) -> do rest <- unfoldM_b f b return (a : rest) test_case_a "" = Nothing test_case_a word@(_:xs) = Just (do a <- print (length word) return (a, xs)) test_case_b "" = return Nothing test_case_b word@(_:xs) = do a <- print (length word) return (Just (a, xs)) main = unfoldM_a test_case_a "foo" putStr "----\n" unfoldM_b test_case_b "foo" -- Mark

2 1

announcing darcs
by David Roundy 09 Apr '03

09 Apr '03

(My apologies for a possibly off-topic post, but I don't know where else I might contact interested haskellers.) For anyone who might be interested, I've written a revision control system which is in haskell (called darcs), which is licensed under the GPL. It contains a few bits of code that you might find useful, such as an interface to libcurl (for lazily reading files over http or ftp), an LCS function and code for opening a pipe to sendmail as a Handle. Of course, I'd welcome anyone who wants to contribute to darcs itself. the darcs webpage is http://www.abridgegame.org/darcs/ darcs is currently unix-only (counting MacOS X as unix). A port to windows would be a fair amount of work, but probably would mostly be straightforward (mostly dealing with slashes versus backslashes and getting libcurl to work under windows). -- David Roundy http://www.abridgegame.org/darcs/

2 1

state of FRP
by Isaac Jones 09 Apr '03

09 Apr '03

Greetings, I'm interested in learning more about Functional Reactive Programming since I want to be a better designer of Haskell programs. I don't want to use it for animation or GUIs in particular, but as a general design paradigm. With some digging, one discovers www.haskell.org/frp which has some pointers to papers on frp, but each of them seems to describe something new or domain specific wrt frp. I'd love advice about what order to read these papers in. Is there any more general introduction to frp for a working programmer? In learning Monads, I found standard libraries like Control.Monad.State to be extremely instructive since they encapsulate the basic operations that are available. (I wrote some documentation for this module a few weeks back to share what I learned. Its in CVS now.) So I'm curious about frp libraries. haskell.org/frp mentions an frp library that will exist one day. The manual looks interesting and this seems like it would be a good place to start, but Yale FRP is, alas, not yet available. Further poking reveals www.haskell.org/afrp which has an available snapshot, but no documentation. Any advice out there on how to go about learning frp? Should I see what I can glean from using functional reactive animation or GUI libraries? peace, isaac

2 1

IOHCC Results?
by Ashley Yakeley 06 Apr '03

06 Apr '03

Anyone know? I didn't submit anything but I am curious... http://iohc.mgoetze.net/ -- Ashley Yakeley, Seattle WA

2 1

comonads, io
by peter＠premise.demon.co.uk 06 Apr '03

06 Apr '03

I came across an interesting paper "Codata and comonads in Haskell" by Richard Kieburtz, and some other work by Alberto Pardo on comonads. Kieburtz proposes an OI comonad, as an alternative to (or something alongside?) the IO monad. Just for reasons of symmetry, it's natural to wonder if they aren't as pervasive in functional programs as monads. Frustratingly, I can't seem to grasp the intuition. I'm aware that the state-monad s->(s,a) has a dual state-in-context comonad (s,s->a). How does the side-effect manifest itself? The (ineffective) hints the authors give revolve around the idea that side-effects "derive" from the context of a program. Any other hints? Are comonads especially appropriate for programming systems that react to changes in their environment? Is an object of OI type something like a program to react to events? I can't make the slightest sense of Kieburtz's OI co-monad, with commands like coGetChar :: OI Handle -> Char. Peter Hancock

4 6

creating MIME mail
by David Roundy 05 Apr '03

05 Apr '03

Any ideas how to easily create MIME mail? A brief look at haskell.org didn't show any libraries that seemed useful for this. Basically I'd like to send information from my program (in the form of a couple of attachments to an email) which can then be extracted on the other end. So I guess I'd like to be able to both create _and_ parse MIME email. The reason for it being email is so the receiver can easily check it out before piping it into my program. -- David Roundy http://www.abridgegame.org

1 0

RE: simulating dynamic dispatch
by Simon Peyton-Jones 04 Apr '03

04 Apr '03

(Taking this off to haskell-cafe) It's not unreasonable for it to be ambiguous. The argument 'f' says *forall b*. The cast will cast to a *specified* type. But you aren't specifying the type. If you passed a less polymorphic 'f' it might be ok. Simon | -----Original Message----- | From: Hal Daume III [mailto:hdaume@ISI.EDU] | Sent: 21 March 2003 22:29 | To: Simon Peyton-Jones | Cc: oleg(a)pobox.com; haskell(a)haskell.org | | Excellent paper! I have started using some of the techniques already! | | But, back to the real question :). I now no longer think such a thing is | possible. Essentially what I want (given 'cast :: Typeable a, Typeable b | => a -> Maybe b' [1]), is to write something like: | | test :: forall a r . Typeable a => | (forall b . (Typeable b, Foo b) => b -> r) -> | a -> Maybe r | test f a = liftM f (cast a) | | but then 'b' is ambiguous. I'm not sure there is any way around | this. Can someone help? | | - Hal | | [1] is there any reason why parens are requires around class | contexts? i've always found this odd... | | -- | Hal Daume III | hdaume(a)isi.edu | "Arrest this man, he talks in maths." | www.isi.edu/~hdaume | | On Fri, 21 Mar 2003, Simon Peyton-Jones wrote: | | > You might also find the 'cast' function in Section 3 of "Scrap your | > boilerplate" useful. | > http://research.microsoft.com/~simonpj/papers/hmap/ | > I'm not certain, but it has the right smell. | > Simon | > | > | -----Original Message----- | > | From: oleg(a)pobox.com [mailto:oleg@pobox.com] | > | Sent: 21 March 2003 04:19 | > | To: hdaume(a)ISI.EDU; haskell(a)haskell.org | > | Subject: Re: simulating dynamic dispatch | > | | > | | > | > i'm hoping to be able to simulate a sort of dynamic dispatch based | > on | > | > class instances. | > | | > | It seems you want to dispatch based not on a type but on the | > | constraint of a type. | > | | > | You code almost worked. Here's the a bit updated and working version. | > | | > | class Foo a where { foo :: a -> Bool } | > | class Bar a where { bar :: a -> Bool } | > | | > | data FB = forall a . Foo a => MkFoo a | forall a . Bar a => MkBar a | > | | > | instance Foo FB where | > | foo (MkFoo x) = foo x | > | | > | instance Bar FB where | > | bar (MkBar x) = bar x | > | | > | -- some instances for the test | > | instance Foo Int where | > | foo x = x == 0 | > | | > | instance Bar Char where | > | bar x = x == 'a' | > | | > | | > | test x = case x of | > | (MkFoo a) -> Just $ foo a | > | (MkBar a) -> Just $ bar a | > | -- _ -> Nothing | > | | > | | > | -- *Main> test $ MkFoo (0::Int) | > | -- Just True | > | -- *Main> test $ MkFoo (10::Int) | > | -- Just False | > | -- *Main> test $ MkBar 'a' | > | -- Just True | > | -- *Main> test $ MkBar 'b' | > | -- Just False | > | | > | _______________________________________________ | > | Haskell mailing list | > | Haskell(a)haskell.org | > | http://www.haskell.org/mailman/listinfo/haskell | >

1 0