- Haskell-Cafe - Haskell.org

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

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

16 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

big rationals question
by Damien R. Sullivan 16 Feb '03

16 Feb '03

So, for my Algorithms class in grad school we have to calculate some number to as many digits as possible in a minute. I figured this would be a good project to try in multiple languages, to see how they compared in ease and speed. In particular I've been intrigued by the functionality and strong typing of Haskell and O'caml for a while, but never had an incentive to really learn them without a project. So I tackled ocaml first, looking at their tutorial, and without too much trouble got a logarithm program working, confirming in the process that (a) the syntax sucks (I like operator overloading for math) and (b) it seems pretty fast, although I need to try Java or Perl or some C++ library for comparison. Not as fast as 'bc', but it might be using better algorithms. In particular I was able to print both the exact form of the big rational and a decimal form to as many digits as I wanted easily. Then I moved to Haskell, largely rewriting the ML code. The result is much nicer looking, being able to say 'sum + powx' instead of 'Num.add_num sum powx', or having to define 'num_2' for a bignum version of 2. It took longer to actually run properly -- I got bit by laziness, but John Meacham tipped me off. And now I have '34283788463231218 % 20536892788086675' being printed out, although I seem to have a bug since if that's a numerator and denominator the result is not the natural logarithm of 2. But my real question is can I get Haskell to actually do that division itself? I get complaints about 'Fractional Integer'; I had to use bc to do the division. -xx- Damien X-)

2 1

Re: big rationals question
by Jon Cast 16 Feb '03

16 Feb '03

"Damien R. Sullivan" <dasulliv(a)cs.indiana.edu> wrote: <snip> > Then I moved to Haskell, largely rewriting the ML code. The result is > much nicer looking, being able to say 'sum + powx' instead of > 'Num.add_num sum powx', or having to define 'num_2' for a bignum > version of 2. It took longer to actually run properly -- I got bit by > laziness, but John Meacham tipped me off. And now I have > '34283788463231218 % 20536892788086675' being printed out, although I > seem to have a bug since if that's a numerator and denominator the > result is not the natural logarithm of 2. But my real question is can > I get Haskell to actually do that division itself? I get complaints > about 'Fractional Integer'; I had to use bc to do the division. Sure: > rationalToDouble :: Rational -> Double > rationalToDouble rat = fromInteger (numerator rat) > / fromInteger (denominator rat) HTH > -xx- Damien X-) Jon Cast

1 0