- Haskell-Cafe - Haskell.org

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 21 Feb '03

21 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 19 Feb '03

19 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 18 Feb '03

18 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 18 Feb '03

18 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

Haskell-Tutorial
by Gerhard Navratil 17 Feb '03

17 Feb '03

At the department we use Haskell for several courses and as a modelling tool in master- and PhD-thesis. A few years ago Damir Medak held a short internal workshop to answer most of the beginners questions and I created a tutorial text from his material. The tutorial could be useful for beginners because it contains lots of examples to explain the concepts. Included are function definition, lists, data types and polymorphism. Excluded are aspects of efficiency and user interaction (esp. monadic programming). The tutorial can be found here as a PDF-File: ftp://ftp.geoinfo.tuwien.ac.at/navratil/HaskellTutorial.pdf I hope you find the tutorial useful and I would be glad to get some feedback for further improvement. Gerhard Navratil ======================================== Gerhard Navratil Teaching- And Research-Assistant Technical University Vienna, Austria Institute for Geoinformation Gusshausstr. 27-29 1040 Vienna Tel.: ++43 (0) 1 / 58 801 - 12721 Fax.: ++43 (0) 1 / 58 801 - 12799 Cel.: ++43 (0) 699 / 197 44 761 http://www.geoinfo.tuwien.ac.at

2 1

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

17 Feb '03

> >File reading is not a pure operation: running out > >of file descriptors is a good counter-example. > > How does this differ from running out of memory whilst trying > to evaluate something? You're absolutely right, of course. I think the point is that by using implicit memory allocation we've accepted that "running out of memory" is going to be a failure condition that we cannot reasonably avoid or prepare for. This is a bad thing - but we deem the tradeoff to be worth it, because on the other hand we don't suffer from memory allocation bugs of the same kind that you get in C programs. I/O is similar in some ways: lazy I/O might lead to file descriptor leaks, which are similar to memory leaks but aren't something that Haskell programmers "expect" to have to worry about. 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! Also, by using lazy I/O one elects to ignore I/O errors - which I think is not something we should be encouraging. Cheers, Simon

2 1

Re: Global variables?
by Jon Cast 17 Feb '03

17 Feb '03

Richard Uhtenwoldt <ru(a)river.org> wrote: <snip> > I do not think it is nice: I do not like any of the solutions Hughes > considers in that paper because this problem can be handled much more > simply with lexical scope and the IO monad. can be /= should be > Just to get our bearings, let us first consider the solution that uses > unsafePerformIO, which neither Hughes nor I prefer: > >globalVar :: IORef Int > >globalVar = unsafePerformIO $ newIORef 0 > >foo = fff aaa bbb ccc > >bar = ggg xxx yyy zzz > >main = mmm >> nnn >> ooo > where the lines > >foo = fff aaa bbb ccc > >bar = ggg xxx yyy zzz > stand in for a typically much larger chunk of code --the bulk of the > program, let us call it. I, personally, haven't written a program whose bulk will fit in a single file in several years, and I doubt I ever will again. So, support for separate compilation is a necessity. How do you intend to handle this? <snip> Jon Cast

3 2