- Haskell-Cafe - Haskell.org

Re: Simple problem from Hudak's SOE
by C.Reinke 24 Feb '03

24 Feb '03

> I checked out the type of "snd" in hugs and basically > figured out what it does, but I was wondering where I could find the > definition of this function. Is it possible to look at it in hugs? If your hugs is configured correctly to use an editor, simply type ":find snd". This underappreciated feature is one reason why you want to set the editor in hugs!-) http://cvs.haskell.org/Hugs/pages/hugsman/started.html hth, Claus

1 0

Debugging haskell
by Sengan.Baring-Gould＠nsc.com 24 Feb '03

24 Feb '03

http://www.catb.org/~esr/writings/taoup/html/ch01s06.html states that "debugging often occupies three-quarters or more of development time". I don't think that is my experience in Haskell... more like 1/4 at most. I was wondering what others felt. Sengan

7 7

Simple problem from Hudak's SOE
by M. Parker 24 Feb '03

24 Feb '03

I'm a real newbie to Haskell, and I'm having trouble with a particular problem dealing with higher-order functions. Exercise 5.9 in Hudak's "School of Expression" asks us to write a function, "makeChange," s.t. it makes change for a given amount using coins in a coin supply (represented by a list of decreasing integers). For example, make Change 99 [5,1] ==> [19,4] This chapter is about higher order functions, so I'm assuming he wants us to compute the result using the higher order functions defined in the chapter (map, foldl, foldr). I devised two solutions: {-Solution 1-} makeChange money coinList = zipWith div (scanl mod money coinList) coinList {-Solution 2-} makeChange' money (coin:coins) = let money' = money `mod` coin numCoins = money `div` coin in (numCoins: makeChange' money' coins) makeChange' 0 _ = [] makeChange' _ [] = [] However, my problem is that neither solution uses the higher-order functions defined in the chapter. So is it possible to solve this problem using map and fold? Furthermore, Hudak makes the case that we should strive to find the higher-order solutions instead of the recursive ones because the latter leads to clearer and more concise solutions. Although solution 1 is more concise, I feel like Solution 2 is clearer to me than Solution 1, but maybe this is just because I'm new to haskell and higher order functions. It just seems like its easier to understand the actual algorithm in solution 2 than in solution 1. Thanks, Matt Parker University of North Texas undergrad http://www.cs.unt.edu

2 2

x-type.net
by Domain Monitor 23 Feb '03

23 Feb '03

Hi, The x-type.net is in delete pending status and will be released soon. You have chance to get this domain with only $35.00. visit http://www.chinodomain.com for details Thank you.

1 0

Re: can this be written more easily?
by Dean Herington 23 Feb '03

23 Feb '03

[moved to haskell-cafe] While I largely agree with what Nils said, it does seem that arrays are a good match for your application. It is true, unfortunately, as you're discovering, that mutable arrays are awkward in a pure functional language. I think the most appropriate way to deal with them would depend on the larger perspective of your application's control structure. If the array manipulation is necessarily intermixed with input/output, for example, you might consider an essentially imperative approach using `IOArray`s in the `IO` monad. If the input/ouput and array manipulation tend to alternate, `STArray`s in the `ST` monad might offer a more functional approach. If the amount of array manipulation is small, then the approach you've shown so far might be entirely adequate. Dean "Mike T. Machenry" wrote: > I guess I figured that Arrays were the natural data type for the tickets > since it has a fixed size and the elements all have a specific player > associated with them. I am coming from a Scheme background so I am already > very fluent in list manipulation. I'm not an imperative programer, so that's > not really the problem. I just think that Arrays represent this data much > better. > > -mike > > On Fri, Feb 21, 2003 at 01:00:30PM +0100, Nils Decker wrote: > > "Mike T. Machenry" <dskippy(a)ccs.neu.edu> wrote: > > > Hey Everyone, > > > > > > I am having a hard time making a data structure that I can > > > incrimentally > > > update. Mostly because dealing with arrays is so tough. Does anyone > > > think I'm going about this completely the wrong way? This is what I > > > have. > > IMO there is normally no need to use arrays in haskell. You should > > use lists instead, because it is much more easy to use recursion > > over lists. Once you got the pattern, it feels like the natural > > way in haskell. > > It also helps to define more types than just one large type for everything. > > > > > data GameState = GameState { > > > dTickets :: Array Player (Array Ticket Int), > > > fTickets :: Array FugitiveTicket Int, > > > history :: [Move], > > > dLocations :: Array Player Stop, > > > fLocations :: Set Stop > > > } > > > > > > removeTicket :: GameState -> Detective -> Ticket -> GameState > > > removeTicket s d t = > > > s { tickets = (tickets s) // [(d,[(t,((tickets s)!d!t - 1))])] } > > > > why not use > > > > data Ticket = Ticket Int {-value-} deriving (Eq, Show) > > type Tickets = [Ticket] > > > > removeTicket :: Ticket -> Tickets -> Tickets > > removeTicket _ [] = fail "not there" > > removeTicket x (t:ts) > > | x == t = ts > > | otherwise = t : (removeTicket x ts) > > > > Is there a reason, to have different fields and types for detectives? > > data PlayerNames = MrX | Red | Green | Blue deriving (Eq,Show) > > If MrX needs special treatment ( computed move or information shown > > to the player ) you can patternmatch for MrX. For the usage of tickets > > and the history of moves there should be no difference. > > > > There might even be no reason to have PlayerNames as instance of enum. > > As i understand, you want to use succ(player) to find the next player > > to move. It can be easier to have a function that recurses over a > > list of players to run one round. > > > > > This remove ticket function is just terrible and it's common for me to > > > have to do operations like this. It's been hard to make this a > > > function that I can pattern match on, because which piece of data is > > > manipulated depends on the parmeter d (Detective) > > Just split up the huge record and have tiny functions to deal with > > every specific part of it > > > > Summary in a few words: Use many small functions instead of a few > > big ones. Use lists instead of arrays. If you use arrays, first understand > > why you can not use lists in that specific case. Learn to recurse > > over lists! Learn to use map, foldl and foldr. They save you a lot of > > typing and make most functions dealing with lists short and clear. > > > > You should derive Show for all your types and test every new function > > in hugs or ghci. > > > > Regards > > Nils Decker > > > > PS: I have learned haskell a year ago after using imperative languages > > all of my life. At first it is hard to get used to some concepts, > > but then they are wonderful. > > > > PPS: There is another list called haskell-cafe. It is used for discussion > > of problems while this list is meant for short threads and announcements. > > You might want to subscribe to it. > > > > > > -- > > Freedom of speech is wonderful - right up there with the freedom > > not to listen. > > > > Nils Decker <nils(a)ndecker.de>

3 3

a monadic if or case?
by David Roundy 20 Feb '03

20 Feb '03

Hello all. I was just thinking that there ought to be a better way to write the following code. It seems to be a common case that within a 'do' I bind a variable that I only intend to use once, in an if or case statement. It occurred to me that there ought to be a better way to do this. For example, it seems like the following code: whatisit :: String -> IO String whatisit f = do isdir <- doesDirectoryExist f if isdir then return "dir" else do isfile <- doesFileExist f if isfile then return "file" else return "nothing" could be replaced by something like: whatisit :: String -> IO String whatisit f = do ifM doesDirectoryExist f then return "dir" else ifM doesFileExist f then return "file" else return "nothing" Is there any way I could do something like this? -- David Roundy http://civet.berkeley.edu/droundy/

6 7

CDirent definition.
by Thaddeus L. Olczyk 18 Feb '03

18 Feb '03

Looking through the sources of ghc, I could not find the definition/devclaration of CDirent used by the FFI version of Posix directory commands (readdir, opendir etc... ). All I could find was type CDirent = () I'm confused by this. Can anyone clarify?

1 0

Re: Graphics output from Haskell as eps
by Sarah Thompson 17 Feb '03

17 Feb '03

> Has anyone done much work on outputting graphics in eps format > directly from > Haskell? Hmm... Actually it turns out to be really easy to generate EPS directly, so long as you're mostly just interested in drawing lines, which I am. I've already got something working which will probably be good enough for my purposes. Thanks to all who replied... Sarah PS: I'll post a link to my library once it does something more interesting than drawing a box in Ghostview! :)

1 0

Graphics output from Haskell as eps
by Sarah Thompson 17 Feb '03

17 Feb '03

Hi all, Has anyone done much work on outputting graphics in eps format directly from Haskell? My intention is to be able to generate publication quality diagrams for inclusion in TeX/LaTeX documents, without the size or quality penalties of using bitmaps. I want to write an automatic circuit visualisation utility somewhat analogous to the AT&T GraphViz tools, but which generates circuit diagrams that look 'right' to an electronic engineer (i.e. me). The idea is that a raw netlist (effectively a directed graph) will be generated by some other code, then fed into this tool, which will then generate a reasonably understandable circuit diagram. My most immediate requirement is to generate circuit diagrams, although longer term I'll probably also want to be able to generate chip floor plan diagrams too. I'm not too bothered about higher level drawing primitives - just something that can draw lines of appropriate widths and output text would be enough. Has anyone done anything already, or should I just pull down the PDF specs from Adobe and weigh in and write a library from scratch? If I do the latter, will anyone be likely to want to use it also? TIA, Sarah PS: To all who helped (esp. Sigbjorn Finne and Simon Peyton-Jones), the in-memory SQL database I was working on did actually work very well in the end. Unfortunately, my boss has insisted on a C++ rewrite - the C++ version (using strict evaluation and STL data structures roughly modelled on the Haskell version) is (I think, I've not measured this) a little slower, and about 5 - 10 times the size. It's been extended a little beyond the Haskell version, so it is difficult to be exact about the size difference, but gut feeling is that it took about five times as much code and about three times as long to write. And that's on the basis of someone who has over 10 years experience coding C++, but very little prior exposure to Haskell beyond the occasional recreational use. I think this proves Haskell's case as far as I'm concerned - keep up the good work, folks!

3 2

RE: Yet another weakly defined bug report
by Simon Marlow 17 Feb '03

17 Feb '03

> "Simon Marlow" <simonmar(a)microsoft.com> writes: > > To fix these > > problems you have to think carefully about strictness and > demand in your > > program. For memory we have heap profilers to help out, > but we don't > > have I/O descriptor profilers for lazy I/O! > > Surely I/O descriptors are just a type of heap-value, and as such > can be profiled in the normal way (producer, retainer, etc), just > like any other heap construction? File descriptors are held in the kernel, not the heap. Hmmm, I suppose you could track Handles, which notionally "hold on to" a file descriptor, but it's not completely reliable because a Handle will be held by a finalizer for an unspecified period of time before the descriptor is released. In practice it might not be a serious problem unless there are lots of other threads. Cheers, Simon

1 0