February 2001 - Haskell

Re: [newbie] Lazy >>= ?!
by andrew＠andrewcooke.free-online.co.uk 17 Feb '01

17 Feb '01

Thanks, that was very helpful, but it does raise two further questions (neither of which is critical, to my program, but if anyone cares to comment I'm interested). 1. After digesting what you wrote I managed to make a lazy list of IO monads containing random numbers, but couldn't make an IO monad that contained a lazy list of random numbers. Is this intentional, me being stupid, or just chance? My code for producing [IO ..] is: listParams :: [IO (Point, Double)] listParams = entry : listParams entry :: IO (Point, Double) entry = do x <- randomIO y <- randomIO t <- randomIO return ((x,y),t) Also, should I be worried about having more than one IO monad - it seems odd encapsulating the "outside world" more than once. 2. Why does the following break finite lists? Wouldn't they just become lazy lists that evaluate to finite lists once map or length or whatever is applied? > Now, if this were changed to > ~(x:xs) >>= f = f x ++ (xs >>= f) > (a lazy pattern match) then your listList2 would work, but finite > lists would stop working. Thanks again, Andrew On Fri, Feb 16, 2001 at 05:51:08PM -0500, Scott Turner wrote: [...] > listList1 works because it has a different meaning from listList2 > and listList3. Note that the length of listList1 is explicitly 1, > but the length of the result list in listList2 and listList3 cannot > be determined. > > Thus, the following "works" because the length of listList5 is > expressed apart from evaluating listList5. > listList5 = do rest <- [head listList5] > return (1:rest) > > > >From another point of view, the (1:rest) _is_ a lazy construct. > However, rest <- listList2 demands to know, at a minimum, > what's the length of listList2. See the definition of the list type > as a monad in Prelude.hs, > (x:xs) >>= f = f x ++ (xs >>= f) > [] >>= f = [] > > Now, if this were changed to > ~(x:xs) >>= f = f x ++ (xs >>= f) > (a lazy pattern match) then your listList2 would work, but finite > lists would stop working. > -- Scott > > >Thanks, Andrew (code follows) > > > >listList1 :: [[Integer]] > >listList1 = [x] where x = 1:x > > > >listList2 :: [[Integer]] > >listList2 = do rest <- listList2 > > return (1:rest) > > > >listList3 :: [[Integer]] > >listList3 = listList3 >>= (\x -> return (1:x)) -- http://www.andrewcooke.free-online.co.uk/index.html

1 0

[newbie] Lazy >>= ?!
by andrew＠andrewcooke.free-online.co.uk 16 Feb '01

16 Feb '01

There seems to be something funny going on here - I thought all the following were equivalent, but only listList1 works with > liftM (take 2) listListn Is there any way to write listList2 or 3 so that they are lazy (what I'm really trying to do is get the same kind of code to work on an IO Monad that contains an infinite list, but when that failed I wondered why it worked for a list monad containing an infinite list and then managed to get that not to work either...) Thanks, Andrew (code follows) listList1 :: [[Integer]] listList1 = [x] where x = 1:x listList2 :: [[Integer]] listList2 = do rest <- listList2 return (1:rest) listList3 :: [[Integer]] listList3 = listList3 >>= (\x -> return (1:x)) -- http://www.andrewcooke.free-online.co.uk/index.html

1 0

ANNOUNCE: nhc98 version 1.02
by malcolm-nhc＠cs.york.ac.uk 16 Feb '01

16 Feb '01

We are pleased to announce the new release 1.02 of nhc98, a compiler for Haskell'98, written in Haskell'98. http://www.cs.york.ac.uk/fp/nhc98/ It is available as a source package (which can be built via ghc, hbc, an existing nhc98 installation, or simply with a C compiler if you don't already have a Haskell compiler installed). Binary packages are also currently available for ix86-Linux and sparc-solaris2. Binary packages for other architectures can be added to the list if users contribute them. What's new ---------- This is an interim release, mainly fixing bugs in nhc98-1.00. The tracing and debugging tool, Hat, is about to undergo some significant changes, so release 1.02 is a stable snapshot before we start to break too many things! Amongst the many bugfixes, notable ones are as follows: * Fixed a space-leak in the compiler. Compilation now requires approximately half the previous maximum heap, and as a result, compile times are 5-10% faster. * The raw speed of input and output for compiled programs is now much faster, although you will probably only notice a difference if your program is severely I/O-bound. * Local infix declarations now work correctly. * `newtype T a = T a' now works correctly. * @-pattern-bindings are fixed. This means that Happy-generated parsers now compile correctly. * We now accept {-# pragmas #-} in any source position, and understand LINE pragmas. Recent bugfixes and new features in Hat include: * When a traced program is interrupted or terminates with an error, you get a virtual stack trace of the computation "for free", without having to start up a browser. * Foreign imports (via the new common primitive FFI) with an I/O result type are now also traced (previously only pure foreign functions were traced). * Interface and object files for tracing now have distinct file suffixes: .T.hi and .T.o. This improves matters enormously when switching between normal and tracing versions of a program. It also fixes some dependency bugs when building the tracing version of the compiler. Both the compiler and hmake have knowledge of the new suffixes. * Tracing versions of the following libraries have been added: IO, Array, FFI, IOExtras. (Still missing: Directory, System, Time, Locale, CPUTime, Random.) Regards, Malcolm

2 1

RE: Haskell threads & pipes & UNIX processes
by Julian Seward (Intl Vendor) 16 Feb '01

16 Feb '01

| So what's going on? How can the goal be achieved? I don't know, but here's a different suggestion, using bzip2 (you could do the same with zlib for .gz files): use the foreign import mechanism to make BZ2_bzopen, BZ2_bzwrite and BZ2_bzclose available in your program. Then: do bz2 <- bzopen "output.bz2" "w" let chars_to_write = ... :: String bzwrite bz2 (packString chars_to_write) (length chars_to_write) -- the above as many times as you like bzclose bz2 and link your program with libbz2.a or libbz2.so. Almost the same trick works with the zlib library for directly reading/writing .gz files. This strikes me as far more convenient than messing round with pipes, etc. J

3 3

Postdoctoral Position
by Elke Tetzner 16 Feb '01

16 Feb '01

Please pass on to interested Post doctorants. Apologies for multiple copies. ---------------------------------------------------------------------------- New Postdoctoral Position (DEADLINE 1 April 2001) Department of Computer Science, University of Rostock Germany Vacancy for an assistant professor Responsibilities: education and research in programming languages and compiler construction research in implementation techniques in different areas of computer science cooperation in academic self-administration Qualifications: PhD in computer science interests in programming languages and compiler constructions priorities: declarative programming, attribute grammars and applications, semantics of programming languages and compiler construction further interests: aspect-oriented programming, specification technics, real-time programming and other educational skills a good knowledge of german language engagement: 1st April 2001 (permanent) salary: BAT-O Ib (special in Germany), full time further information: Prof. Dr. G. Riedewald (http://www.informatik.uni-rostock.de/FB/Praktik/psuet/griedew.html) Dr. W. Mahrhold phone: (+49 381)498-3397 Qualified women are emphatically invited for application. Severely handicapped person with same qualification is prefered.

1 0

Haskell Graphics Lib problem
by Don Wakefield 16 Feb '01

16 Feb '01

I just bought 'The Haskell School of Expression', so I downloaded the latest version of Hugs98, February 2001, and the latest version of the Hugs Graphics Library, 2.0.3. Since the documentation mentioned building on Linux, I built and installed hugs98, ran some tests and felt it was okay. This is on a Redhat Linux 6.0 installation. Then I built the Hugs Graphics Library, and tried to run the first test suggested: ======================================================================= <1122:~/tmp/haskell> runhugs -Pgraphics-2.0.3/lib/x11: graphics-2.0.3/demos/HelloWorld.hs runhugs: Error occurred Reading file "graphics-2.0.3/demos/HelloWorld.hs": Reading file "graphics-2.0.3/lib/x11/GraphicsUtils.hs": Reading file "graphics-2.0.3/lib/x11/GraphicsCore.hs": Reading file "graphics-2.0.3/lib/x11/GraphicsEvent.hs": Reading file "graphics-2.0.3/lib/x11/GraphicsWindow.hs": Reading file "graphics-2.0.3/lib/x11/Xlib.hs": Reading file "graphics-2.0.3/lib/x11/StdDIS.hs": Reading file "/user/donw/tmp/haskell/Hugs.ixl/share/hugs/lib/exts/Int.hs": Reading file "/user/donw/tmp/haskell/Hugs.ixl/share/hugs/lib/exts/Bits.hs": Reading file "/user/donw/tmp/haskell/Hugs.ixl/share/hugs/lib/exts/Int.hs": Reading file "/user/donw/tmp/haskell/Hugs.ixl/share/hugs/lib/exts/Word.hs": Reading file "/user/donw/tmp/haskell/Hugs.ixl/share/hugs/lib/exts/Addr.hs": Reading file "/user/donw/tmp/haskell/Hugs.ixl/share/hugs/lib/Monad.hs": Reading file "/user/donw/tmp/haskell/Hugs.ixl/share/hugs/lib/exts/Foreign.hs": Reading file "graphics-2.0.3/lib/x11/StdDIS.hs": Reading file "graphics-2.0.3/lib/x11/X.hs": Reading file "graphics-2.0.3/lib/x11/Xlib.hs": Reading file "/user/donw/tmp/haskell/Hugs.ixl/share/hugs/lib/exts/Concurrent.lhs": Reading file "/user/donw/tmp/haskell/Hugs.ixl/share/hugs/lib/exts/ChannelVar.lhs": Reading file "/user/donw/tmp/haskell/Hugs.ixl/share/hugs/lib/exts/ConcBase.hs": Reading file "/user/donw/tmp/haskell/Hugs.ixl/share/hugs/lib/exts/ChannelVar.lhs": Reading file "/user/donw/tmp/haskell/Hugs.ixl/share/hugs/lib/exts/Channel.lhs": Reading file "/user/donw/tmp/haskell/Hugs.ixl/share/hugs/lib/exts/Semaphore.lhs": Reading file "/user/donw/tmp/haskell/Hugs.ixl/share/hugs/lib/exts/SampleVar.lhs": Reading file "/user/donw/tmp/haskell/Hugs.ixl/share/hugs/lib/exts/Concurrent.lhs": Reading file "/user/donw/tmp/haskell/Hugs.ixl/share/hugs/lib/System.hs": Reading file "graphics-2.0.3/lib/x11/Graphics_Utilities.hs": Dependency analysis ERROR graphics-2.0.3/lib/x11/Graphics_Utilities.hs:73 - Illegal type "IOResult a" in constructor application <1123:~/tmp/haskell> pushd graphics-2.0.3 ~/tmp/haskell/graphics-2.0.3 ~/tmp/haskell <1125:~/tmp/haskell/graphics-2.0.3> find . -name '*hs' -print | xargs grep IOResult ./lib/x11/Graphics_Utilities.hs: mkErr :: Maybe (IOResult a) -> IOError ./lib/win32/GraphicsUtilities.hs: mkErr :: Maybe (IOResult a) -> IOError ======================================================================= I couldn't find a discussion of IOResult in the html versions of the Haskell 98 report or library report, but it is in the prelude: ======================================================================= ./lib/Prelude.hs:data IOResult ======================================================================= I'm still learning all the ins and outs of Haskell, so I don't really know what the problem is. Any helpful hints? -- Don Wakefield Mentor Graphics Corporation (503) 685-1262 8005 S.W. Boeckman Road don_wakefield(a)mentorg.com Wilsonville, OR 97070-7777

2 1

Stack depth
by Sengan 16 Feb '01

16 Feb '01

I have a program which works fine, except that for certain (large) input files I have to give it a larger than normal Stack (eg 4M in ghc). GHC allows one to profile heap, but I'd like to know how to profile stack contents. Is there a means with ghc/hugs/or something else? Does anyone have any suggestions on how to find out where stack's being used? Thanks Sengan

1 0

AVIS'01: LAST Call for Abstracts
by Ramesh Bharadwaj 15 Feb '01

15 Feb '01

First International Workshop on Automated Verification of Infinite-State Systems (AVIS'01) http://www.informatik.hu-berlin.de/top/fme2001/html/workshops.html Co-located with FME 2001 in Berlin, Germany 12th March 2001 This workshop is a forum for researchers, students, and practitioners interested in the application of formal methods and tools for the auomatic verification of large practical systems. Formal methods, in particular model checking, is increasingly being used in industry to automatically establish the correctness of (and to find flaws in) finite-state systems, such as descriptions of hardware and protocols. However, model checking is limited in scope due to the state explosion problem. Most practical system descriptions, notably that of software, are therefore not directly amenable to finite-state verification methods since they have very large or infinite state spaces. For such systems, theorem proving -- a process that requires manual effort and mathematical sophistication to use -- has so far been the only viable alternative. More recently, we have seen the emergence of hybrid techniques that combine the ease-of-use of model checkers with the power of theorem provers. Tools based on these techniques afford users with full automation, and are less sensitive to the size of the state space (which may be infinite or arbitrarily large). There is a growing body of knowledge in this field which has a very exciting future. The intention of this workshop is to build a forum for exchanging ideas and experiences by bringing together theoreticians, tool builders, as well as practitioners who are interested in this emerging area of research in formal verification. The Workshop The workshop will be co-located with FORMAL METHODS EUROPE 2001 "Formal Methods for Increasing Software Productivity" 12-16 March 2001, Humboldt-Uinversitaet zu Berlin, Germany. The workshop will be held on 12th March. Submission You are invited to submit a 2-4 page abstract on related research or case study. We invite both completed work as well as work in progress; the aim of the workshop is to stimulate discussion and bring together people with varying backgrounds from disparate communities. Submission should be made electronically to ramesh(a)itd.nrl.navy.mil We accept plain text, pdf, or postscript submissions. Authors of accepted abstracts will be expected to give a 20 minute presentation at the workshop. Important Dates 16th February 2001 Submission of abstracts 2nd March 2001 Notification of acceptance 12th March 2001 Workshop 15th June 2001 Camera-ready copies due Workshop Organizers Dr. Ramesh Bharadwaj Center for High Assurance Computing Systems Naval Research Laboratory Washington DC 20375 ramesh(a)itd.nrl.navy.mil +1-202-767-7210 Dr. Steve Sims Chief Technology Officer -- Reactive Systems, Inc. http://www.reactive-systems.com sims(a)reactive-systems.com +1-703-534-6458 Publication The accepted papers will be published as a Naval Research Laboratory Technical Memorandum. Authors of selected papers may be invited to submit full and revised papers for a special journal issue after presentation at the workshop.

1 0

Haskell threads & pipes & UNIX processes
by Michael Marte 15 Feb '01

15 Feb '01

Hello *, I need to compress the output of my Hakell program. To avoid the creation of huge files, I want to compress before writing by means of gzip or bzip2. However, this seems to be quite involved. I decided to run the compressor with runProcess :: FilePath -- Command -> [String] -- Arguments -> Maybe [(String, String)] -- Environment(Nothing -> Inherited) -> Maybe FilePath -- Working directory (Nothing -> inherited) -> Maybe Handle -- stdin (Nothing -> inherited) -> Maybe Handle -- stdout (Nothing -> inherited) -> Maybe Handle -- stderr (Nothing -> inherited) -> IO () First I wanted to use Posix.createPipe to connect to the compressor but Posix.createPipe returns a Fd. So this does not fit. I ended up with using Posix.createNamedPipe. This creates a named pipe that can be openend with IO.openFile (which again yields the Handle needed for runProcess). At this point, it turned out that the pipe has to be opened for reading before it can be opened for writing (ghc-4.08.1). This seems to be a bug. (In a shell, the order does not matter; the processes are suspended as expected.) Then, as expected, the problem occured that writing to the pipe and compressing cannot be sequenced. If the producer is started first, the producer blocks because there is no consumer. If the consumer is started first, the consumer blocks because there is no input. So I played around with threads. If both consumer and producer are executed as threads, the program terminates immediately without any output. There seems to be no need to start executing any of the threads. If either the producer or the compressor are executed in a thread, the compressor bails out complaining that some resource is not available. So what's going on? How can the goal be achieved? Thank you, Michael

1 0

The Do-Let-Braces problem
by Mark Utting 15 Feb '01

15 Feb '01

Summary: Haskell layout has problems within 'do' (see below). Can we change Haskell to improve it? We teach Haskell to all our second-year students, and we like to teach the OPTION of using explicit braces and ;'s. (If students write nested do constructs, even though we discourage this, they often have trouble with the layout rules.) We would like to be able to teach this: "To use explicit structuring, instead of layout, you can just put braces around all the statements in a 'do' block, plus semicolons at the end of each statement. (like in C++/Java!)." But this does not work. For example, the first definition below parses, but the second does not. fa::IO () fa = do putStr "Enter Data: " line <- getLine let line2 = line putStr line2 fb::IO () fb = do { putStr "Enter Data: "; line <- getLine; let line2 = line; putStr line2; } ERROR "f.hs" (line 13): Syntax error in definition (unexpected symbol "putStr") Fix 1: Put explicit braces around the body of the 'let': let {line2 = line}; This is ugly and a nuisance to teach. It would be much nicer to be able to teach 'let pattern = expr' as a simple statement, and avoid mentioning the possibility of multiple definitions within a single 'let'. (Which is rarely needed within 'do' syntax anyway, because you can usually use several separate let statements instead. Mutually recursive definitions is probably the only reason.) Fix 2: an alternative fix is to move the semicolon at the end of the let to the beginning of the next line, but this is ugly! f2 = do { putStr "Enter Data: "; line <- getLine; let line2 = line ;putStr line2 } Fix 3: I might be happy to put ALL the semicolons at the beginning of lines, which also works, but you are not allowed a semicolon at the beginning of the first brace, so this looks asymmetric. f3 = do { putStr "Enter Data: " ;line <- getLine ;let line2 = line ;putStr line2 } Question: Is it possible to change the layout handling of Haskell slightly so that f1 is legal? Perhaps the explicit semicolon at the end of the let line could terminate the (implicit) layout of the let statement? Mark. Dr Mark Utting, Senior Lecturer Department of Computer Science School of Computing and Mathematical Sciences The University of Waikato Tel: +64 7 838 4791 Private Bag 3105 Fax: +64 7 858 5095 Hamilton Email: marku(a)cs.waikato.ac.nz New Zealand Web: http://www.cs.waikato.ac.nz/~marku It is a time-proven principle of software engineering to try and strengthen the static description of systems as much as possible. [Clemens Szyperski]

5 4