- Haskell - Haskell.org

How do students learn Haskell? Postgraduate project at University of Kent
by S.J.Thompson 18 Mar '09

18 Mar '09

Funding is available for this postgraduate project, supervised by Simon Thompson and Sally Fincher, in collaboration with Jurriaan Hage, Utrecht University. To apply visit http://www.cs.kent.ac.uk/research/pg/ How do students learn Haskell? As users and teachers of Haskell, we have some sense of how people, both experienced programmers and novices, learn to program in Haskell. This sense is based on experience - as learners ourselves, perhaps, or through teaching. We propose an alternative approach, based on the wealth of data collected through the instrumented version of the Helium system for Haskell [1]. This collects information of the programs compiled, the errors they generate, and how learners use the system in fixing those errors, and so we can see precisely the way that learners use these tools while they are learning. This is a joint project of the Functional Programming and Computing Education groups at the University of Kent, and the Helium group at Utrecht. The CompEd group has experience of working on this sort of project [2], and the FP group has wide experience of teaching functional languages, particularly Haskell [3]. [1] Helium http://www.cs.uu.nl/wiki/Helium [2] ICER 2006 http://www.jadud.com/people/mcj/files/2006-icer-jadud.pdf [3] Craft http://www.cs.kent.ac.uk/people/staff/sjt/craft2e/

1 0

Re: indirectly recursive dictionaries
by oleg＠okmij.org 18 Mar '09

18 Mar '09

Tom Schrijvers wrote: > The cyclic dictionaries approach is a bit fragile. The problem appears to > be here that GHC alternates exhaustive phases of constraint reduction and > functional dependency improvement. The problem is that in your example you > need both for detecting a cycle. It seems we can convince GHC to do constraint reduction and improvement in the order we desire. The key is to use the continuation-passing style -- which forces things to happen in the right order, both at the run-time and at the compile time. I took the liberty to flesh out the example a bit more, to verify that recursive dictionaries are indeed constructed and used. The trace statement shows it. {-# OPTIONS -fglasgow-exts #-} {-# OPTIONS -fallow-overlapping-instances #-} {-# OPTIONS -fallow-undecidable-instances #-} import Debug.Trace class C1 x where m1 :: x -> Int instance (C1 x, C1 y) => C1 (x,y) where m1 (x,y) = m1 x + m1 y instance C1 Bool where m1 = fromEnum -- Was: instance (C2 x y, C1 (y,Bool)) => C1 x instance C2CPS x (C1K Bool) => C1 x where m1 x = trace "recursive C1" $ c2invoke (C1K True) x newtype C1K a = C1K a -- The class C2CPS below is a CPS version of the class C2 below -- class C2 x y | x -> y where c2 :: x -> y -- instance C2 Int Int where c2 = id -- The functional dependency becomes implicit class C2CPS x k where c2invoke :: k -> x -> Int instance Apply k Int Int => C2CPS Int k where c2invoke k x = apply k x class Apply f x y | f x -> y where apply:: f -> x -> y instance C1 (b,a) => Apply (C1K a) b Int where apply (C1K a) x = m1 (x,a) -- It is this declaration that was causing nontermination of typechecking. -- Not any more bar :: Int bar = m1 (1::Int)

1 0

Re: scoped type variables
by Norman Ramsey 18 Mar '09

18 Mar '09

[Opening discussion to broader audience: I asked Simon PJ about scoped type variables and type abbreviations] > | With scoped type variables, it would be useful to be able to define > | a type abbreviation in a where clause, so that the scoped > | type variable could be used on a right-hand side. Apparently > | this wasn't done. Was there any technical reason why not? > > Would you care to give an example? Do you mean > f x = e where a = Int No. I give an example below, but I've just spent 10 minutes grubbing through the Haskell 98 Report so I can phrase the question more precisely: Given the extension to scoped type variables, I believe that the 'type' abbreviation declaration should have been 'promoted' from syntactic category 'topdecl' to syntactic category 'decl', because it is convenient and useful to be able to exploit a scoped type variable in a type abbreviation. Was this possibility simply overlooked, or was a deliberate choice made not to do it? Here is a synopsis of code I would like to write: solve :: forall m l a . Graph m l -> Fuel -> DFM a (a, Fuel) solve = solveGraph where -- in the defintions below, type variable 'a' is free -- on the RHS but is bound by the forall above type FactKont b = Graph m l -> a -> Fuel -> DFM a b type FuelKont b = Graph m l -> Fuel -> DFM a b solveMid :: m -> FactKont b -> FactKont b solveLast :: l -> FuelKont b -> FactKont b ... For my sanity I'd like to define type abbreviations that refer to 'm' and 'l' also... Under the current regime, I'm forced to do what amounts to lambda lifting on the type abbreviations. Not only does this lead to a extra type parameters which distract from the main event, but in floating the type abbreviation out to top level, I am forced to choose a unique name for it, which I might prefer not to do if the same module contains several similar functions with similar (but not identical) type abbreviations. Of course the naming issue arises even in Haskell 98, but the ability to bring type variables into scope in a 'where' clause adds urgency. > There are lots of design issues. For example, in GHC today, a scoped type > variable stands for a type *variable* not for a *type*. I took the other > approach initially, but I think this is better I know this distinction is important in instance declarations. Presumably it also means that the scoped type variable can unify with something else during type inference? I fear that without seeing some formalism I can't be too sure what's going on---is there a technical report somewhere that explains the distinction? In any case, I hope this question is orthogonal to the problem of permitting a type declaration as a 'decl' in a where clause and not a mere lonely 'topdecl'. Is anybody else keen to have this ability? Norman

2 1

indirectly recursive dictionaries
by Ralf Laemmel 17 Mar '09

17 Mar '09

{- Recursive instance heads as in ... instance C0 (x,Bool) => C0 x ... are Ok if we allow for typechecking scheme as described in "SYB with class". The main idea is to assume C0 x in proving the preconditions of the body of the clause. This is also works for mutual recursion among type classes and instances to the extent exercised in ditto paper. What about the below example though? Here recursion detours through an extra class in a way that leads to nonterminating typechecking with GHC 6.10.1. Does anyone agree that a constraint resolution scheme like the one mentioned could be reasonably expected to cover this case? Regards, Ralf -} {-# OPTIONS -fglasgow-exts #-} {-# OPTIONS -fallow-overlapping-instances #-} {-# OPTIONS -fallow-undecidable-instances #-} -- Direct recursion terminates (typechecking-wise) class C0 x where m0 :: x -> () m0 = const undefined instance (C0 x, C0 y) => C0 (x,y) instance C0 Bool instance C0 (x,Bool) => C0 x foo :: () foo = m0 (1::Int) -- Indirect recursion does not terminate (typechecking-wise) class C1 x where m1 :: x -> () m1 = const undefined instance (C1 x, C1 y) => C1 (x,y) instance C1 Bool instance (C2 x y, C1 (y,Bool)) => C1 x class C2 x y | x -> y instance C2 Int Int -- It is this declaration that causes nontermination of typechecking. bar :: () bar = m1 (1::Int)

2 2

ANNOUNCE: libffi 0.1 released
by Remi Turk 17 Mar '09

17 Mar '09

I am happy to announce libffi 0.1, binding to the C library libffi, allowing C functions to be called whose types are not known before run-time. Why? Sometimes you can't use the haskell foreign function interface because you parse the type of the function from somewhere else, i.e. you're writing an interpreter for a language that has an FFI itself. What? The main function it exports is: callFFI :: FunPtr a -> RetType b -> [Arg] -> IO b And because code is worth a thousand words, here a small program that uses C to write a 1Gb buffer of random garbage to a file: > import System.Posix.DynamicLinker > import Foreign.LibFFI > > main = do > malloc <- dlsym Default "malloc" > creat <- dlsym Default "creat" > write <- dlsym Default "write" > let sz = 2 ^ 30 > buf <- callFFI malloc (retPtr retVoid) [argCSize sz] > fd <- callFFI creat retCInt [argString "/tmp/test", argCUInt 0o644] > n <- callFFI write retCSize [argCInt fd, argPtr buf, argCSize sz] > putStrLn $ show n ++ " bytes written" It should work on any 32/64bits machine on which libffi works, but has been primarily tested on linux x86_64. The current libffi is not exception-safe (exception = memory leak) and callFFI has quite some overhead that would be unnecessary with another api. It is, however, very easy to use :) More interesting examples are included in examples/ in the package. Where? Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/libffi Module docs: http://www.science.uva.nl/~rturk/doc/libffi-0.1 Cheers, Remi

1 0

Re: indirectly recursive dictionaries
by oleg＠okmij.org 17 Mar '09

17 Mar '09

Ralf wrote: > class C1 x > where > m1 :: x -> () > m1 = const undefined > instance (C1 x, C1 y) => C1 (x,y) > instance C1 Bool > instance (C2 x y, C1 (y,Bool)) => C1 x > class C2 x y | x -> y > instance C2 Int Int > bar :: () > bar = m1 (1::Int) I believe it works very well (meaning bar typechecks and even runs) if we either add an instance instance C1 Int or change the instance of C2 to instance C2 Int Bool Otherwise, the problem really has no solution, and looping is an indication. I used GHC 6.8.3....

1 0

ANN: The Monad.Reader (13)
by Wouter Swierstra 16 Mar '09

16 Mar '09

I am pleased to announce that a new issue of The Monad.Reader is now available: http://www.haskell.org/haskellwiki/The_Monad.Reader The Monad.Reader is a quarterly magazine about functional programming. Issue 13 consists of the following four articles: * Stephen Hicks Rapid Prototyping in TEX * Brent Yorgey The Typeclassopedia * Chris Eidhof, Eelco Lempsink Book Review: "Real World Haskell" * Derek Elkins Calculating Monads with Category Theory Special thanks to Ashley Yakeley for his help with publishing The Monad.Reader on the Haskell wiki. If you'd like to write something for the next issue of The Monad.Reader, please get in touch. I haven't fixed the deadline for the next issue, but it should be mid-May or thereabouts. Wouter

1 0

ANNOUNCE: dzen-utils 0.1
by Felipe Lessa 15 Mar '09

15 Mar '09

Hello! I'm please to announce dzen-utils 0.1. I don't feel like it is ready to be released, but let's see how everything goes. :) == WHAT == dzen-utils contains various utilities for creating dzen input strings in a type-safe way using some combinators, including the ability to apply colors locally (instead of applying for everything beyond some point). It can also emulate dbar and gdbar, do automatic padding, and more. == WHY == I don't like to write bash scripts for dzen, and I don't like the way xmobar treats its configuration and its inability to show anything other than text. This package is a short-term solution for my problems. Maybe I'll write xmozen in the future. ;) == WHERE, HOW, etc. == It is in Hackage already, go get it[1]. Please see the documentation of System.Dzen for some small examples. [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/dzen-utils Thanks for your time, -- Felipe.

1 0

Haskell Weekly News: Issue 109 - March 14, 2009
by Brent Yorgey 14 Mar '09

14 Mar '09

--------------------------------------------------------------------------- Haskell Weekly News http://sequence.complete.org/hwn/20090314 Issue 109 - March 14, 2009 --------------------------------------------------------------------------- Welcome to issue 109 of HWN, a newsletter covering developments in the [1]Haskell community. Congratulations to the authors of RWH on their [2]Jolt award! Some cool libraries released this week (as usual), and some really cool PhD [3]opportunities at Strathclyde. Also, it seems that I was censured last week for not including any quotes in the HWN, which is because tunes.org (which hosts the #haskell logs) was down while I was putting it together. So, this time I've included quotes going back two weeks, I HOPE YOU'RE HAPPY Community News Tom DuBuisson (TomMD) has [4]moved to Portland and will be starting a PhD at Portland State soon. Announcements darcs fundraising drive - only $720 left to go!. Eric Kow [5]announced that [6]donations are still being accepted to help pay for travel to the upcoming Haskell hackathon. So far we have raised $280, so we're almost a third of the way there. Think you can help? Vintage BASIC 1.0. Lyle Kopnicky [7]announced the initial release of [8]Vintage BASIC, an interpreter for microcomputer-era BASIC. Fully unit-tested, it faithfully implements the common elements of the language. On the web site, you can find 102 games from the classic book BASIC Computer Games, all of which run flawlessly. Have fun! ThreadScope: Request for features for the performance tuning of parallel and concurrent Haskell programs. Satnam Singh [9]requested feedback on infrastructure for logging run-time events and a graphical viewer program called [10]ThreadScope. The goal is for these features to make it into the next release of GHC. torch-0.1. Yusaku Hashimoto [11]announced a new unit test framework, [12]torch-0.1. sparsebit 0.5 - Sparse Bitmaps for Pattern Match Coverage. Ki Yung Ahn [13]announced the release of the [14]sparsebit library. This library packages the functional peal paper [15]Sparse Bitmaps for Pattern Match Coverage submitted to ICFP 2009 by Ki Yung Ahn and Tim Sheard. happs-tutorial 0.8. Crieghton Hogg [16]announced the release of [17]happs-tutorial 0.8, which is compatible with [18]happstack-0.2. A number of changes have occurred in this release, including general code cleanup, migration to the new Happstack.Server.SimpleHTTP API, and more. Future 1.1.0 concurrency library. ChrisK [19]announced the [20]future package, which ought to do what C++ standard futures/promises do, plus a bit more. The main operation is forkPromise :: IO a -> IO (Promise a), which sets the "IO a" operation running in a fresh thread; the eventual result can be accessed in many ways (non-blocking, blocking, blocking with timeout). Holumbus-MapReduce 0.0.1. Stefan Schmidt [21]announced three new libraries: [22]Holumbus-MapReduce, [23]Holumbus-Distribution, and [24]Holumbus-Storage, which provide tools for building distributed systems. These libraries are used as the backbone of the [25]Holumbus search engine. Turbinado V0.6. Alson Kemp [26]announced the release of [27]Turbinado 0.6, a Rails-ish Model-View-Controller web serving framework for Haskell. New features include support for CGI serving, statically compiled Layouts, Views, and Controllers, lower case paths, support for cookies and encrypted cookie sessions, easier installation, and support for GHC 6.10. iteratee-0.1.0. John Lato [28]announced the hackage release of [29]iteratee-0.1.0. This library implements enumerators and iteratees [30]as proposed by Oleg Kiselyov. Harpy 0.4.4 - Runtime code generation for x86 machine code. Dirk Kleeblatt [31]announced the release of [32]Harpy 0.4.1, a library for runtime code generation for x86 machine code. The new release features additional Eq instances, support for new prefetching instructions, and some bug fixes. Discussion Suggestion for a Haskell mascot. Maur�cio [33]suggested using a sloth as the Haskell mascot. If you would like to know how to say 'sloth' in just about every language ever, read this thread. Jobs Microsoft PhD Scholarship at Strathclyde. Conor McBride [34]announced another PhD opportunity at Strathclyde, sponsored by Microsoft Research, to investigate the practical and theoretical impact of extending Haskell's type system with numeric expressions (representing sizes, or ranges, or costs, for example) and constraints capturing richer safety properties than are currently managed by static typing. Blog noise [35]Haskell news from the [36]blogosphere. * Braden Shepherdson: [37]Pimp Your XMonad #4: Urgency Hooks. * Thomas M. DuBuisson: [38]Explicit Parallelism via Thread Pools. * Ketil Malde: [39]Current developments. Ongoing development of the biohaskell libraries for bioinformatics. * Philip Wadler: [40]Cafe Scientifique. Philip will be giving a talk, "Proofs are Programs: 19th Century Logic and 21st Century Computing", on Monday in Edinburgh. * Yi: [41]Yi 0.6.0 Release Notes. * Alson Kemp: [42]ANNOUNCE: Turbinado V0.6. * GHC / OpenSPARC Project: [43]Thread activity plotting. * Real-World Haskell: [44]We won a Jolt Award!. * Real-World Haskell: [45]Real World Haskell on the Kindle 2. * Christophe Poucet (vincenz): [46]Bootstrapping cabal. * Gtk2HS: [47]Mickinator File Manager. * Osfameron: [48](rough) Grids in Haskell. Some notes on representing 2D grids in Haskell. * Manuel M T Chakravarty: [49]These graphs summarise the performance of Data Parallel Haskell.... * GHC / OpenSPARC Project: [50]Project midpoint. * GHC / OpenSPARC Project: [51]The GNU Debugger and me. * Don Stewart (dons): [52]Evolving faster Haskell programs. Using genetic algorithms to find optimal flag combinations. * Xmonad: [53]Xmonad and the Gimp. * Xmonad: [54]xmonad on eee. * Mark Wassell: [55]Conversations with a type checker. * Holumbus: [56]Holumbus-MapReduce on Hackage. Some neat libraries for building distributed systems! * Darcs: [57]darcs weekly news #20. * Nick Mudge: [58]First Bay Area Haskell Meeting. * Dan Piponi (sigfpe): [59]Dinatural Transformations and Coends. Quotes of the Week * mmorrow: when i first saw haskell i was like "holy shitfork! that's what i've been trying to do in C for forever!" * pastah: the maybe monad is like cheating. everything is so awesomelly easy. * wli: Monads are like constipation. Comonads are like Ex-Lax. * TomMD: Never trust IO. * Axman6: let blah f x = f (blah f x) in blah ("blah "++) "" * MyCatVerbs: Lazy IO is implemented in terms of unsafePerformIO, you, you, you silly bipedal carbon-based organism. * MyCatVerbs: Amdahl's law is mostly to be used for making people feel depressed. * Axman6: -ddump-occur-anal <- another terrible name... * AchimSchneider: Finite automata don't go bottom in any case, at least not if you don't happen to shoot them and their health drops below zero. * ski: the truth (semantics), the whole truth (completeness), and nothing but the truth (soundness) * f4hy: wait you can do a show on an infinite list?! (I am starting to think haskell is not a programming language, it is evil wizardry) * Baughn: concat $ forM [(1,2), (4,5)] $ \(a,b) -> show (b,a+b) About the Haskell Weekly News New editions are posted to [60]the Haskell mailing list as well as to [61]the Haskell Sequence and [62]Planet Haskell. [63]RSS is also available, and headlines appear on [64]haskell.org. To help create new editions of this newsletter, please see the information on [65]how to contribute. Send stories to byorgey at cis dot upenn dot edu. The darcs repository is available at darcs get [66]http://code.haskell.org/~byorgey/code/hwn/ . References 1. http://haskell.org/ 2. http://www.realworldhaskell.org/blog/2009/03/12/we-won-a-jolt-award/ 3. http://article.gmane.org/gmane.comp.lang.haskell.general/16944 4. http://tommd.wordpress.com/2009/03/13/explicit-parallelism-via-thread-pools/ 5. http://article.gmane.org/gmane.comp.lang.haskell.cafe/54758 6. http://www.darcs.net/donations.html 7. http://article.gmane.org/gmane.comp.lang.haskell.cafe/54652 8. http://www.vintage-basic.net/ 9. http://article.gmane.org/gmane.comp.lang.haskell.cafe/54521 10. http://raintown.org/threadscope 11. http://article.gmane.org/gmane.comp.lang.haskell.cafe/54445 12. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/torch 13. http://article.gmane.org/gmane.comp.lang.haskell.cafe/54436 14. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/sparsebit 15. http://kyagrd.dyndns.org/wiki/SparseBitmapsForPatternMatchCoverage 16. http://www.haskell.org//pipermail/haskell-cafe/2009-March/057305.html 17. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/happs%2Dtutorial 18. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/happstack 19. http://article.gmane.org/gmane.comp.lang.haskell.cafe/54409 20. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/future 21. http://article.gmane.org/gmane.comp.lang.haskell.cafe/54325 22. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Holumbus%2DMapRe… 23. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Holumbus-Distrib… 24. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Holumbus-Storage 25. http://www.holumbus.org/redmine/wiki/holumbus 26. http://article.gmane.org/gmane.comp.lang.haskell.general/16953 27. http://www.turbinado.org/ 28. http://article.gmane.org/gmane.comp.lang.haskell.general/16945 29. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/iteratee 30. http://okmij.org/ftp/Haskell/Iteratee/ 31. http://article.gmane.org/gmane.comp.lang.haskell.general/16942 32. http://uebb.cs.tu-berlin.de/harpy/ 33. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/54418 34. http://article.gmane.org/gmane.comp.lang.haskell.general/16944 35. http://planet.haskell.org/ 36. http://haskell.org/haskellwiki/Blog_articles 37. http://braincrater.wordpress.com/2009/03/14/pimp-your-xmonad-4-urgency-hook… 38. http://tommd.wordpress.com/2009/03/13/explicit-parallelism-via-thread-pools/ 39. http://blog.malde.org/index.php/2009/03/13/current-developments/ 40. http://wadler.blogspot.com/2009/03/cafe-scientifique.html 41. http://yi-editor.blogspot.com/2009/03/yi-060-release-notes.html 42. http://www.alsonkemp.com/haskell/announce-turbinado-v06/ 43. http://ghcsparc.blogspot.com/2009/03/thread-activity-plotting.html 44. http://www.realworldhaskell.org/blog/2009/03/12/we-won-a-jolt-award/ 45. http://www.realworldhaskell.org/blog/2009/03/13/real-world-haskell-on-the-k… 46. http://cpoucet.wordpress.com/2009/03/12/bootstrapping-cabal/ 47. http://haskell.org/gtk2hs/archives/2009/03/10/mickinator-file-manager/ 48. http://greenokapi.net/blog/2009/03/10/rough-grids-in-haskell/ 49. http://justtesting.org/post/85103645 50. http://ghcsparc.blogspot.com/2009/03/project-midpoint.html 51. http://ghcsparc.blogspot.com/2009/03/gnu-debugger-and-me.html 52. http://donsbot.wordpress.com/2009/03/09/evolving-faster-haskell-programs/ 53. http://xmonad.wordpress.com/2009/03/08/xmonad-and-the-gimp/ 54. http://xmonad.wordpress.com/2009/03/08/xmonad-on-eee/ 55. http://www.poundstone.org/blog/?p=23 56. http://holumbus.fh-wedel.de/blog/?p=18 57. http://blog.darcs.net/2009/03/darcs-weekly-news-20.html 58. http://nickmudge.info/?post=115 59. http://blog.sigfpe.com/2009/03/dinatural-transformations-and-coends.html 60. http://www.haskell.org/mailman/listinfo/haskell 61. http://sequence.complete.org/ 62. http://planet.haskell.org/ 63. http://sequence.complete.org/node/feed 64. http://haskell.org/ 65. http://haskell.org/haskellwiki/HWN 66. http://code.haskell.org/~byorgey/code/hwn/

1 0

Lazy IO breaks purity
by oleg＠okmij.org 14 Mar '09

14 Mar '09

We demonstrate how lazy IO breaks referential transparency. A pure function of the type Int->Int->Int gives different integers depending on the order of evaluation of its arguments. Our Haskell98 code uses nothing but the standard input. We conclude that extolling the purity of Haskell and advertising lazy IO is inconsistent. Henning Thielemann wrote on Haskell-Cafe: > Say I have a chain of functions: read a file, ... write that to a file, > all of these functions are written in a lazy way, which is currently > considered good style Lazy IO should not be considered good style. One of the common definitions of purity is that pure expressions should evaluate to the same results regardless of evaluation order, or that equals can be substituted for equals. If an expression of the type Int evaluates to 1, we should be able to replace every occurrence of the expression with 1 without changing the results and other observables. The expression (read s) where s is the result of the (hGetContents h1) action has the pure type, e.g., Int. Yet its evaluation does more than just producing an integer: it may also close a file associated with the handle h1. Closing the file has an observable effect: the file descriptor, which is a scarce resource, is freed. Some OS lock the open file, or prevent operations such as renaming and deletion on the open file. A file system whose file is open cannot be unmounted. Suppose I use an Haskell application such as an editor to process data from a removable drive. I mount the drive, tell the application the file name. The (still running) application finished with the file and displayed the result. And yet I can't unplug the removable drive, because it turns out that the final result was produced without needing to read all the data from the file, and the file remains unclosed. Some people say: the programmer should have used seq. That is the admission of guilt! An expression (read s)::Int that evaluates to 1 is equal to 1. So, one should be able substitute (read s) with 1. If the result of evaluating 1 turns out not needed for the final outcome, then not evaluating (read s) should not affect the outcome. And yet it does. One uses seq to force evaluation of an expression even if the result may be unused. Thus the expression of a pure type has *side-effect*. The advice about using seq reminds me of advice given to C programmers that they should not free a malloc'ed pointer twice, dereference a zero pointer and write past the boundary of an array. If lazy IO is considered good style given the proper use of seq, then C should be considered safe given the proper use of pointers and arrays. Side affects like closing a file are observable in the external world. A program may observe these effects, in an IO monad. One can argue there are no guarantees at all about what happens in the IO monad. Can side-effects of lazy IO be observable in _pure_ Haskell code, in functions with pure type? Yes, they can. The examples are depressingly easy to write, once one realizes that reading does have side effects, POSIX provides for file descriptor aliasing, and sharing becomes observable with side effects. Here is a simple Haskell98 code. > {- Haskell98! -} > > module Main where > > import System.IO > import System.Posix.IO (fdToHandle, stdInput) > > -- f1 and f2 are both pure functions, with the pure type. > -- Both compute the result of the subtraction e1 - e2. > -- The only difference between them is the sequence of > -- evaluating their arguments, e1 `seq` e2 vs. e2 `seq` e1 > -- For really pure functions, that difference should not be observable > > f1, f2:: Int -> Int -> Int > > f1 e1 e2 = e1 `seq` e2 `seq` e1 - e2 > f2 e1 e2 = e2 `seq` e1 `seq` e1 - e2 > > read_int s = read . head . words $ s > > main = do > let h1 = stdin > h2 <- fdToHandle stdInput > s1 <- hGetContents h1 > s2 <- hGetContents h2 > print $ f1 (read_int s1) (read_int s2) > -- print $ f2 (read_int s1) (read_int s2) One can compile it with GHC (I used 6.8.2, with and without -O2) and run like this ~> /tmp/a.out 1 2 -1 That is, we run the program and type 1 and 2 as the inputs. The program prints out the result, -1. If we comment out the line "print $ f1 (read_int s1) (read_int s2)" and uncomment out the last line the transcript looks like this ~> /tmp/a.out 1 2 1 Running the code with Hugs exhibits the same behavior. Thus a pure function (-) of the pure type gives different results depending on the order of evaluating its arguments. Is 1 = -1?

6 6