November 2006 - Haskell

UTP'07 at IFM: Unifying Theories of Programming
by Jeremy.Gibbons＠comlab.ox.ac.uk 20 Nov '06

20 Nov '06

First call for papers UTP'07 at IFM: Unifying Theories of Programming Organised as a special session of IFM 2007, the Sixth International Conference on Integrated Formal Methods IFM 2007 will be held at St Anne's College, Oxford, UK, from the 2nd to the 6th of July, 2007 http://www.ifm2007.org This special session follows the successful First International Symposium on Unifying Theories of Programming, UTP'06, and aims to reaffirm the significance of the ongoing UTP project, to encourage efforts to advance it by providing a focus for the sharing of results by those already actively contributing, and to raise awareness of the benefits of unifying theoretical frameworks among the wider computer science and software engineering communities. Technical contributions are invited on the UTP themes of abstraction, refinement, choice, termination, feasibility, concurrency and communication, as well as related issues. These themes include, but are not limited to, linkage of theories, algebraic descriptions, healthiness conditions, normal forms, incorporation of probabilistic programming, timed calculi, and object-based descriptions. The deadline for paper submission is 29th January 2007. The submission mechanism - via the website - will allow authors to indicate that the paper should be considered for the UTP special session. Session co-chairs: Phil Brooke University of Teesside, UK Yifeng Chen University of Durham, UK

1 0

Re: Type-class overloaded functions: second-order typeclass programming with backtracking
by oleg＠pobox.com 20 Nov '06

20 Nov '06

Sorry, forgor the precise URLs http://pobox.com/~oleg/ftp/Haskell/poly2.hs http://pobox.com/~oleg/ftp/Haskell/poly2.txt

1 0

Type-class overloaded functions: second-order typeclass programming with backtracking
by oleg＠pobox.com 20 Nov '06

20 Nov '06

We demonstrate functions polymorphic over classes of types. Each instance of such (2-polymorphic) function uses ordinary 1-polymorphic methods, to generically process values of many types, members of that 2-instance type class. The typeclass constraints are thus manipulated as first-class entities. We also show how to write typeclass instances with back-tracking: if one instance does not apply, the typechecker will chose the `next' instance -- in the precise meaning of `next'. The code only uses stable Haskell extensions (undecidable and overlapping instances) and is tested with GHC 6.4.1. Our running example is a function whose type (modulo the constraint) is approx_eq :: a -> b -> Bool It applies to values of any two types. If both arguments are of the same type and are Fractionals, the function checks if the values are the same within given tolerance, 0.5. We test the values of other numeric types for equality give or take 1. For a class of other types supporting equality, we test the values with the Eq's (==) operation. For all other types, including the cases when the two arguments are of different types, approx_eq returns False. The complete code for this article is available at http://pobox.com/~oleg/ftp/ The first inspiration for this message comes from generic programming. In approaches like SYB1 or Smash, the functions that process (sub)terms of specific types must be monomorphic. In SYB1, for example, that requirement comes from the fact that TypeRep only supports monomorphic types (see also note in Data.Dynamic documentation). One would like, for example, to traverse a term and apply a polymorphic numeric function to all subterms that are members of the class Num -- without the need to monomorphise the function. The second inspiration comes from Haskell-Cafe requests for a function that does something for any Fractional and does something else for a Num and something else entirely for a value whose type in in the class Ord. The common solution to those problems is to monomorphise -- enumerate all needed types. That leads to a notable amount of boilerplate. We'd like to process all Num values, for example, with one polymorphic function -- without manually instantiating this function for each Num type. Another drawback of the common solution is the need to enumerate Num and Fractional classes again should we need another function that does something for Fractionals and something else for Nums. We show how to eliminate that redundancy. We offer a way to describe classes of types in a _concise_ way, using unions and class differences. These classes of types may be either closed or open (extensible). After that set up, we can write arbitrarily many functions overloaded over these type classes. An instance of our function for a specific type class may use polymophic functions to generically process all members of that type class. Our functions are hence second-order polymorphic. Again, the class membership has to be described -- but only once and for all. Furthermore, we offer quite an expressive notation and the opportunity of augmenting a class at a later time. For our running example, we define the following type classes: > type Fractionals = Float :*: Double :*: HNil > type Nums = Int :*: Integer :*: AllOf Fractionals :*: HNil > type Ords = Bool :*: Char :*: AllOf Nums :*: HNil > type Eqs = AllOf (TypeCl OpenEqs) :*: AllOfBut Ords Fractionals :*: HNil > data OpenEqs > instance TypeCls OpenEqs () HTrue -- others can be added in the future In particular, Eqs specifies the class of all of Ords except Fractionals, plus the open OpenEqs. The latter currently includes (), with more types can be added at any point. We excluded Fractionals from Eqs just because we can -- and to hint that exact equality on Fractionals is unreliable. Incidentally, while the following naive definition does not type type Russel = AllOfBut () Russel :*: HNil because type synonyms can't be recursive, a more elaborated variant does work, with the expected result. Thus when we say type _class_ (rather than type _set_), we really mean it. Our implementation is a rather trivial extension of the Apply class of HList. class Apply f a r | f a -> r where apply :: f -> a -> r; apply = undefined Our 2-polymorphic functions (and their 1-polymorphic specializations) are all instances of the Apply class. They are all identified by labels (singlular datatypes) for the reasons to be explained shortly. Regular typeclasses match on types; to match on a type class, we need a guard: a type function that decides the membership. We also need the ability to `backtrack' and select another instances should the guard fail. Let us start with an example: a simple 2-polymorphic function "a -> Bool" that returns True if its argument is a member of the type class Eqs as defined above. It returns False for any other type. We start by defining the label for our function: > data IsAnEq = IsAnEq Next we define a pair of matching instances. The first isntance, of a typeclass > class GFN n f a pred | n f a -> pred specifies the guard for the instantiation number `n' of the 2-polymorphic function named `f' when applied to an argument of the type 'a'. The guard itself is a label, which, when Apply'ed to 'a' yields either HTrue or HFalse. Again, we shall see soon why we need so many labels. > instance GFN Z IsAnEq a (Member Eqs) > instance Apply (GFnA Z IsAnEq) a Bool where > apply _ _ = True We are saying here that the instantiation number Z of the function named IsAnEq has the guard (Member Eqs) -- which tests the class membership of the type 'a' in Eqs. Should this guard succeed, we `apply' (GFnA Z IsAnEq) to the argument to get the desired result -- in this case, True. The second instance is the catch-all, it applies when the guard (Member Eqs) fails: > -- the default instance > instance TypeCast pred Otherwise => GFN n IsAnEq a pred > instance Apply (GFnA n IsAnEq) a Bool where > apply _ _ = False where the Otherwise membership predicate always succeeds. We now write > test1 = [apply (GFn IsAnEq) (), apply (GFn IsAnEq) (1.0::Double), > apply (GFn IsAnEq) 'a'] which evaluetes to [True,False,True]. Recall that we explictly excluded Fractionals from Eqs. Suppose that we wish to extend the above function to pairs, that is, given a pair (x,y) it should return True if both 'x' and 'y' are in Eqs. The simplest way is to extend the type class Eqs accordingly, given that we specifically made it open. We choose a different approach however, to illustrate that the function IsAnEq is itself extensible, and can be recursively applied. We add the following pair of instances: > instance GFN (S Z) IsAnEq (x,y) Otherwise > instance (Apply (GFn IsAnEq) x Bool, > Apply (GFn IsAnEq) y Bool) > => Apply (GFnA (S Z) IsAnEq) (x,y) Bool where > apply (GFnA f) (x,y) = apply (GFn f) x && apply (GFn f) y We wedge this instance `between' the existing two. > test2 = [apply (GFn IsAnEq) (True,'a'), > apply (GFn IsAnEq) (1.0::Double,True)] > -- [True, False] Let us move to the main example: the approximate equality: test the Fractionals with the tolerance 0.5, test other Nums with the tolerance 1, and test Eqs with the exact equality. For the values of all other types (including the case when the values to compare have different types), the result is False. The order of guard tests obviously matters as all of Fractionals are also Nums. If we want to discriminate Fractionals, we should test for them first. > data ApproxEq = ApproxEq -- define the label > data PairOf t -- lift membership to pairs > instance Apply t x r => Apply (PairOf t) (x,x) r > instance TypeCast r HFalse => Apply (PairOf t) x r > > instance GFN Z ApproxEq (x,x) (PairOf (Member Fractionals)) > instance (Fractional x, Ord x) => > Apply (GFnA Z ApproxEq) (x,x) Bool where > apply _ (x,y) = abs (x - y) < 0.5 > > instance GFN (S Z) ApproxEq (x,x) (PairOf (Member Nums)) > instance (Num x, Ord x) => > Apply (GFnA (S Z) ApproxEq) (x,x) Bool where > apply _ (x,y) = abs (x - y) < 2 > > instance GFN (S (S Z)) ApproxEq (x,x) (PairOf (Member Eqs)) > instance (Eq x) => > Apply (GFnA (S (S Z)) ApproxEq) (x,x) Bool where > apply _ (x,y) = x == y -- recursion over pairs skipped... > -- The default instance > instance TypeCast pred Otherwise => GFN n ApproxEq a pred > instance Apply (GFnA n ApproxEq) a Bool where > apply _ _ = False > > -- A convenient abbreviation > approx_eq x y = apply (GFn ApproxEq) (x,y) *Poly2> :t approx_eq approx_eq :: (Apply (GFn ApproxEq) (a, b) r) => a -> b -> r > test3 = [approx_eq (1.0::Double) (1.5::Double), > approx_eq (1.0::Float) (1.1::Float), > approx_eq (1::Integer) (2::Integer), > approx_eq (1::Int) True, > approx_eq (Just ()) [], > approx_eq ((2::Integer),(2::Integer)) ((1::Integer),(2::Integer)), > approx_eq ((1::Integer),(2::Integer)) ((1::Integer),(2::Integer)) ] > -- [False,True,True,False,False,True,True] Now why we need so many labels and why we have to separate the guard and the real computation across two different typeclasses? First of all, why can't we write something like the following (as in `Smash your bolierplate') and so use real functions rather than labels? approx_eq2 x y = sapply (scons (undefined::PairOf (Member Fractionals)) eqfrac (scons (undefined::PairOf (Member Nums)) eqnum (scons (undefined::PairOf (Member Eqs)) (uncurry (==)) snil))) (x,y) False where eqfrac (x,y) = abs (x - y) < 0.5 eqnum (x,y) = abs (x-y) < 2 If we do that and write > testeq2 = approx_eq2 (1.0::Double) (1.5::Double) we get a type error, `Ambiguous Eq b constraint'. Indeed, the use of (==) in the code above gives rise to an Eq b constraint. That 'b' is not directly related to the type of the arguments to approx_eq2 -- the function (==) will be applied only if the guard `PairOf (Member Eqs)' succeeds. Thus we have no direct way to instantiate the type 'b' in general, and so the constraint 'Eq b' is left hanging, eventually leading to a type error. Second, why can't we define the guard and the corresponding computation within the same instance? For example, we could have declared a typeclass > class GFN n f a pred b | n f a -> pred, n f a -> b where > gfn :: n -> f -> a -> b Instances of GFN define a 2-polymorphic function as a set of clauses. The clauses are `numbered' via the 'n' parameter, which is of a kind numeral (Z, S Z, etc). Pred is the guard, and the numering establishes the order, so we can find the `next' instance if the guard, applied to the argument 'a', fails (that is, `Apply guard a HFalse' is derivable). Alas, to find the guard `pred', we have to select the corresponding instance. We replace a failure with the sequence of successes, selecting one instance after another, until we find the one with the succeeding guard. Those instances may come with the constraints; as we select one instance after another, the constrains accumulate (forming the conjunction). But these constraints may be contradictory. The two failing approaches show the complication we have to struggle with. A 2-polymorphic function is defined by cases where each case is, in general, a 1-polymorphic function. Each 1-polymorphic function comes with a set of constraints. We must make sure that our 2-polymorphic function makes a _disjoint_ union of those constraints rather than an intersection. Thus, unless we have committed to a particular 1-polymorphic case (the guard succeeded), we must not evaluate the corresponding constraints. Our solution has this property. We notice in the ApproxEq cases above that none of the GFN instances have any instance constraints. The corresponding Apply instances do have constraints -- which, fortunately, only take effect when the guard succeeded and the instance is selected. The name of the game is to delay the imposition of constraint. We take advantage of the fact that a label such as ApproxEq _stands_ for a set of constraints but does not have any actual constraints. We play on the difference between the notation and denotation. The need to spread the guard and the corresponding computation across two instances is less satisfying. Fortunately, the type system watches for the consistency between the two, that is, the guard admitting no more types that can be used in the real computation. It seems appropriate to end this message with xxx lines of implementation. The complete code with more examples is available at the URL given above. newtype GFn f = GFn f newtype GFnA n f = GFnA f newtype GFnTest n f flag = GFnTest f instance (GFN Z f a pred, Apply pred a flag, Apply (GFnTest Z f flag) a b) => Apply (GFn f) a b where apply (GFn f) a = apply ((GFnTest f)::GFnTest Z f flag) a instance Apply (GFnA n f) a b -- guard succeeded => Apply (GFnTest n f HTrue) a b where apply (GFnTest f) a = apply ((GFnA f) :: GFnA n f) a instance (GFN (S n) f a pred, Apply pred a flag, -- else chose the next inst Apply (GFnTest (S n) f flag) a b) => Apply (GFnTest n f HFalse) a b where apply (GFnTest f) a = apply ((GFnTest f)::GFnTest (S n) f flag) a

1 0

I18N, external strings
by Johannes Waldmann 17 Nov '06

17 Nov '06

What methods and tools are there for i18n of Haskell programs? (I.e. I want output in several languages, with the language configurable at runtime, and I want to add languages without recompilation.) a typical source text (for my application) is here http://141.57.11.163/cgi-bin/cvsweb/tool/src/Graph/Circle/Plain.hs?rev=1.2 it contains (German) text strings all over the place. In Java/Eclipse, I would "Source -> Externalize Strings" and this replaces each string by something like Messages.getString("Foobar.0") where Messages is a global variable (constructed at program start from reading a properties file) In Haskell, I see at least two problems: a) reading the file is in IO b) there are no "global variables". implicit parameters perhaps? c) when I'm trying to be clever, I use "deriving Show/Read" or similar. then i18n should rename the constructors/accessors? I rather not. http://141.57.11.163/cgi-bin/cvsweb/tool/src/Grammatik/Type.hs.drift?rev=1.6 Best regards, -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------

4 3

Fundep broken in GHC 6.6
by Yitzchak Gale 16 Nov '06

16 Nov '06

Hi, The following class declaration worked in GHC 6.4. I recently upgraded to 6.6 (following Debian), and now it is broken. class Error e => Game b mv e | b -> mv e where newBoard :: MonadState b m => m () ... Since MonadState has the fundep m -> b, the type of newBoard fully specifies all of the class parameters. And this worked fine in GHC 6.4. But GHC 6.6 complains: The class method `newBoard' mentions none of the type variables of the class Game b mv e When checking the class method: newBoard :: m () In the class declaration for `Game' Any ideas? Thanks, Yitz

1 1

HaskellWiki Style Help
by Ashley Yakeley 16 Nov '06

16 Nov '06

If you're interested in improving the CSS for HaskellWiki, please go to <http://haskell.org/haskellwiki/HaskellWiki:Community#Style_Help>. The only requirements are knowledge of CSS and an ability to use MediaWiki. More than one person would be ideal. At Simon PJ's request, I have also turned on numbered headings for when not logged in. Logged-in users can set this option at Preferences -> Misc. I'm not sure it's an improvement, however; it makes the front page look a bit odd. -- Ashley Yakeley

1 0

ANNOUNCE: LocH, source locations in error, trace, and exceptions
by dons＠cse.unsw.edu.au 15 Nov '06

15 Nov '06

The topic of improving exception diagnosis in Haskell is hot at the moment, and I'm pleased to announce the release of LocH, a small Haskell module providing source location-specific error messages and debugging strings for Haskell code. It uses the compiler-expanded 'assert' token, rather than cpp or m4, to provide a lightweight approach to generating source locations. No preprocessor is required. The code is available under a BSD license. The LocH home: http://www.cse.unsw.edu.au/~dons/loch.html The API: http://www.cse.unsw.edu.au/~dons/loch/Debug-Trace-Location.html Example usage: import Debug.Trace.Location main = trace assert "Starting ..." $ do print 1 trace assert "Finished" $ do print 2 let x = check assert $ head ([] :: [Int]) print x Will produce: $ ./a.out A.hs:4:10-15: Starting ... 1 A.hs:6:10-15: Finished 2 a.out: A.hs:8:18-23: Prelude.head: empty list LocH provides located versions of trace, failure, as well as check and checkIO to wrap exception-throwing pure and IO code. May all your exceptions be located, Don

1 0

ANN: Safe library, 0.1
by Neil Mitchell 14 Nov '06

14 Nov '06

Hi, I am hereby releasing the Safe library, 0.1. http://www-users.cs.york.ac.uk/~ndm/projects/libraries.php#safe (darcs repo, haddock documentation, cabal file, BSD3 licensed) People often have a problem with pattern match errors, and the only helpful message they get is: "pattern match error, head []". The Safe library hopes to eliminate some of the frustration this causes. Within the Safe library there are 3 different forms of head: headNote - takes an extra parameter which gives extra information - such as the function that is calling head, or a useful reminder to the programmer why head might be failing. headDef - takes an extra parameter being the default value, to return on the empty list. headMay - wrap the result in a Maybe, returning Nothing for failure. There are also a large number of other wrapped functions, which may prove useful. A variant of this library has been in use one of my projects (Catch) for some time, and has saved a lot of debugging headaches. I have found an effective way of debugging is to use the normal head function, and then when an error occurs start replacing instances of head with headNote until the error is diagnosed. Once the headNote's have been inserted, leave them, to help next time. Any comments or suggestions are welcome. Thanks Neil

1 0

[ANN] Call for participation: TLDI'07
by Francois Pottier 14 Nov '06

14 Nov '06

****************************************************************************** The 2007 ACM SIGPLAN Workshop on Types in Language Design and Implementation (TLDI'07) Affiliated with the 34th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (POPL'07) Call for Participation http://www.cs.berkeley.edu/~necula/tldi07/ ****************************************************************************** Preliminary programme Invited talks: Kathleen Fisher (AT&T Research) Conor McBride (University of Nottingham) Accepted papers: A Garbage-Collecting Typed Assembly Language Chris Hawblitzel, Heng Huang, Lea Wittie and Juan Chen A graphical presentation of MLF types with a linear-time unification algorithm Didier Rémy and Boris Yakobowski An Open Framework for Foundational Proof-Carrying Code Xinyu Feng, Zhaozhong Ni, Zhong Shao and Yu Guo Modular Information Hiding and Type-Safe Linking for C Saurabh Srivastava, Michael Hicks and Jeffrey Foster Semantics of an Effect Analysis for Exceptions Nick Benton and Peter Buchlovsky System F with Type Equality Coercions Martin Sulzmann, Manuel Chakravarty, Simon Peyton Jones and Kevin Donnelly ****************************************************************************** Scope The role of types and proofs in all aspects of language design, compiler construction, and software development has expanded greatly in recent years. Type systems, type analyses, and formal deduction have led to new concepts in compilation techniques for modern programming languages, verification of safety and security properties of programs, program transformation and optimization, and many other areas. In light of this expanding role of types, the ACM SIGPLAN Workshop on Types in Language Design and Implementation (TLDI'07) follows five previous International Workshops on types in compilation and language design (TIC'97, TIC'98, TIC'00, and TLDI'03 and TLDI'05), with the hope of bringing together researchers to share new ideas and results in this area. ****************************************************************************** General Chair François Pottier INRIA Rocquencourt BP 105 78153 Le Chesnay Cedex FRANCE francois.pottier(a)inria.fr Program Chair George Necula University of California 783 Soda Hall Berkeley, CA 94720 necula(a)cs.berkeley.edu Program Committee Damien Doligez, INRIA Peter Lee, Carnegie Mellon University Andrew Kennedy, Microsoft Research, Cambridge Naoki Kobayashi, Tohoku University George Necula (chair), University of California, Berkeley Randy Pollack, Edinburgh University Norman Ramsey, Harvard University David Tarditi, Microsoft Research, Redmond Stephanie Weirich, University of Pennsylvania Hongwei Xi, Boston University

1 0

Haskell Weekly News: November 14, 2006
by dons＠cse.unsw.edu.au 14 Nov '06

14 Nov '06

--------------------------------------------------------------------------- Haskell Weekly News http://haskell.org/haskellwiki/HWN Issue 49 - November 14, 2006 --------------------------------------------------------------------------- Welcome to issue 49 of HWN, a weekly newsletter covering developments in the Haskell community. This week we see the announcement of a Haskell to Javascript compiler project, and the overhaul of GHC's typeclass machinery is complete. Announcements * Compiling Haskell to Javascript: YCR2JS. Dimitry Golubovsky [1]announced Ycr2js, a sub-project within the [2]York Haskell Compiler (Yhc) project. It is aimed to create a tool to convert an arbitrary Haskell program into Javascript which in turn may be executed in any Web browser. With great amount of help from the Yhc Team, the converter has been integrated into the Yhc project, and initial stage of coding and development has been completed. [3]More documentation. 1. http://article.gmane.org/gmane.comp.lang.haskell.general/14471 2. http://darcs.haskell.org/yhc 3. http://haskell.org/haskellwiki/Yhc/Javascript * System.FilePath 0.10. Neil Mitchell [4]announced System.FilePath 0.10, which hopefully is pretty close to final. [5]This library manipulates FilePath's correctly on both Posix and Windows. 4. http://article.gmane.org/gmane.comp.lang.haskell.general/14467 5. http://www-users.cs.york.ac.uk/~ndm/projects/libraries.php#filepath * Major typeclass overhaul. Simon Peyton-Jones [6]mentioned that for some time he has been promising an overhaul of GHC's type inference machinery to fix the interactions between type classes and GADTs. This overhaul has now been completed, and user-visible changes are summarised, including: GHC's type inference becomes complete, the restriction that every constraint in a type signature must mention at least one of the quantified type variables is lifted, dictionaries are packaged in data constructors and the proper interaction between GADTs and type classes is now respected. 6. http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/11192 * Implementing the lambda calculus. Lennart Augustsson [7]wrote about implementing interpreters for the lambda-calculus in Haskell, to [8]experiment with different implementation methods. 7. http://article.gmane.org/gmane.comp.lang.haskell.cafe/16490 8. http://darcs.augustsson.net/Darcs/Lambda/ * Great language shootout: reloaded. Don Stewart [9]mentioned that now [10]GHC 6.6 is available on the shootout machines, the time has come to improve the existing [11]language shootout entries. Improvements can be posted to the [12]wiki for review. 9. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/16454/focus=16454 10. http://haskell.org/ghc 11. http://shootout.alioth.debian.org/ 12. http://www.haskell.org/haskellwiki/Great_language_shootout Haskell' This section covers the [13]Haskell' standardisation process. * [14]Overloading string literals * [15]Annotation systems 13. http://hackage.haskell.org/trac/haskell-prime 14. http://thread.gmane.org/gmane.comp.lang.haskell.prime/1882/focus=1882 15. http://thread.gmane.org/gmane.comp.lang.haskell.prime/1889/focus=1889 Libraries This week's proposals and extensions to the [16]standard libraries. * [17]Adding Kleisli composition to Control.Monad * [18]Add ranged sets * [19]Add unsafeCoerce 16. http://haskell.org/haskellwiki/Library_submissions 17. http://thread.gmane.org/gmane.comp.lang.haskell.libraries/5640/focus=5640 18. http://thread.gmane.org/gmane.comp.lang.haskell.libraries/5635/focus=5635 19. http://thread.gmane.org/gmane.comp.lang.haskell.libraries/5611/focus=5611 Discussion * Choosing a Haskell GUI library. Bulat Ziganshin [20]asked for advice on which Haskell gui library to use. Several suggestions were made. 20. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/16497/focus=16497 Conference roundup Asian Symposium on Programming Languages and Systems (APLAS 2006) * Type Processing by Constraint Reasoning. Peter Stuckey. [21]Paper. * Principal Type Inference for GHC-Style Multi-Parameter Type Classes. Martin Sulzmann, Tom Schrijvers and Peter J Stuckey. [22]Paper. * Automatic Testing of Higher Order Functions. Pieter Koopman and Rinus Plasmeijer. [23]Paper. 21. http://www.cs.mu.oz.au/~pjs/papers/aplas06i.pdf 22. http://www.comp.nus.edu.sg/~sulzmann/publications/ghc-mptc-inf.ps 23. http://www.st.cs.ru.nl/papers/2006/koop2006-TestingOfHigherOrderFunctionsAP… Jobs * Research position in spatial cognition (Haskell-related). Till Mossakowski [24]announced the availability of a Doctoral Research Assistant / Postdoctoral Researcher position at the Universit�t Bremen, concerned with classification and formalization of qualitative spatial calculi, relations among these calculi, spatial ontologies, and route graphs. [25]More information. 24. http://article.gmane.org/gmane.comp.lang.haskell.general/14469 25. http://www.sfbtr8.uni-bremen.de/i4.html Blog noise [26]Haskell news from the blogosphere. * [27]Getting real with Haskell * [28]A Simple RPN Calculator in Haskell * [29]One more grunt trying to learn Haskell * [30]Testing Telecoms Software with Quviq QuickCheck * [31]Quviq QuickCheck: A new automated testing tool * [32]My first Haskell adventure game! 26. http://planet.haskell.org/ 27. http://therning.org/magnus/archives/219 28. http://jcreigh.blogspot.com/2006/11/simple-rpn-calculator-in-haskell.html 29. http://monad.carnalreason.org/wordpress/?p=4 30. http://lambda-the-ultimate.org/node/1827 31. http://blog.lab49.com/?p=703 32. http://jpmoresmau.blogspot.com/2006/11/my-first-haskell-adventure-game.html Quotes of the Week * dylan: I remember being introduced to lambdas (in perl) from the programming perl, 2nd edition book. I used them heavily ever since... like some kind of cocaine addiction. * jdunck: What's your safeword? * sketerpot: With very strict typing, you need an *unsafe*word. * Binkley: Can you represent 'more moronic than Slashdot' with a 32-bit integer? * Robert Dockins: A Turing-complete type-checker isn't enough! Our work is not complete until the parser is a universal machine as well! * dons: Disable the type checker in GHC for 6 months and we'd have 5 Haskell debuggers by the end of it. * lennart: System Verilog is one of the worst 'designs' I've ever seen. So I bet it will be popular * lispy: The biggest reason most developers I know don't fix a bug is because they don't know it exists yet * monochrom: Time flies like an arrow. Fruit flies like a banana. Syntax rules like a macro * robreim: [on the new #haskell lojban channel] Great, now we've got to start an IRC channel for lojban-speaking, Haskell-coding anarchists * syntaxfree: Yes, Wadlerman: Prince of Funktions Code Watch * 2006-11-09 17:01:33 GMT. Claus Reinke. [33]Syntax patch for lambda-match. 33. http://article.gmane.org/gmane.comp.lang.haskell.cvs.ghc/17645 * 2006-11-06 21:27:30 GMT. Lennart Kolmodin. [34]New ghc-pkg option 'check'. A patch for ghc-pkg show broken packages (due to missing dependencies) with a new command 'check', and also indicate broken packages when using the command 'list'. 34. http://article.gmane.org/gmane.comp.lang.haskell.cvs.ghc/17656 * 2006-11-10 13:43:26 GMT. Simon Peyton Jones. [35]Use implication constraints to improve type inference. 35. http://article.gmane.org/gmane.comp.lang.haskell.cvs.ghc/17665 * 2006-11-13 09:36:19 GMT. Simon Peyton Jones. [36]Add literal-shift rewrite rules. 36. http://article.gmane.org/gmane.comp.lang.haskell.cvs.ghc/17705 About the Haskell Weekly News Each week, new editions are posted to [37]the Haskell mailing list as well as to [38]the Haskell Sequence and [39]Planet Haskell. [40]RSS is also available, and headlines appear on [41]haskell.org. The Haskell Weekly News is also [42]available in Spanish translation. To help create new editions of this newsletter, please see the [43]contributing information. Send stories to dons at cse.unsw.edu.au. The darcs repository is available at darcs get http://www.cse.unsw.edu.au/~dons/code/hwn 37. http://www.haskell.org/mailman/listinfo/haskell 38. http://sequence.complete.org/ 39. http://planet.haskell.org/ 40. http://sequence.complete.org/node/feed 41. http://haskell.org/ 42. http://haskell.org/haskellwiki/HWN/es 43. http://haskell.org/haskellwiki/HWN

1 0