- Haskell-Cafe - Haskell.org

Re: Generating "setMember" functions for record structures
by Peter Simons 23 Sep '03

23 Sep '03

Peter Gammie writes: > Haskell Report, Sec 3.15.3 Great, that's exactly what I need. Thanks a lot to all who replied! Peter

1 0

Generating "setMember" functions for record structures
by Peter Simons 23 Sep '03

23 Sep '03

Hi, in one of my programs, I have to modify individual fields of a pretty large record structure quite frequently. Assume the structure is: > data State = State { foo :: [Int] > , bar :: [String] > } Then I'd like to have functions setFoo and setBar, which copy a State but replace the field in question with a given value. This is implemented as: > setFoo :: State -> [Int] -> State > setFoo st x = State { foo = x > , bar = bar st > } > setBar :: State -> [String] -> State > setBar st x = State { foo = foo st > , bar = x > } Now, defining these helper functions for large records is not what I call an interesting job. Thus I wonder, is there any way to automate this task? I thought about using Template Haskell, but I haven't used it at all yet and am uncertain about how difficult accomplishing this would be. I also thought about using "Data.Generics", which I know better, but the generic approach feels like over-kill for this task. In order to use it, I'd have to re-design my data structure as well. So this isn't too attractive ... Any ideas? Comments? Source Code? :-) Peter

3 2

garbage collection and Ptr/ForeignPtr/StablePtr
by Bayley, Alistair 23 Sep '03

23 Sep '03

Should I expect that Ptr memory allocated with malloc is garbage collected when no longer used by the Haskell runtime? The FFI spec doesn't say so explicitly (that I could see); AFAICT this is how the pointer types behave: Ptr : freed when no longer used/referenced ForeignPtr : like Ptr, but will also run a finaliser when freed StablePtr : not freed or collected (I haven't tested this; I've only read the FFI spec.) ***************************************************************** The information in this email and in any attachments is confidential and intended solely for the attention and use of the named addressee(s). This information may be subject to legal professional or other privilege or may otherwise be protected by work product immunity or other legal rules. It must not be disclosed to any person without our authority. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. *****************************************************************

2 1

Re: Thanks: (was Question about categories)
by Bill Halchin 23 Sep '03

23 Sep '03

2 1

Thanks: (was Question about categories)
by Graham Klyne 22 Sep '03

22 Sep '03

Thanks to everyone who responded to my question about category theory. The responses turned up some interesting and useful material on the web, which I'm still digesting. Notably [1] [2]. There's something in the introduction of [2] that I think will help me get a handle on this: [[ ... objects are not collections of "elements," and morphisms do not need to be functions between sets (thus morphisms cannot be applied to "elements" but only composed with other morphisms). Any immediate access to the internal structure of objects is prevented: all properties of objects must be specified by properties of morphisms ... ]] My earlier supposition was that an "object" was roughly in correspondence with a member of a set, but I'm coming to perceive that "object" corresponds more with the notion of a set or collection of some (unspecified) things. #g -- [1] http://www.cs.toronto.edu/~sme/presentations/cat101.pdf [2] http://www.di.ens.fr/users/longo/download.html which has a link to content of the (apparently) out-of-print book: [[ CATEGORIES TYPES AND STRUCTURES An Introduction to Category Theory for the working computer scientist Andrea Asperti Giuseppe Longo FOUNDATIONS OF COMPUTING SERIES, M.I.T. PRESS, 1991 ]] _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ------------ Graham Klyne GK(a)NineByNine.org

3 2

RE: garbage collection and Ptr/ForeignPtr/StablePtr
by Simon Marlow 22 Sep '03

22 Sep '03

> Should I expect that Ptr memory allocated with malloc is > garbage collected > when no longer used by the Haskell runtime? The FFI spec > doesn't say so > explicitly (that I could see); AFAICT this is how the pointer > types behave: > Ptr : freed when no longer used/referenced > ForeignPtr : like Ptr, but will also run a finaliser when freed > StablePtr : not freed or collected No, all memory that you allocate with the FFI must be freed explicitly. You can arrange for memory to be deallocated when no longer referenced by using a ForeignPtr, and using the finalizer to free the memory. Bear in mind that if your application has large, or strict, memory requirements, then relying on the ForeignPtr method may not be the best solution, because finalizers can be unpredictable. Cheers, Simon

1 0

Re: An IO Question from a Newbie
by Jon Cast 22 Sep '03

22 Sep '03

> On Fri, 12 Sep 2003 16:27:59 -0600 > Matt O'Connor <angagon(a)earthlink.net> wrote: > > > Hello all. I'm new to functional programming and Haskell, but have > > been programming in C and Java for a while. I've been going through > > the tutorials and whatnot on haskell.org. I've read from the Gentle > > Introduction to Haskell about IO and some of the other stuff and I > > have a question about it. > > > > main = do putStr "Type Something: " > > str <- getLine > > putStrLn ("You typed: " ++ str) > > > > When compile and run this code the "Type Something: " isn't displayed > > until the putStrLn. So there is no prompt. The output looks like > > this. > > > > s > > Type Something: You typed: s > > > > But if I change the putStr "Type Something: " to a putStrLn or put a > > \n at the end of the string it displays the text immediately (ie, when > > I want it to). Is there a good reason for this? Am I doing something > > wrong? Or do I need to call some kind of standard output flush? > > Yes, the problem is that the first line is not being flushed. Importing > hFlush and stdout from IO (or System.IO) and adding hFlush stdout after > you putStr will fix it. Alternatively, you could change the buffering > on stdout to NoBuffering. I don't know if there is a standard > putStrWithFlush function or just a better answer than this. A > putStrWithFlush would be trivial to write or more generally to a > HOF that flushed after performing the action passed to it. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Just thought I'd point out (in case it isn't clear) that this function is flushAfter h a = liftM2 const a (hFlush h). Not much of an improvement... Jon Cast

1 0

(Off-topic) Question about categories
by Graham Klyne 19 Sep '03

19 Sep '03

(I'm asking here because I believe there is some overlap between category theory and functional programming cognoscenti...) It has been suggested to me that categories may be a useful framework (more useful than set theory) for conceptualizing things for which there is no well-defined equality relationship. (The discussion is about resources in WWW.) I've done a little digging about category theory, and find some relatively approachable material at: http://www.wikipedia.org/wiki/Category_theory http://www.wikipedia.org/wiki/Class_(set_theory) and nearby. But I'm hitting a mental block with this (and other places I've look don't add anything I can grok). The definition of a category depends on the definition of a morphism, and in particular the existence of an identity morphism for every object in a category. The definition of an morphism is in terms of equality of compositions of morphisms: for f : A -> B we have Id[B]. f = f = f . Id[A] My problem is this: how does it make sense to define an equality of morphisms without some well-defined concept of equality on the underlying objects to which they apply? That is, given object X and an object Y, it is possible to examine them and determine whether or not they are the same object. And if the underlying objects have such a concept of equality, what prevents them from being sets or members of sets? But categories are presented as being more general than sets. Does anyone see the cause of my non-comprehension here? #g ------------ Graham Klyne GK(a)NineByNine.org

6 5

How to detect finite/infinite lists?
by Juanma Barranquero 19 Sep '03

19 Sep '03

Extremely-newbie questions: Is there any way to know if a list is finite or infinite, other than doing: length l and waiting forever? :) I ask because I was learning Haskell by writing some pretty naive implementation of surreal numbers, where I used lists for left and right surreal sets, and I wanted to do some operations on the sets (like finding the maximum/minimum), but obviously just on finite sets. I vaguely suspect the answer is going to be: "No, because lists are lazy (at least when they are :) and there's no general way to know beforehand how many elements they're going to have". But still, if I write x = [1..5] the compiler knows pretty well x is not going to grow any new member... (Unrelated) Is there any standard function to do: interleave [] _ = [] interleave _ [] = [] interleave (x:xs) (y:ys) = x : y : interleave xs ys It's pretty easy to implement as shown or via zipWith, but given that Haskell 98 already includes some "basic" functions (like cycle, iterate, etc.) I wonder if I've missed this one somehow. Thanks, /L/e/k/t/u

4 5

Re: How to detect finite/infinite lists?
by Juanma Barranquero 18 Sep '03

18 Sep '03

On Thu, 18 Sep 2003 14:20:46 -0400, "David Barton" <dlb(a)patriot.net> wrote: > that's halting problem equivalent. Yes, I know it's a halting problem, in the general case. But the compiler could try to say if it knows it *is* a finite list. So: x = [1..10] y = [1..] z = someFunctionOrOther knownToBeFinite x -> should return Just True knownToBeFinite y -> should return Just False knownToBeFinite z -> should return Nothing ("I don't know"). or something along these lines. > Nope. Ok. Thanks, /L/e/k/t/u

1 0