- Haskell-Cafe - Haskell.org

restricted existential datatypes
by oleg＠pobox.com 12 Jan '07

12 Jan '07

Misha Aizatulin wrote > I am using existential boxes like > > data Box cxt = forall a . Sat (cxt a) => Box a > here Sat is taken from [1]: > > class Sat a where dict :: a > The result is a box type which can have variable context imposed on > its contents. What I noticed is that sometimes I want to write functions > that operate on the Box and make use of some part of the context without > knowing the context completely. Such a function would look something > like this: > > f :: (Contains cxt ShowCxt) => Box cxt -> String > > f (Box a) = show a It seems what you'd like is an opaque datum that responds to (generally open) set of messages giving a reply dependent on a message. Sounds like an object, doesn't it? Why does it have to be an existential? True, existentials (that is, type abstraction) is one way to implement objects. There are other ways. Let's consider a very simple example: > data Box = forall a . Show a => Box a > f (Box a) = show a Now, the *only* meaningful thing we can do with the value `a' after unboxing is to pass it to the function `show'. Right? One may wonder why not to perform this application to show right upfront: > data Box1 = Box1 String > box a = Box1 (show a) This is _precisely_ equivalent to the above. Thanks to lazy evaluation, the application `show a' won't be evaluated unless we really need its value. The obvious benefit of Box1 is the simplicity of it: no existentials. The value 'Box1' is an object that responds to only one message, `show'. We'd like to have several messages, and we'd like to have the set of messages open. There are two choices: HList or the typeclasses. Both do the same thing, only the heterogeneous set of dictionaries is explicit in the former approach and implicit in the latter. Given below is the example. The box data constructor can be hidden in a module; its details are not important anyway. What is important is the membership in the Boxable class. The code below works with GHC 6.4.1 (no advanced versions required) and even in Hugs. {-# OPTIONS -fglasgow-exts #-} module RestrictedEx where -- Box labeled l responding to a message msg gives the result x class Boxable l msg x | l msg -> x where box_value :: l -> msg -> x -- A few message labels data SHow = SHow data CastToInt = CastToInt data Print = Print -- Create one box data MyBox1 = MyBox1 String -- Define its response to messages instance Boxable MyBox1 SHow String where box_value (MyBox1 s) _ = s instance Boxable MyBox1 Print (IO ()) where box_value (MyBox1 s) _ = putStrLn s -- A function that takes any box that can be shown f1 :: Boxable b SHow String => b -> String f1 b = box_value b SHow

1 0

UDP client/server
by John Ky 12 Jan '07

12 Jan '07

Hello, Does anyone know where I can find a simple UDP client/server written in Haskell? Something along the lines of an echo server would do. Thanks -John

4 6

MapTuple is possible and easy
by oleg＠pobox.com 12 Jan '07

12 Jan '07

Marco Tu'lio Gontijo e Silva wrote: > is there a way to defined something as a map to use in tuples? Yes, it is: and it is quite easy and straightforward. Udo Stenzel > since c would be a variable that ranges over type classes, and that > doesn't exist. Of course it does: please see below (as well as several earlier posts on the Haskell list showing that Haskell classes *are* first-class). Here's the definition of mapTuple > mapTuple l (x,y) = (apply l x, apply l y) and here its inferred type: > *MapTuple> :t mapTuple > mapTuple :: (Apply l b y1, Apply l a y) => l -> (a, b) -> (y, y1) Our mapTuple applies to (in general) heterogeneous tuples and gives (in general) a heterogeneous tuple. Here's the complete code and the tests. {-# OPTIONS -fglasgow-exts #-} module MapTuple where class Apply l x y | l x -> y where apply:: l -> x -> y data SHow = SHow instance Apply SHow String String where apply _ = show instance Apply SHow Int String where apply _ = show instance Apply SHow Bool String where apply _ = show mapTuple l (x,y) = (apply l x, apply l y) -- Here, the result is a homogeneous tuple test1 = mapTuple SHow ("a",(1::Int)) test2 = mapTuple SHow ((1::Int),"b") test3 = mapTuple SHow (True,"b") -- ANother operation: SUcc data SUcc = SUcc instance Apply SUcc String String where apply _ x = x ++ x instance Apply SUcc Int Int where apply _ = succ instance Apply SUcc Bool Bool where apply _ = not -- Here, the result is a heterogeneous tuple (as is the argument) testH1 = mapTuple SUcc ("a",(1::Int)) testH2 = mapTuple SUcc ((1::Int),"b") testH3 = mapTuple SUcc (True,"b")

1 0

an advanced foldification problem
by Seth Gordon 11 Jan '07

11 Jan '07

I have a data type "Group", representing a group of geographic information that is all referring to the same location, and a function "mergeGroups" that tries to merge two groups: mergeGroups :: Group -> Group -> Maybe Group Then I have a function "mergeGroupToList" that tries to merge its first argument with every element of the second argument: mergeGroupToList :: Group -> [Group] -> [Group] mergeGroupToList g [] = [g] mergeGroupToList g1 (g2:gs) = case (mergeGroups g1 g2) of Nothing -> g2 : (mergeGroupToList g1 gs) Just g3 -> mergeGroupToList g3 gs How can I rewrite mergeGroupToList in terms of foldr?

3 2

Re: [Haskell-cafe] State monad strictness - how?
by Yitzchak Gale 11 Jan '07

11 Jan '07

Dean Herington wrote: > I can't seem to figure out how to achieve strictness > in the context of the State monad. Unfortunately, the current situation is that State is only available as a lazy monad, and StateT is only available as a strict monad. It seems to me that this should clearly be considered a serious bug in the library. It has been reported on numerous occasions over the years, but it has still not been fixed. At the very least, the two should be consistent. I would much prefer for them both to be lazy. I have written a lot of code that depends on that; it is the natural assumption in Haskell that everything is lazy by default, except seq, IO, and their friends. The obvious solution would be to have available both a lazy and a strict version of each monad: State, State', StateT, and State'T (or some such), with functions to convert between them. It is trivial to implement that in the current library. If someone can come up with a more elegant solution right away, that would be great. (Iavor - do you have a solution?) Otherwise, I think we have waited long enough. Let's implement the simple fix. This bug is a major inconvenience to users of this library. > (try 1000000) overflows the stack. In the current situation, you can use > where final = runIdentity $ execStateT prog (0::Int) ... > tick :: (Num a, MonadState a m) => m a ... Regards, Yitz

10 18

Using PAPI to measure performance with CPU events
by Alexey Rodriguez Yakushev 11 Jan '07

11 Jan '07

Dear all, I have added a page to the GHC commentary explaining how to use the PAPI library together with GHC to gather performance information from your CPU (cache misses, branch misprediction). At present only cache miss information is supported in a platform independent way (though not tested). Also, this implementation separates the performance information for the garbage collector and the mutator so it is quite useful if you are implementing an optimisation. The page also has some patches to use PAPI on the nofib suite. These patches are eventually going to make it into the HEAD, but I thought someone might find them useful meanwhile. Cheers, Alexey

1 1

[Haskell-cafe] Can't figure out how to "show" for type "Int -> (Int, Int)"
by Tom Titchener 11 Jan '07

11 Jan '07

Typing up and running (via Hugs) the examples in Wadler's excellent "Monads for functional programming" (here: http://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/baastad.pdf) I hit the inevitable "show" function error: ERROR - Cannot find "show" function for: *** Expression : eval answer *** Of type : Int -> (Int,Int) I can find lots of nice text about extending data for "show" (including the miraculous "Deriving") but... I'm showing my Haskell newbie roots by utterly failing to understand how to do this of a "higher-order" type (my best guess for the right term for the type Int -> (Int, Int)). It'd be a big help if somebody could tell me either: a) It's obvious, you moron, just <insert Haskell code here> or b) It's impossible, you moron, you're trying to violate the <insert Haskell rule here> Here' my code: data Term = Con Int | Div Term Term type M a = State -> (a, State) -- higher-order type, e.g. function type type State = Int -- type synonym eval :: Term -> M Int eval (Con a) x = (a, x) eval (Div t u) x = let (a, y) = eval t x in let (b, z) = eval u y in (a `div` b, z + 1) answer, error :: Term answer = (Div(Div(Con 1972)(Con 2))(Con 23)) error = (Div(Con 1)(Con 0)) I get the "ERROR" message when I type "eval answer" at the Hugs prompt. Thanks! Tom Titchener

3 2

HaskellForge?
by Imam Tashdid ul Alam 11 Jan '07

11 Jan '07

is it a good idea to have HaskellForge? Ruby, Lua and some other languages have already adopted GForge, and I must say, those sites look *impressive*!!! any Ruby programmer on the list? can anyone provide an estimate of the amount of work involved? cheers, and long live the lambda revolution. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

13 14

restricted existential datatypes
by Misha Aizatulin 10 Jan '07

10 Jan '07

hi, I am wondering whether it would be possible to use the existing haskell type system to simulate a certain feature. Namely, I am trying to apply ideas from [1] to existential datatypes. First I will describe the problem and later say something about the context in which it arose. I am using existential boxes like > data Box cxt = forall a . Sat (cxt a) => Box a here Sat is taken from [1]: > class Sat a where dict :: a The result is a box type which can have variable context imposed on its contents. What I noticed is that sometimes I want to write functions that operate on the Box and make use of some part of the context without knowing the context completely. Such a function would look something like this: > f :: (Contains cxt ShowCxt) => Box cxt -> String > f (Box a) = show a The type is meant to say that the context of the box must contain Show as one of the classes. I would imagine the Contains class to be something like > class Contains cxt subCxt where > subDict :: cxt a -> subCxt a Now inside f I would like to have the real (Show a) context available. So I'd have an instance > (Sat cxt a, Contains cxt ShowCxt) => Show a where > show = -- <the show function extracted from (subDict dict)> This instance of course does not work in ghc, because cxt is hanging in the air - I get an error whenever it tries to infer (Show a). The question I'd like to ask is whether there is some trickery to circumvent this problem. In the f function I'd like to be able to hint to the compiler that I want Show to be derived from cxt which is attached to the Box, but I see no way of doing that. (This by the way seems connected to http://www.mail-archive.com/haskell@haskell.org/msg19564.html) Now a couple of words about where I stumbled upon this problem. I am writing a program that is supposed to use plugins. The plugins operate among other things on Boxes as above. Now some plugins would like to demand some additional capabilities from the Box that cannot be foreseen at the spot where Box is defined. Parametrizing over context seems a very natural solution to me - leading to the problem above. I would be very thankful for any suggestions! Cheers, Misha Aizatulin 1. John Hughes, "Restricted Data Types in Haskell", September 4, 1999

3 3

Re: [Haskell] Re: state of HaXml?
by Taral 10 Jan '07

10 Jan '07

On 1/10/07, Malcolm Wallace <Malcolm.Wallace(a)cs.york.ac.uk> wrote: > Actually, I'm pretty sure that most Haskell RTS implementations have a > finalizer attached to all file handles. Once the file handle is no > longer reachable from the program graph (even if its data has not been > fully consumed), the GC will close the file (via the finalizer) before > reaping the memory associated with the handle. That's not the point. The GC will only close the file when the heap is under pressure. It does not aggressively close the file, so the file may stay open for longer than the user likes. For a read-only operation, this shouldn't matter, however on some platforms an open file handle can prevent deletion of the file. -- Taral <taralx(a)gmail.com> "You can't prove anything." -- Gödel's Incompetence Theorem

2 1