- Haskell-Cafe - Haskell.org

A question about "monad laws"
by Deokjae Lee 14 Mar '08

14 Mar '08

Tutorials about monad mention the "monad axioms" or "monad laws". The tutorial "All About Monads" says that "It is up to the programmer to ensure that any Monad instance he creates satisfies the monad laws". The following is one of the laws. (x >>= f) >>= g == x >>= (\v -> f v >>= g) However, this seems to me a kind of mathematical identity. If it is mathematical identity, a programmer need not care about this law to implement a monad. Can anyone give me an example implementation of monad that violate this law ?

28 58

Problem making a program in ghc
by Maverick 14 Mar '08

14 Mar '08

Hi, I have a problem when I am trying to use a binary file generated by ghc make in Windows. Ihave writed an application that parses xml files and returns a result(using HaXml), this is published as a service, I implemented a server(withSocketsDo), the server listen the port 5760 in a forever fashion,when a message arrives, then the program creates a new thread (forkIO)for attend the request. This works fine when I run it from ghci, when I make the program and run the binary (in Windows), the requests arrive to the program but I think that the response can´t be sentbecause the front end can´t receive the response (I am calling theservice from a .Net web application), I have a log that confirms that the response arrives correctly. I use make like this: ghc --make -package HaXml Main.hs HermesService.hs ..... What could be the problem? I am using HaXml 1.13.2 with Ghc 6.6.1, thanks in advance. Alvaro Sejas UMSS Cochabamba - Bolivia ______________________________________________ Enviado desde Correo Yahoo! El buzón de correo sin límite de almacenamiento. http://es.docs.yahoo.com/mail/overview/index.html

4 3

Naming as infection
by Greg Meredith 14 Mar '08

14 Mar '08

All, Here <http://biosimilarity.blogspot.com/2008/03/naming-as-dialectic.html> is a deliberately provocative posting (with running code and a shameless plug for BNFC) on the process of introducing naming and name management into the design of data structures. Comments greatly appreciated. Best wishes, --greg -- L.G. Meredith Managing Partner Biosimilarity LLC 806 55th St NE Seattle, WA 98105 +1 206.650.3740 http://biosimilarity.blogspot.com

1 0

Re: Some clarity please! (was Re: [Haskell-cafe] Re: (flawed?) benchmark : sort)
by Conor McBride 14 Mar '08

14 Mar '08

Hi On 13 Mar 2008, at 23:42, kahl(a)cas.mcmaster.ca wrote: > Conor McBride <conor(a)strictlypositive.org> responded to my comment: > >>> (mapMonotonic should of course be removed, too, >>> or specified to fail (preferably in some MonadZero) >>> if the precondition is violated, >>> which should still be implementable in linear time.) >> >> What's wrong with mapMonotonic that isn't wrong >> with, say, sortBy?, or Eq instances for parametrized >> types? > > Prelude> :m + Data.Set > Prelude Data.Set> toAscList $ mapMonotonic (10 -) (fromList [1 .. 5]) > [9,8,7,6,5] > Prelude Data.Set> 5 `member` mapMonotonic (10 -) (fromList [1 .. 5]) > False > > > Something's certainly wrong there! But nothing out of the ordinary: garbage in, garbage out. Happens all the time, even in Haskell. Why pick on mapMonotonic? Prelude Data.List> sortBy (\_ _ -> GT) [1,3,2,5,4] [4,5,2,3,1] Prelude Data.List> sortBy (\_ _ -> GT) [4,5,3,2,1] [1,2,3,5,4] I guess there's a question of what we might call "toxic waste"---junk values other than undefined. I think undefined is bad enough already. So the type system can't express the spec. I don't think we should be casual about that: we should be precise in documentation about the obligations which fall on the programmer. Some dirt is pragmatically necessary: we shouldn't pretend that it ain't so; we shouldn't pretend that dirt is clean. > > >> >> Before we can talk about what == should return, >> can we settle what we mean by = ? > > ``='' is not in the Haskell interface! ;-) No, but "is" is in the human interface! > > Therefore, I talked only about (==). Ah, but you talked about things. Which things? Is one of the things you talked about the same as (==)? the same as (flip (==))? > > The best way to include ``='' seems to be the semantic equality of > P-logic > [Harrison-Kieburtz-2005], which is quite a heavy calibre, > and at least in that paper, classes are not yet included. I expect it's hard work. It's hard work in much better behaved systems. My point is that it's worth it, in order to facilitate more meaningful discussions. All the best Conor

1 0

Re: Some clarity please! (was Re: [Haskell-cafe] Re: (flawed?) benchmark : sort)
by Conor McBride 13 Mar '08

13 Mar '08

Hi folks I'm late into this thread, so apologies if I'm being dim. On 13 Mar 2008, at 16:17, kahl(a)cas.mcmaster.ca wrote: > Adrian Hey <ahey(a)iee.org> wrote: > >> I would ask for any correct Eq instance something like the law: >> (x==y) = True implies x=y (and vice-versa) I wish I knew what = meant here. Did somebody say? I don't think it's totally obvious what equational propositions should mean. Nor do I think it's desirable to consider only those propositions expressible in QuickCheck. If = is reflexive and distinguishes undefined from True, then x = y implies (x == y) = True will be tricky to satisfy for quite a lot of types. What about undefined == undefined or repeat 'x' == repeat 'x' ? For some suitable (slightly subtle) definition of "finite", you might manage x finite and x = y implies (x == y) = True One rather intensional definition of x = y might be "x and y have a common n-step reduct" with respect to some suitable operational semantics. I don't think this is what Adrian had in mind, but it certainly falls foul of Wolfram's objection. > > The easiest counterexample are sets (or finite maps) > provided as an abstract data type (i.e., exported without access to > the > implementation, in particular constructors). > Different kinds of balanced trees typically do not produce the same > representation for the same set constructed by different construction > expressions. This suggests that we should seek to define x = y on a type by type basis, to mean "x and y support the same observations", for some suitable notion of observation, which might depend crucially on what operations are exported from the (notional or actual) module which defines the type. If so, it's clearly crucial to allow some observations which rely on waiting for ever, in order to avoid _|_-induced collapse. Something of the sort should allow this... > > Therefore, (==) on sets will be expected to produce equality of sets, > which will only be an equivalence on set representations. ...but this... > >> which implies (f x == f y) = True (for expression types which are >> instances of Eq). > > This specifies that (==) is a congurence for f, and is in my opinion > the right specification: (==) should be a congurence > on all datatypes with respect to all purely defineable functions. ...is more troublesome. Take f = repeat. Define f = f. I'd hope x == y = True would give us x = y, and that x == y would be defined if at least one of x and y is finite. That implies f x = f y, which should guarantee that f x == f y is not False. > But at least nowadays people occasionally do export functions > that allow access to representation details, [..] > I consider this as an argument to remove showTree from the > interface of > Data.Set, and to either specify toList to produce an ordered list > (replacing toAscList), or to remove it from the interface as well. Perhaps that's a little extreme but I agree with the sentiment. How about designating such abstraction- breaking functions "nosy", in the same way that functions which might break purity are "unsafe". > (mapMonotonic should of course be removed, too, > or specified to fail (preferably in some MonadZero) > if the precondition is violated, > which should still be implementable in linear time.) What's wrong with mapMonotonic that isn't wrong with, say, sortBy?, or Eq instances for parametrized types? > >> but if so would like to appeal to movers and shakers in the >> language definition to please decide exactly what the proper >> interpretation of standard Eq and Ord "class laws" are and in the >> next version of the report give an explanation of these > > Strongly seconded, inserting ``precise'' before ``explanation'' ;-) > > (And I'd expect equivalences and congruences to be accessible > on the basis of standard first-year math...) Before we can talk about what == should return, can we settle what we mean by = ? I think we need to pragmatic about breaking the rules, given suitable documentation and maybe warnings. We should at least aspire to some principles, which means we should try to know what we're talking about and to know what we're doing, even if we don't always do what we're talking about. I'll shut up now. Potatoes to peel Conor

1 0

Video / Slides: Type-driven testing in Haskell (Simon Peyton Jones)
by Robert Hulme 13 Mar '08

13 Mar '08

I was lucky enough to attend a lecture by SPJ yesterday. You're lucky that I taped it and have put it all online :-) http://www.foomongers.org.uk/videos/spj-typedriventestinginhaskell.html If you're a redditer please vote it up on programming.reddit! http://reddit.com/r/programming/info/6byuy/comments/ -Rob -- ----------------------------------------------------- "She's flushing me out with dogs and grenades, and a sincere desire to spend time with me" --Mark Corrigan "That's the way things are these days, let's just put a zip here, a swastika there. Who the hell even knows what these things were used for. Who cares?" --Mark Corrigan http://www.robhulme.com/ http://robhu.livejournal.com/

1 0

Exception handling when using STUArray
by Xiao-Yong Jin 13 Mar '08

13 Mar '08

Dear list, I'm using STUArray in some of my time critical number crunching code. I would like to know some way to catch the exceptions raised in the ST monad, ie. ArrayException. Looking through the Control.Exception module, I understand that those functions can only be used within IO monad. So my question is, what the best way to do exception handling in STUArray is. Plus, it would be helpful if I can also raise an exception in ST monad, but how? Thanks, Xiao-Yong -- c/* __o/* <\ * (__ */\ <

10 28

Bug with GADT in function Patterns?
by Hugo Pacheco 13 Mar '08

13 Mar '08

Hi guys, I have found a bug on the compiler (at least ghc >6.8.2). For some module (yes, the example does nothing at all): *module Test where data Type a where Func :: Type a -> Type b -> Type (a -> b) PF :: Type a -> Type (PF a) data PF a where ID :: PF (a -> a) test :: Type a -> a -> a test (PF (Func _ _)) ID = ID* I get the impossible: *$ ghci Test.hs -fglasgow-exts GHCi, version 6.9.20080303: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. [1 of 1] Compiling Test ( Test.hs, interpreted ) ghc-6.9.20080303: panic! (the 'impossible' happened) (GHC version 6.9.20080303 for i386-apple-darwin): Coercion.splitCoercionKindOf $co${tc aog} [tv] <pred>t_ao8{tv} [tau] ~ a{tv aob} [sk] -> a{tv aob} [sk] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug* However, the following implementations of *test* compile ok: *test :: Type a -> a -> a test (PF _) ID = ID test :: Type a -> a -> a test (PF (Func _ _)) x = x* It has something to do with mixing different GADTs contructors. Should this be submitted as a bug as it is? Cheers, hugo

2 4

IO () and IO [()]
by Paulo J. Matos 13 Mar '08

13 Mar '08

Hello all, I find it funny that IO () is different from IO [()]. For example, if I define a function to output some lines with mapT, I would do: outputLines :: Int -> IO () outputLines i = mapM (putStrLn . show) (take i $ iterate ((+) 1) 1) However, this is in fact outputLines :: Int -> IO [()] I would like to know if in fact there's any difference in practice between (), [()], i.e. if in practice the difference matters. My first guess is that this is just a consequence of the Haskell type system and so that everything fits this really needs to be like this. Because mapM :: (Monad m) => (a -> m b) -> [a] -> m [b] So I guess that it makes sense that you get IO [()] instead of IO (), and adding an exception just to say that [()] == () isn't good. By the way, as a consequence can you possibly get IO (()) or IO ([()]) and are these all different from each other? Cheers, -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK Sponsor ECS runners - Action against Hunger: http://www.justgiving.com/ecsrunslikethewind

16 20

An offer to any haskell projects out there.
by michael＠schmong.org 13 Mar '08

13 Mar '08

Hello, My name is Michael Litchard. I'm a techie living in silicon valley, and I want to move into tech writing. I've got the background, now I need a portfolio. I figured the best way to go is to attach myself to some open source projects, and haskell has had my heart for a few years now. I am by no means an expert at haskell. My expertise is writing. So I make this offer. If you need documentation written for your haskell project, I'm your man. Whatever it is, I'll write it or edit it. Thanks for your time. P.S If this was the wrong list, or if anyone has other ideas about how to propogate my proposal, please let me know. Michael

6 5