- Haskell-Cafe - Haskell.org

Re: [Haskell] Second draft of the Haskell 2010 report available
by Henk-Jan van Tuyl 30 Jun '10

30 Jun '10

On Tue, 29 Jun 2010 17:01:54 +0200, Simon Marlow <marlowsd(a)gmail.com> wrote: > Comments on the draft report are welcome, before I finalise this and > sign off on Haskell 2010. Subsection 12.3, "Language extensions", mentions the FFI as a language extension, but FFI is now part of the standerd; the same goes for the "extensions" mentioned at the end of the subsection. Regards, Henk-Jan van Tuyl -- http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html --

2 1

whine and solution about programmers not respecting documentations
by Albert Y.C.Lai 29 Jun '10

29 Jun '10

Some docs are in a miserable state of being incomplete. And then some programmers are in a miserable state of not respecting docs when the docs are complete. Why should anyone expect deleteBy (>=) 5 [0..10] to accomplish anything meaningful, if he/she respects the written docs? Today someone on #haskell expected it to accomplish something meaningful, even something mind-reading. The said person has been around for more than a year, not eligible for the "newbie" excuse. The said person is just the tip of an iceberg. The doc of deleteBy states: "The deleteBy function behaves like delete, but takes a user-supplied equality predicate." A precondition is that the user-supplied predicate is an equality predicate. (>=) is not an equality predicate, be it in the layperson sense of "it isn't analogous to (==)" or the mathematical sense of "it isn't an equivalence relation". If you respect the precondition or the authors of the doc, you should just never use deleteBy (>=) 5 [0..10], much less expect any meaningful result. I propose this solution: For each of deleteBy, groupBy, unionBy... we can usually conceive at least two implementations, behaving pretty much the same (answer, speed, space) when given an equivalence relation (modulo some rare concern when the equivalence relation has assymetric strictness properties), but behaving different when not, and their code sizes are pretty much the same. With more imagination and allowing some code bloat, perhaps we can conceieve more implementations. But two suffices, really. I propose that at each minor version of base, someone picks an implementation randomly. Here is a more radical, less labour-intensive solution, if you don't mind a judicious, correctness-preserving use of unsafePerformIO: at the first invocation of the process lifetime, pick an implementation randomly. The result frustrates people who disrespect the docs. My purpose is exactly that. The goal is to give people an incentive to not disrepect the docs. (If you think this is a nasty "stick, not carrot" incentive, on first thought I would agree. On second thought, it is not adding a stick, it is just removing a carrot. Programmer's carrot means his/her code "works" consistently. When deleteBy (>=) "works" consistently, you are giving out undeserved free carrots --- incentive to write more wrong code. I am proposing to remove undeserved free carrots.)

12 22

Call for comments: neither package
by Michael Snoyman 29 Jun '10

29 Jun '10

Hi all, I'll admit, the original idea for this package was something to place in ACME ;). However, it's goal is to solve a real problem: the lack of good instances on the Either type. As a brief summary, Either has no Applicative or Monad instances in the base library, has 2 reasonable definitions for Applicative, and there are conflicting orphan instances in the mtl and transformers packages. Also, the ErrorT transformer in those two packages introduces a superclass constraint many people would like to avoid. neither supplies three datatypes: AEither, MEither and MEitherT. AEither provides the Monoid version of the Applicative instance, MEither is the monadic version, and MEitherT is a monad transformer. The package provides instances for both the transformers and mtl libraries for MonadTrans, MonadIO and MonadCatchIO. The code is up on github[1], let me know what you think. Michael [1] http://github.com/snoyberg/neither

6 8

specifying package name in ghci import?
by Michael Vanier 29 Jun '10

29 Jun '10

Hi, Quick question about ghci: when I do this at the prompt: ghci> :m +Control.Monad.Cont I get Ambiguous module name `Control.Monad.Cont': it was found in multiple packages: mtl-1.1.0.2 monads-fd-0.0.0.1 Is there any way to fix this from within ghci (i.e. not involving mucking with ghc-pkg)? What I have in mind might be e.g. ghci> :m + "mtl" Control.Monad.Cont or something similar. Thanks, Mike

2 1

Re: [Haskell-cafe] Call for comments: neither package
by Antoine Latter 29 Jun '10

29 Jun '10

It looks like good work, but I would be hesitent about depending on a package which pulled in both mtl and tranformers. Maybe that's just superstition - I haven't tried it. Antoine On Jun 28, 2010 5:51 PM, "Michael Snoyman" <michael(a)snoyman.com> wrote: Hi all, I'll admit, the original idea for this package was something to place in ACME ;). However, it's goal is to solve a real problem: the lack of good instances on the Either type. As a brief summary, Either has no Applicative or Monad instances in the base library, has 2 reasonable definitions for Applicative, and there are conflicting orphan instances in the mtl and transformers packages. Also, the ErrorT transformer in those two packages introduces a superclass constraint many people would like to avoid. neither supplies three datatypes: AEither, MEither and MEitherT. AEither provides the Monoid version of the Applicative instance, MEither is the monadic version, and MEitherT is a monad transformer. The package provides instances for both the transformers and mtl libraries for MonadTrans, MonadIO and MonadCatchIO. The code is up on github[1], let me know what you think. Michael [1] http://github.com/snoyberg/neither _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

3 4

MonadCatchIO and bracket.
by Carl Howells 28 Jun '10

28 Jun '10

While working this weekend on the Snap web framework, I ran into a problem. Snap implements MonadCatchIO, so I thought I could just use bracket to handle resource acquisition/release in a safe manner. Imagine my surprise when bracket simply failed to run the release action sometimes. I quickly determined the times when it doesn't run are when Snap's monadic short-circuiting is used. I dug into the source of bracket (in the transformers branch, though the mtl branch has the same behavior in these cases, with slightly different code), and the reason why quickly became obvious: -- | Generalized version of 'E.bracket' bracket :: MonadCatchIO m => m a -> (a -> m b) -> (a -> m c) -> m c bracket before after thing = block $ do a <- before r <- unblock (thing a) `onException` after a _ <- after a return r When monadic short-circuiting applies, the "_ <- after a" line gets completely ignored. In discussions with #haskell on this topic, it quickly became clear that for any monad transformer that can affect control flow, the definition of bracket in MonadCatchIO doesn't keep the guarantee provided by bracket in Control.Exception, which is that the "after" action will be run exactly once. Because of that, I think bracket needs to be a class function. Furthermore, I think it needs to be a new class, ie class MonadCatchIO m => MonadBracketIO m where bracket :: m a -> (a -> m b) -> (a -> m c) -> m c This would allow its definition in cases where it makes sense (Snap or MaybeT IO), but it could be left out in cases where it doesn't make sense, like ListT IO, even though MonadCatchIO makes sense there. Carl Howells

4 3

Physical equality
by José Romildo Malaquias 28 Jun '10

28 Jun '10

Is there in Haskell a non monadic function of type a -> a -> Bool which test for physical equality of two values? It would return True if only if both values are the same object in memory. For instance: value1 = "good" value2 = "good" eq value1 value2 => False value1 = "good" value2 = value1 eq value1 value2 => True Romildo

5 4

Space leak with unsafePerformIO
by Henning Thielemann 28 Jun '10

28 Jun '10

Attached is a program with a space leak that I do not understand. I have coded a simple 'map' function, once using unsafePerformIO and once without. UnsafePerformIO has a space leak in some circumstances. In the main program I demonstrate cases with and without space leak. Without space leak the program writes a file to the disk until it is full. Any idea? The original problem is a function that is compiled by LLVM and shall be applied to a list in a mapAccumL manner.

2 3

Construction of short vectors
by Alexey Khudyakov 28 Jun '10

28 Jun '10

Hello, cafe I have question about vector package. Currently I'm playing with data types which are isomorphic to vectors of fixed length. Think about vector in N-dimensional space, list of parameters to function R^n → R, set of measurements with uncertainties, etc. They have different semantics but exactly the same representation and it's often advantageous to think about them as N-dimensional vectors. Then constructor like one below arise naturally. And I don't know how to write them properly. It's possible to use fromList but then list could be allocated which is obviously wasteful. > vector2 :: Double -> Double -> Vec2D > vector2 x y = ... > -- Vec2D is some wrapper around Vector data type Another question is there any specific problems with short vectors? They could be just 2 elements long. I mean performance problems

5 8

Why this doesn't type checked
by Victor Nazarov 28 Jun '10

28 Jun '10

I've allways found code like > -- maxBound (undefined :: Int) a bit strange as any usage of undefined is. Being Ruby on Rails developer I've personally found that one of the main Rails motos is being as readable as possible. Code must be as close to english as possible. Embeded DSLs like rspec are made mostly to made specs as close to english as possible. Having this in my mind I've decided that this code should be rewritten without undefined being mentioned. But I need some type signature and it should mention Int type. So I've got an idea about what I've called "fantom type functions". So wee need type families for it to work. > {-# LANGUAGE TypeFamilies #-} > module Main where > > import Data.Word I want the code I've mentioned to be rewrited as something like > -- maxBound :: MaxBoundOf Int As it is much more readable: "I want maxBound with the type of MaxBound Of Int". So here is the implementation of class Sizeable that implements sizeof operation. Which is type-indexed like maxBound is. sizeof returns number of bytes that occupy type when serialized to some binary stream. > class Sizeable sizeable > where type Sizeof sizeable > sizeof :: Sizeof sizeable We should like to make a default type but GHC still doesn't support it. > -- type Sizeof sizeable = Int Instances for all basic types > instance Sizeable Int > where sizeof = 4 Even without defaults we get type safety in these instances > type Sizeof Int = Int > instance Sizeable Word8 > where sizeof = 1 > type Sizeof Word8 = Int > > instance Sizeable Word16 > where sizeof = 2 > type Sizeof Word16 = Int > > instance Sizeable Word32 > where sizeof = 4 > type Sizeof Word32 = Int > > instance Sizeable Word64 > where sizeof = 8 > type Sizeof Word64 = Int The annoyance is the need to instantiate Sizeof type family every time. It will disappear once associated types' defaults will be implemented in GHC. What we get with this instances is following code. > main = > do print (sizeof :: Sizeof Word16) Let's try it. $ runhaskell this.lhs this.lhs:78:14: Couldn't match expected type `Int' against inferred type `Sizeof sizeable' NB: `Sizeof' is a type function, and may not be injective In the first argument of `print', namely `(sizeof :: Sizeof Word16)' In the expression: print (sizeof :: Sizeof Word16) In the expression: do { print (sizeof :: Sizeof Word16) } What can I do with this code to make it type-check? -- Victor Nazarov

5 5