- Beginners - Haskell.org

Re: [Haskell-cafe] try, seq, and IO
by Jeroen van Maanen 16 Sep '10

16 Sep '10

Op 2010-09-15 18:38, Neil Brown schreef: > On 15/09/10 10:13, Jeroen van Maanen wrote: >> The past year I have been working on a port of my machine learning project named LExAu from Java to Haskell. I'm still very glad I took the jump, because the complexity curve appears to be log shaped rather than exp shaped. In one year I almost got to the functionality that had taken me five years to produce in Java (of course it helped a lot that I had a working prototype this time). >> >> There is one thing that still bothers me though: when I write seq or $! it doesn't seem to have any effect! >> >> Currently I am trying to add some exception handling to help me debug the system, but the code that I managed to produce depends on the logging statement to produce the desired result. :-( It looks like this, and only works when I uncomment the line '-- logger "Check sum": [...]', otherwise the exception is caught by the try around the body of the thread that this code runs in: >> >> do logger "Received update" [showString label, logs update] >> result<- >> try $! >> do maybeUpdatedModel<- return $ f update startModel >> theCheckSum<- return $ liftM checkSum maybeUpdatedModel >> -- logger "Check sum" [showString label, shows theCheckSum] >> return $! seq theCheckSum maybeUpdatedModel >> maybeNextModel<- >> case result of >> Right theMaybeNextModel -> return theMaybeNextModel >> Left exception -> >> do let exc :: SomeException >> exc = exception >> logger "Exception" [showString label, shows exception] >> return Nothing >> logger "Maybe next model" [showString label, logs maybeNextModel] >> >> For more context see: >> >> http://lexau.svn.sourceforge.net/viewvc/lexau/branches/totem/src/LExAu/Pipe… >> >> after line 241. >> >> Can someone explain why a few showStrings a shows and a putStrLn are more effective in forcing the check sum to be computed (which necessarily evaluates the complete updated model and reveals the lurking exception) than the seq on the line just below the logging statement? >> > I just looked at your code for a second time and I think I know. Here's my guess: > > It's all about the types, and weak head normal form. The "theCheckSum" item has type Maybe a, and you are looking for an exception in the "a" part that's wrapped by Maybe (I presume: the Just/Nothing is determined by the function "f", not "checkSum"). When you use seq or $!, you only evaluated to weak head normal form, For something of type "Maybe a", that's only the Just/Nothing part. Forcing that aspect to be evaluated only requires some evaluation of the function "f", and the checkSum function doesn't need to be applied, even if it is a Just value. However, your shows function digs deeper and evaluates the whole thing, so hence it will trigger the error where seq and $! won't. Ah, I didn't know that weak normal form evaluation doesn't force the evaluation of the argument of the Just constructor. That makes sense. (I confess that I added the liftM construction almost without thinking when the compiler told me that I couldn't just ask for the checkSum of maybeUpdatedModel and had not realized that this changed the type of theCheckSum. I also stubbornly ignored the telltale "Just" in the log statement.) > So, if I'm right, you need to change your function to make sure to evaluate the checksum itself. The deepseq package on Hackage may help here (use the deepseq function in place of seq: http://hackage.haskell.org/packages/archive/deepseq/1.1.0.0/doc/html/Contro…) The maybe function does the trick quite neatly. In fact, I added the checkSum method because my particular data stuctures have quite natural Integer valued functions that force evaluation of the complete, ... erm, in Java I would have said object graph, ... you know, ... everything. ;-) > I'm a little suspicious of the code as a whole though: why does checkSum throw an exception rather than returning a Maybe value? Or is it an exception somehow outside of your control? That is because the exception is thrown by an assert kind of thing. There are still bugs lurking in the code (strange, I have been so careful ;-> ), but I don't want to litter my code with Maybe types just in case there Maybe something wrong with it. I use Maybe frequently, for example, when a function may or may not return an updated data structure when given some extra information, but in those cases it is natural in the context of the algorithm to use a Maybe type. > Another thing: > > x <- return $ blah > > in a do block is bad style, and can always be replaced with: > > let x = blah > > Note that there is no "in" needed with let statements in do blocks (that confused me when first learning Haskell). That's funny, first I fixed my code: do let maybeUpdatedModel = f update startModel theCheckSum <- return $ maybe 0 checkSum maybeUpdatedModel return $! seq theCheckSum maybeUpdatedModel That worked beautifully. The exception is caught here as desired. Then I tried to get rid of the remaining '<- return'. However, when I write: do let maybeUpdatedModel = f update startModel theCheckSum = maybe 0 checkSum maybeUpdatedModel return $! seq theCheckSum maybeUpdatedModel It reverts to the old behavior. What is the subtle difference here? And let me guess, the next step is to replace do let blah blah return result by return $ let blah blah in result Right? Cheers, Jeroen

1 1

try, seq, and IO
by Jeroen van Maanen 15 Sep '10

15 Sep '10

The past year I have been working on a port of my machine learning project named LExAu from Java to Haskell. I'm still very glad I took the jump, because the complexity curve appears to be log shaped rather than exp shaped. In one year I almost got to the functionality that had taken me five years to produce in Java (of course it helped a lot that I had a working prototype this time). There is one thing that still bothers me though: when I write seq or $! it doesn't seem to have any effect! Currently I am trying to add some exception handling to help me debug the system, but the code that I managed to produce depends on the logging statement to produce the desired result. :-( It looks like this, and only works when I uncomment the line '-- logger "Check sum": [...]', otherwise the exception is caught by the try around the body of the thread that this code runs in: do logger "Received update" [showString label, logs update] result <- try $! do maybeUpdatedModel <- return $ f update startModel theCheckSum <- return $ liftM checkSum maybeUpdatedModel -- logger "Check sum" [showString label, shows theCheckSum] return $! seq theCheckSum maybeUpdatedModel maybeNextModel <- case result of Right theMaybeNextModel -> return theMaybeNextModel Left exception -> do let exc :: SomeException exc = exception logger "Exception" [showString label, shows exception] return Nothing logger "Maybe next model" [showString label, logs maybeNextModel] For more context see: http://lexau.svn.sourceforge.net/viewvc/lexau/branches/totem/src/LExAu/Pipe… after line 241. Can someone explain why a few showStrings a shows and a putStrLn are more effective in forcing the check sum to be computed (which necessarily evaluates the complete updated model and reveals the lurking exception) than the seq on the line just below the logging statement? Cheers, Jeroen

1 0

A question on seq
by Klaus Gy 15 Sep '10

15 Sep '10

Hi! Inspred from the discussion http://www.haskell.org/pipermail/beginners/2010-February/003396.html , I just try to understand the seq function a bit better. When I compare these two functions: firstSum :: Num a => a -> [a] -> a firstSum s [] = s firstSum s (x:xs) = seq help (firstSum help xs) where help = x + s secondSum :: Num a => [a] -> a secondSum [] = 0 secondSum (x:xs) = seq help (x + help) where help = secondSum xs What should be the difference? In my opinion both functions do not return a complete unevaluated thunk (secondSum returns a thunk of the form (THUNK + b) where THUNK contains a single numeral value). But it seems to me that the first function computes the output somehow linear in the sense that it does just a set of substitutions while the second functions has to create a tree to handle all the recursive calls of seq (sorry, my terminology is for sure a bit poor). So I would say the first function delivers a better performance. (In the discussion I mentioned, the second function was not discussed in this form with the seq implementation). Am I right with my thoughts? Thanks, fweth

3 3

Padding List with Zeros
by Lorenzo Isella 15 Sep '10

15 Sep '10

Dear All, I still have to find my way with immutable lists and list comprehension. Consider the following lists A=[0,10,20,30,40,50] B=[0,10,50] (i.e. B is a subset of list A; list A is already ordered in increasing order and so is B). C=[2,1,-5] i.e. there is a corresponding element in C for every element in B. Now, I would like to define a new list D having length equal to the length of A. The elements of D in the position of the elements of A in common with B are equal to the corresponding entries in C, whereas the other ones are zero i.e. D=[2,1,0,0,0,-5]. How can I achieve that? The first thought that comes to my mind is to define a list of zeros which I would modify according to my needs, but that is not allowed... Many thanks Lorenzo

8 13

Randomness, lists, and unfoldr
by Alex Rozenshteyn 14 Sep '10

14 Sep '10

I'm trying to build a list where each entry depends on the previous one. Unfoldr seemed like a good idea at the time. Unfortunately, my values are monadic values (specifically RVars, from the random-fu package). Okay, shouldn't be a problem; I just monadic bind and... > -- example code > updateCell :: Bool -> RVar Bool > updateCell False = return False > updateCell True = bernoulli (0.9 :: Double) > sim = sequence $ take 20 $ unfoldr (\x -> Just (x, x >>= updateCell)) (return True) > runRVar sim DevURandom [True,True,True,True,True,False,True,False,True,False,False,False,False,False,False,True,True,False,False,False] That output shouldn't be possible if I'm doing things right... It appears that each cell has an independent history. I'm stumped. Advice on threading monad input in general and random-fu in specific would be appreciated. -- Alex R

6 7

List Sorting and I/O
by Lorenzo Isella 14 Sep '10

14 Sep '10

Dear All, Thanks to the help I got from the list, I was able to (almost) finish a script that performs some data postprocessing (and the code is really amazingly short). Now, there are a few things left. Consider the lists bs = [4,5,3,1,5,2,7,2,8,2,2,3,3,5,6,7] and ms = [2,2,2,2,4,4,4,4,6,6,4,4,4,10,12,14] Now, I would like to sort bs (and that is easy) and then (since there is a 1-1 correspondence between the elements in ms and bs) re-order the elements in ms accordingly i.e. bs would become [1,2,2,2,2,3,3,3,4,5,5,5,6,7,7,8] and ms [2,4,4,6,4,2,4,4,2,2,4,10,12,4,14]. How can I achieve that? Finally, I would like to be able to save the two lists as plain text files (no commas, no brackets). I tried writeFile+Show, but this saves the lists exactly as printed on screen (whereas I simply would like a text file showing a column of numbers when opened by your favorite editor). Many thanks Lorenzo

2 2

Re: how to implement accesor function for given data type
by Brent Yorgey 13 Sep '10

13 Sep '10

On Mon, Sep 13, 2010 at 05:33:12PM +0200, Martin Tomko wrote: > Hi Brent, > thank you for your help. Indeed, I need to be able to distinguish > them in terms of single coordinate, tuple or list - that is crucial > in order to keep the logic. > I am not sure how your second suggestion would help though, because > then I would get a function to return the > CoordinateSet, but then I would need again to somehow extract the > individual vertices out of it for any mathematical processing. And > again, I will be faced by the same problem. just one wrapper further, > am I right? No, you won't still have the same problem. The problem before was that you wanted to write a function which could return values of several different types, which is not possible. (Well, technically, it IS possible, but not in a way that would be helpful to you.) This solution allows you to wrap the options up in a single type. Of course, you will later need to extract vertices out of the Coordinates type for processing -- but that's just fine, you can write the processing function by cases on the Coordinates type. However, you might decide that the intermediate step is not all that helpful and just write the mathematical processing directly by cases on Geometry. It depends on what the mathematical processing looks like, I suppose. > This is what I end up with: > > type Coordinate = (Float, Float) > > data Coordinates = Pt Coordinate | Ls (Coordinate, Coordinate)| Pl > [Coordinate] deriving (Show,Eq) -- this is what you called the > CoordinateSet > > data Geometry = Point FID Coordinates > | LineSegment FID Coordinates > | Polyline FID Coordinates > | Polygon FID Coordinates > deriving (Show,Eq) This looks wrong to me, since this would allow (say) a Point to have a list of coordinates, or a Polygon to have just a single coordinate. I think you want to stick with what you had before. > > Then, indeed, the whole Geometry ADT seems redundant, and could be It doesn't look redundant to me. For example, isn't there a difference between a Polyline and a Polygon (even if they have the same coordinates)? > Let us assume a practical example: I want to find vertices shared by > two geometries, using intersect or elem seems to be the way to go, > depending if either are lists or soem are single points (not sure > this will work on tuples... I would prefer a single solution for > all). > My thinking is that I need a function to get to the Coordinates of a > geometry somehow, and maybe convert the mto a vector, but that sounds > like a dirty trick not worthy of Haskell! Why not: shared :: Geometry -> Geometry -> [Coordinate] shared geo1 geo2 = sharedCoords (getCoords geo1) (getCoords geo2) sharedCoords :: Coordinates -> Coordinates -> [Coordinate] sharedCoords (Pt p1) (Pt p2) = if (p1 == p2) then [p1] else [] sharedCoords (Pt p1) (Ls (x,y)) = ... sharedCoords (Pt p1) (Pl cs) = ... ... and so on. This is what I mean by doing mathematical analysis by cases on Coordinates. -Brent

1 0

Selecting Arguments in Function to Feed Map
by Lorenzo Isella 13 Sep '10

13 Sep '10

Dear All, Suppose you have the function f x y z = x*y +z and that you want to iterate it on a list z=[1,2,3,4], with x=4 and y=3 then you would do the following map (f x y) z. Now consider the case in which the list is given by y e.g. y=[1,2,3,4], with x=4 and z=3. How can you iterate f on y (i.e. its second argument) while keeping x and y fixed? Lorenzo

5 4

how to implement accesor function for given data type
by Martin Tomko 13 Sep '10

13 Sep '10

Dear all, apologies for a newbie question, but I am returning to Haskell after years of hiatus and Java... I have the following data type (representing geometries): data Geometry = Point FID Coordinate | LineSegment FID (Coordinate,Coordinate) | Polyline FID [Coordinate] | Polygon FID [Coordinate] deriving (Show,Eq) type Coordinate = (Float, Float) And this is where I fail: I have no idea how to type getCoordinates, in order to match against the three different combinations -> it can result into a Coordinate, or a typle, or a List. I am sure it is possible! class Geoms a where getCoordinates :: a -> b instance Geoms Geometry where getCoordinates (Point _ a) = a getCoordinates (Polygon _ a) = a And I want to access the Coordinates for each given geometry. Note that I tried to define it using records: say, Polygon {getID::FID,gcoords::[Coordinate]}, but the coords function failed to match, due to having different return types for Geometry. Thank you very much, Martin

2 2

Haskell for POS (business) apps
by glpunzi＠lordzealon.com 13 Sep '10

13 Sep '10

Hi all, I work in a company thath needs to develop some applications. As IT Manager, I'm on the decision to choose language and platforms. For the moment, We are developing a POS system. The first prototype is beeing developed under Windev(1), but, I would like to move to opensource options as soon as posible. For this reason I'm here. I'm looking to all this languages thath take my attention to take a look, and I'm very curious about Haskell, for this I would like to learn a little about it. For our projects, we will need database access (RDBMS or Objects database), reports, serial ports access to communicate with external devices (serial display, ticket printers, cash drawers, and so on..)..web services..well...all thath a POS application will need. I would like to develop for it too, a Desktop and Web BackOffice, some application to take orders (PocketPC, Android) and so on..It suppose, all of this, will work under Linux or Windows (it's decision of my customers), and I would like to do it like a chameleon, to adapt to many type of customers as possible. Then, my main question is: I know (suppose), with Haskell you can develop whath you want, and I readed Scala is a good option, but I don't like the idea of depend of JVM, and Haskell do native executables. Is worth the effort for this type of applications? There are libs for this things? It's easy to maintain large projects? Sorry for my english and lack of knowledge :S PD: I come from a Delphi and Smalltalk background. (1)http://www.windev.com

3 4