- Haskell-Cafe - Haskell.org

RE: foldr
by Garner, Robin 02 Jan '04

02 Jan '04

It's not too difficult to do: think 'fold map' and put it in the form that foldr needs. cheers -----Original Message----- From: James Ealing [mailto:jamesealing2000@yahoo.co.uk] Sent: Friday, 02 January, 2004 1:54 PM To: haskell-cafe(a)haskell.org Subject: foldr Hi all, If I have a function: it f [a0, a1, a2, ...] = [a0, f a1, f (f a2), ...] Is there any way of expressing it f as an instance of foldr? Many thanks, Jim ________________________________________________________________________ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

Module creation
by J & M van Berchem 02 Jan '04

02 Jan '04

New to Haskell, I got a version, through Fink, for my Mac OS X. I like the interpreter very much, but I do not see how I may get out of "Prelude" in order to write a program. Could you advise me ? Thanks in advance Jacques van Berchem

2 1

Parsec question
by Mark Carroll 01 Jan '04

01 Jan '04

I tried posting this before but, from my point of view, it vanished. My apologies if it's a duplicate. In http://www.cs.uu.nl/~daan/download/parsec/parsec.html we read, > testOr2 = try (string "(a)") > <|> string "(b)" > > or an even better version: > > testOr3 = do{ try (string "(a"); char ')'; return "(a)" } > <|> string "(b)" Why is the latter better? (BTW, I like Parsec. Thanks, Daan. (-:) -- Mark

3 3

Monads
by Mark Carroll 01 Jan '04

01 Jan '04

Omitting the typeclass bit, I'm trying to write something like (s1 -> s2) -> StateT s1 m () -> StateT s2 m a -> StateT s1 m a That is, it sequences two StateT computations, providing a way to translate from the first's state to the second to keep the chain going. I can easily write something for when s1 and s2 are the same, and my understanding of much of Control.Monad.* remains tenuous at best, but if it's easy for anyone to provide me with some tips, then I thought I should mention that it'd certainly be helpful. And Happy New Year, everyone! -- Mark

3 3

Type checking/inference
by Lee Dixon 28 Dec '03

28 Dec '03

Hi, I've run into a small problem whilst doing some manual type checking, to see if I could match the results given by hugs prelude> :t foldr filter foldr filter :: [a] -> [a -> Bool] -> [a] -- This was fine and was the same as my answer, so I tested it with prelude> foldr filter [1,2,3,4] [even,odd] -- and the answer was indeed an empty list -- However I got stuck when attempting to derive the result of map (foldr filter) -- Hugs says that: prelude> :t map (foldr filter) map (foldr filter) :: [[a]] -> [[a -> Bool] -> [a]] Two main questions: 1/ How does hugs derive this answer? 2/ What input can I give so that it yields a correct result? I've tried giving it a list of lists but it fails... Any pointers would be greatly appreciated! Many Thanks, Lee _________________________________________________________________ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger

4 3

Re: Perspectives on learning and using Haskell
by Graham Klyne 24 Dec '03

24 Dec '03

[switching to Haskell-cafe] At 19:37 23/12/03 +0100, Tomasz Zielonka wrote: >On Tue, Dec 23, 2003 at 05:26:20PM +0000, Graham Klyne wrote: > > > [1] http://www.ninebynine.org/Software/Learning-Haskell-Notes.html > >Thanks, that was a nice reading :) Thanks! (If by any chance there's anything here that might be useful for the Wiki, anyone may feel free to plunder it.) >I have some comments: > >8. Your explanation of Functor excludes many useful Functors which are > rather not collections. For example, every monad (like IO) can > be a Functor if you take fmap = Monad.liftM. > > For [] and Maybe this would give the same operation as in their > normal instances. That's an interesting perspective that I wasn't aware of... I need to think about that. Meanwhile, I've added your observation to my notes. [later] It now seems to me that (some?) Monads are kinds of Functors, generalized to handle the "no value" case, and also composition. This also had me thinking about sequence: is there a generalization to arbitrary monads that rearranges the monadic structure? >11 and 18. > If you define an instance of Monad for ((->) e) then > > return (putStrLn "Hello!") 'x' > > is a proper IO () value. Probably still not sensible ;) Ah, I think I see your point. It would apply where monads are "nested", right? > Special treatment of 'return' could be helpful, but I am afraid that > it could also make it look special, like a return keyword in C. I certainly wouldn't argue for special treatment _in the language_, but OTOH, I think it might be helpful if compiler diagnostics hinted at the possibility when a type error is detected in a form like return x y. #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

2 1

Re: looking for data structure advice
by Jon Cast 24 Dec '03

24 Dec '03

Conor McBride <c.t.mcbride(a)durham.ac.uk> wrote: <snip> > I've always been a little bothered by the MonadPlus class: zero and > plus are associated (no pun intended) in my mind with monoidal > structure. Is there more to MonadPlus than a clumsy workaround for > the lack of quantified constraints? Yes. For every functor m with a MonadPlus instance, m () has /two/ monoids, (mzero, mplus) and (return (), (>>)). MonadPlus is thus no more a workaround than the category Field; MonadPlus is simply a way to specify that a functor has two monoid-like structures, one more exact than the other, together with the expectation that the two monoids are related in a manner similar to the relationship of the two (more-or-less-) groups that make up a field. > If we could have quantified constraints, e.g. > > (Monad m, forall x. Monoid (m x)) > > wouldn't that be better than having Monad-specific monoids? No. Consider the monad Writer (IO ()). The Writer monad wants a Monoid instance, and the most natural such instance is often (return (), (>>)). OTOH, this monad is always wrong in the cases where, currently, you would use mplus. So you can't just replace MonadPlus with Monoid; you need to be more specific about your choice of monoid than can be accounted for by a single class. <snip> Jon Cast

2 1

Hugs Nov-2003 release: traceShow goes missing
by Graham Klyne 20 Dec '03

20 Dec '03

I've just upgraded my Hugs installation to the Nov-2003 release, and I notice that function traceShow is missing from library module Debug.Trace. I assume this is unintentional, as it's still mentioned in the Hugs manual. (In my installation, I've copied the 2-line function implementation from the previous Hugs release into this module, and added it to the module export list.) #g -- ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

Re: To show or not to show french accents
by MR K P SCHUPKE 19 Dec '03

19 Dec '03

Lets assume I get a unicode terminal, and I am reading and writing from unicode files, how does Haskell (or more specifically GHC cope with this)? (PS: I am not a member of haskell-cafe mailing list, so please CC me in to any replies in this thread)... Keean.

1 0

Re: To show or not to show french accents
by Jon Fairbairn 19 Dec '03

19 Dec '03

(note change of forum from glasgow-haskell-users) On 2003-12-19 at 12:28GMT MR K P SCHUPKE wrote: [ > I wrote: ] > >The problem is that if you are reading single bytes, 233 is > >not necessarily é. > > Erm, Internationalisation is not my thin as such... but I can't help > commenting that from a systems point of view this is an utterly bad > sitiation to be in... It certainly is. > I though Haskell used unicode? It's supposed to. Note that I said "/if/ you are reading a single byte", meaning that I was talking about the (not uncommon) curcumstance where the underlying operating system presents you with bytes each of which represents a single character (ie not something like utf-8). Haskell is supposed to deal with Unicode internally, but the I/O system's treatment of it is not currently in a happy state, at least partly because of what lies beneath. > I thought in unicode the id of a character was fixed > irrespective of language. It is. > Where is unicode support lacking? All over the place. There's this monstrous notion of "locale" that means that if you move your computer across the border from Germany into Poland and change the system settings appropriately, all character files change their meanings. It stems from files being untyped, and as all good Haskell programmers know, untyped is a Bad Thing. Jón -- Jón Fairbairn Jon.Fairbairn(a)cl.cam.ac.uk

1 0