- Haskell-Cafe - Haskell.org

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

Re: Haskell-Cafe digest, Vol 1 #616 - 12 msgs
by Chevalier Dr. Dr. Ruediger Marcus Flaig 14 Feb '03

14 Feb '03

Am Donnerstag, 13. Februar 2003 18:01 schrieb haskell-cafe-request(a)haskell.org: > Message: 5 > Date: Thu, 13 Feb 2003 10:06:53 +0100 > From: Jerzy Karczmarczuk <karczma(a)info.unicaen.fr> > Organization: =?ISO-8859-1?Q?Universit=E9_de_Caen=2C_France?= > Cc: haskell(a)haskell.org, haskell-cafe(a)haskell.org > Subject: Re: ANNOUNCE: Learning Haskell portal, version 0.1 > > Arjan van IJzendoorn wrote: > > Often we see messages from people who want to learn Haskell (something we > > applaud), but don't know where to begin. > > ... > > > Enough talk: http://www.cs.uu.nl/~afie/haskell/LearningHaskell.html > > Thanks, Arjan, nice work. > I would add some significant papers, such as John Hughes' > "Why functional programming matters", etc. > > and perhaps - for some, a little bit advanced readers - some > other papers, introducing type classes, perhaps monads (Wadler) > etc. Everything can be found through the Home of Haskell, but > gathering essential references on your page would shorten the > search path. > > I believe - from some discussions here and on comp.lang.functional > (some of them quite annoying...) that it would perhaps be a good > idea to put down a relatively comprehensive, easy comparison > between Haskell and other languages, notably functional: Clean, > also: Scheme, absolutely: ML variants, and Erlang. > Such questions are, and will continue to be recurring. > > > Jerzy Karczmarczuk > Excellent idea -- if you need a volunteer, contact me (I am familiar with Erlang, the Lisp/Scheme group and CAML). But I would also suggest to include the declarative languages such as Prolog and Mercury, if we can find anyone who knows -- the Mercury homepage (sorry, I don't have the URL right now, it was something long and winding) contains an explicit comparison between Mercury and Haskell. (A rather fair and objective one, it must be pointed out!) And maybe one should also add a few lines about hybrids such as Python? Yours, Ruediger M. Flaig -- "I was always told that death and taxes are no subjects for discussion." "Well... the one does not concern me." "And the other?" "I admit that I do not pay taxes either." -- Diane Duane: "The Wounded Sky"

2 1

RE: MArray and newSTUArray
by Simon Peyton-Jones 14 Feb '03

14 Feb '03

Excellent idea. This does indeed seem to be the cleanest way to explain the necessary type constraints. I think we (Simon M) may add it to the library. Simon | -----Original Message----- | From: Dean Herington [mailto:heringto@cs.unc.edu] | Sent: 13 February 2003 15:21 | To: haskell-cafe(a)haskell.org | Subject: MArray and newSTUArray | | The MArray class in Data.Array.MArray is a very nice abstraction. | However, when creating an array whose type partakes of MArray, say | STUArray, I find myself defining and using a type-specific creation | function, such as: | | newSTUArray :: (MArray (STUArray s) e (ST s), Ix i) | => (i, i) -> e -> ST s (STUArray s i e) | newSTUArray = newArray | | so that I don't have to give a complicated type declaration for each use | of `newArray` that creates an STUArray. | | 1. Is there a better (more concise/convenient) way to provide the | necessary type information? | 2. If not, should functions such as `newSTUArray` be provided in the | libraries? | | -- Dean | | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

RE: Pattern matching, implict par. question
by Simon Peyton-Jones 14 Feb '03

14 Feb '03

Well the definition clearly falls under the monomorphism restriction as laid down by the Report, because you haven't given a signature for us,n,j. I suggest ctPar :: (?ctPar::CTPar) => CTPar ctPar = ?ctPar (us,n,j) = ctPar That should work Simon | -----Original Message----- | From: Jorge Adriano [mailto:jadrian@mat.uc.pt] | Sent: 13 February 2003 14:36 | To: Haskell Cafe; glasgow-haskell-users(a)haskell.org | Subject: Pattern matching, implict par. question | | Hello, When trying | | type CTPar = ([Double],Int,Int) | ctPar ::(?ctPar::CTPar)=>CTPar | ctPar@(us,n,j) = ?ctPar | | I got this error message in ghci is: | " Illegal overloaded type signature(s) | in a binding group for ctPar, us, n, j | that falls under the monomorphism restriction | When generalising the type(s) for ctPar, us, n, j | Failed, modules loaded: CrossTypeOps." | | Should the monomorphis restriction really apply here? | The values of us,j,n do depend on the context, but not their types (right?). | | J.A. | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0