January 2006 - Haskell

Switch to MediaWiki
by John Peterson 26 Jan '06

26 Jan '06

We have finally finished moving nearly all of the top level haskell.org content over to the new wiki. Sometime soon switch to the new pages will happen. But meanwhile, there's a lot of work to do in the new wiki. Many of the pages on the old site were very out of date. The wiki pages are just as out of date, but at least you can fix them easily. The Links to Haskell people and projects is in pretty sad shape - a lot of people have moved and the links point many dead web pages. If you're listed, please check that your link is up to date. Even better, make yourself little user page in the wiki (every login has an associated user page), direct the link to that, and then you can throw your links and maybe a very short Haskell bio there. If you're not on the list just add yourself - we're not fussy. If there are links to group pages or companies missing you can add those. The Haskell in Education page is pretty outdated. It hasn't been seen to for a long time. I think that there's no longer much need to have a thumbnail sketch of each class at haskell.org but a link to your class homepage would be nice. You can always add a wiki page for your class and place information there. I expect this page will reorganize soon but if you get a link on it we'll make sure it stays on the site. Pages on jobs and consultants seem to be a bit out of date too - please edit as needed. The overall organization of the front page is definitely up for grabs - I believe there are too many links and we could simplify this. Be bold in your edits. Anyone with a good sense of style is welcome to add some MediaWiki templates to make things more interesting. We killed off most of the tables in the transition - some more tables would certainly help organize the site. And if you want to do some new logos, go for it. The old wiki will stay around - we have no intention of turning it off. However, I find the new wiki much nicer and hope that people will willingly migrate to the new one. Thanks to everyone who has helped with this, especially Ashley who did most of the hard work. I believe that haskell.org will stay much more current now. Olaf and I certainly won't miss getting email messages about broken links or new libraries. The new wiki is at http://haskell.org/haskellwiki/ - go have fun with it. I don't know when we'll make the switch but it will be soon. We most definitely will not be requiring that other haskell.org pages move to the wiki or change the url of anything currently hosted there. John

1 0

Simple IO Regions
by oleg＠pobox.com 26 Jan '06

26 Jan '06

This message shows a very simple implementation of Monadic Regions (for the particular case of IO and reading the file). The technique *statically* guarantees that neither a file handle nor any computation involving the handle can leak outside of the region that created it. Therefore, the handle can be safely closed (and its resources disposed of) whenever control leaves the corresponding 'withFile' block. Many handles can be open simultaneously, the type system enforces the proper nesting of their regions. The technique has no run-time overhead and induces no run-time errors. Unlike the previous implementation of monadic regions, only the basic extensions (higher-ranked types and one two-parameter type class) are used. No undecidable instances, no functional dependencies (let alone overlapping instances) are required. In fact, the implementation uses only one trivial typeclass and one trivial instance. Perhaps such an approach to File IO can be more widely used? It trivially generalizes to database IO and other kinds of IO. The motivation for monadic regions has been best explained by: Brandon Moore wrote on Haskell Cafe: > I'm assuming you understand how the type on runST and the STRef > operations ensure that, even though you *can* smuggle out an STRef in > the result from runST, you will never be able to use it again. > > The idea was to do the equivalent thing with databases: use fancy types > to ensure that handle can only be used inside to origination withDB or > withCursor or whatever, and the bracketing function can release the > resource on the way out, without worrying about it being used again. Benjamin Franksen wrote: > I think this is an extremely good idea. I have been very frustrated > with finalizers because of their limitations (can't rely on them being > called at all), so have (reluctantly) been using the unsafe bracket > version. Making it safe via a type system trick is really the way to > go. Let us start with the tests > {-# OPTIONS -fglasgow-exts #-} > > module IORegionsTest where > > import IORegions -- see below > > test0 = withFile "/etc/motd" (const $ return True) > > reader q = do > c1 <- qGetChar q > c2 <- qGetChar q > return [c1,c2] > > test1 = withFile "/etc/motd" reader > test1r = runIOM test1 >>= print Instead of handles, we have Qs -- marked handles. The are created by the function withFile and used similar to regular handles. A special IOM monad is a newtype away from the regular IO. The phantom type parameter of the IOM monad maintains the marks of the regions. *IORegionsTest> :t reader reader :: (Monad (IOM marks), IORegions.IN mark marks) => Q mark -> IOM marks [Char] the type of the reader shows that it takes a marked handle and yields a marked IO computation. The constraint IN assures that the computation must be marked with the mark of the handle. If we attempt to leak the handle: *> test2 = withFile "/tmp/i.hs" (\q -> return q) we get Inferred type is less polymorphic than expected Quantified type variable `mark' escapes In the second argument of `withFile', namely `(\ q -> return q)' The following is OK: we perform the computation and return its result: > test3 = withFile "/etc/motd" (\q -> (qGetChar q)) If we attempt to return the unperformed computation itself: *> test4 = withFile "/tmp/i.hs" (\q -> return (qGetChar q)) we get Could not deduce (IORegions.IN mark marks1) from the context (IORegions.IN mark marks) arising from use of `qGetChar' at IORegionsTest.h... As we said earlier, more than one handle can be at play at the same time: > reader2 q1 q2 = do > c1 <- qGetChar q1 > c2 <- qGetChar q2 > return [c1,c2] > test5 = withFile "/etc/motd" (\q1 -> > withFile "/etc/motd" (\q2 -> reader2 q1 q2)) > > test5r = runIOM test5 >>= print Incidentally, the inferred type of reader2 is *IORegionsTest> :t reader2 reader2 :: (Monad (IOM marks), IORegions.IN mark1 marks, IORegions.IN mark marks) => Q mark -> Q mark1 -> IOM marks [Char] Obviously, the resulting computation is marked with the marks of both argument handles. With two handles, we can actually return a handle -- provided we return an outermost handle from the innermost region (but not the other way around). For example, the following is wrong *> test6 = withFile "/etc/motd" *> (\q2 -> *> do *> q' <- withFile "/etc/motd" (\q -> return q) *> qGetChar q') but the following is OK: > test7 = withFile "/etc/motd" > (\q2 -> > do > q' <- withFile "/etc/motd" (\q -> return q2) > qGetChar q') Ditto for the computation: The following is the improper leakage and leads to a type error: *> test8 = withFile "/etc/motd" *> (\q2 -> *> do *> a <- withFile "/etc/motd" (\q -> return (qGetChar q)) *> a) But the following is fine: > test9 = withFile "/etc/motd" > (\q2 -> > do > a <- withFile "/etc/motd" (\q -> return (qGetChar q2)) > a) > > test9r = runIOM test9 >>= print -- The file IORegions.hs follows. {-# OPTIONS -fglasgow-exts #-} -- Simple IO Regions module IORegions (runIOM, qGetChar, withFile, -- Only types are exported, not their data constructors! Q, IOM) where import Control.Exception import System.IO -- The marked IO monad. The data constructor is not exported. -- The type 'marks' is purely phantom (and is never instantiated, actually) newtype IOM marks a = IOM (IO a) deriving Monad unIOM (IOM x) = x -- The marked IO handle. The data constructor is not exported. newtype Q mark = Q Handle -- |IN mark marks| asserts that |mark| is a member of the mark set |marks| -- The mark set is really a set, and the best of all, it's typechecker -- that maintains it. We don't need to do anything at all. class IN a b instance IN () b -- Reading from a marked handle. The mark must be within the marks -- associated with the IOM monad qGetChar :: (IN mark marks) => Q mark -> IOM marks Char qGetChar (Q h) = IOM $ hGetChar h -- There must not be an operation to close a marked handle! -- withFile takes care of opening and closing (and disposing) of -- handles. -- Open the file, add the markset constraint for the duration of the body, -- and make sure the marked handle does not escape. -- The marked handle is closed on normal or abnormal exit from the -- body -- The type system guarantees the strong lexical scoping of -- withFile. That is, we can assuredly close all the handles after -- we leave withFile because we are assured that no computations with -- marked handles can occur after we leave withFile. withFile :: FilePath -> (forall mark. IN mark marks => Q mark -> IOM marks a) -> IOM marks a withFile filename proc = IOM( bracket (openFile filename ReadMode) (hClose) (\handle -> unIOM $ proc ((Q handle) :: Q ()))) -- Running the IOM monad runIOM :: (forall mark. IOM mark a) -> IO a runIOM = unIOM

4 7

Re[2]: [Template-haskell] new TH tutorial (request for comments)
by Bulat Ziganshin 24 Jan '06

24 Jan '06

Hello Johannes, Monday, January 23, 2006, 11:27:58 AM, you wrote: JW> I'd like to read some overview and comparison on "second-level JW> programming" in Haskell (and if there is none, I'm willing to contribute): citating my another letter: "when i was interested in generic programmimg with Haskell, i found 7 projects, which can be used for it: drift -fgenerics TH generic haskell polyp SYB strafunski" JW> what is the relation between Preprocessors (DrIFT), Template Haskell, JW> Data.Generics/Typeable (so perhaps have one example presented in each JW> of these frameworks) i also had an idea of small overview of these all tools. i divided them to 3 categories: general preprocessors/code generators TH DrIFT compile-time generic programming tools GH PolyP -fgenerics dynamic generic programming libraries SYB strafunski it's interesting that GHC itself armored with just one tool in each category! :) of course, -fgenerics is very weak tool, so compile-time generic programming is the area where GHC has lesser power JW> and how it compares to Reflection (including Annotations) as in JW> http://java.sun.com/j2se/1.5.0/docs/api/java/lang/reflect/package-summary.h… JW> I have the feeling that annoations (in the Java sense, see JLS 9.6/9.7) JW> are a clever and powerful idea that we might want to copy. no opinion, just citating for haskell maillist :) -- Best regards, Bulat mailto:bulatz@HotPOP.com

4 3

Visual Haskell for Visual Studio 2005
by Lars Schouw 24 Jan '06

24 Jan '06

Simon, All, First of all congratulations on a great product and all the time spend on this. Is there any plans to let Visual Haskell support Visual Studio 2005 like f#? Regards Lars Schouw Tokyo, Japan --------------------------------- Yahoo! Photos Got holiday prints? See all the ways to get quality prints in your hands ASAP.

2 1

RE: [Haskell] IO Regions in Haskell98
by Simon Peyton-Jones 24 Jan '06

24 Jan '06

| however that there is a Haskell98 implementation of IO regions. The | solution involves no higher-ranked types, and works both in GHC and | Hugs. The idea is trivial: given | | > newtype Q = Q Handle | > newtype IOM a = IOM (IO a) | > qGetChar :: Q -> IOM Char | > withFile :: FilePath -> (Q -> IOM a) -> IOM a | | we wish to assure that the handle Q never escapes, neither explicitly | nor implicitly. Don't side effects kill you? withFile "foo" (\q -> writeIORef var q) So would unsafePerformIO withFile "foo" (\q -> return (unsafePerformIO (qGetChar q))) Simon

2 1

Modelling languages for FP (like UML for OO)
by Mads Lindstrøm 23 Jan '06

23 Jan '06

Hi all In object-oriented programming, UML is used to model programs. In functional programming (especially Haskell) we use ??? The only graphical modellering language I have found is FAD: http://www.cs.kent.ac.uk/pubs/2001/1152/ . Are there other approaches? Are anybody, except for the creates of FAD, using it? If you are using FAD, what are your experiences with it? I am mainly interested in the macro level. That is modules, classes, class instances, ... Not in modellering the internals of a function. Greetings, Mads Lindstrøm

7 7

RE: [Haskell] Pattern Matching with rank-2 types
by Simon Peyton-Jones 23 Jan '06

23 Jan '06

Well spotted! Yes, I changed this some time ago. Handling polymorphic subsumption when matching patterns just turned to be a lot of hassle, with little obvious payoff. Types in patterns must now match exactly. I could conceivably back-pedal on this, but you are the first person to even notice the change (or at least to comment on it). Simon | -----Original Message----- | From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Bruno Oliveira | Sent: 21 January 2006 18:44 | To: Haskell Mailing List | Subject: [Haskell] Pattern Matching with rank-2 types | | Hello, | | The following function is a valid function in ghc6.2.2: | | > func :: (forall a . [a]) -> [b] | > func [] = [] | | However, in ghc6.4.1 it does not work anymore: | | Iterators4.lhs:56:6: | Couldn't match `forall a. [a]' against `[a]' | When checking the pattern: [] | In the definition of `func': func [] = [] | | Is this supposed to happen? | | Cheers, | | Bruno | | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

1 0

Haskell Weekly News: January 23, 2006
by dons＠cse.unsw.edu.au 23 Jan '06

23 Jan '06

Haskell Weekly News: January 23, 2006 Greetings, and thanks for reading the 21st issue of HWN, a weekly newsletter for the Haskell community. Each Monday, new editions are posted to [1]the Haskell mailing list and to [2]The Haskell Sequence. [3]RSS is also available. 1. http://www.haskell.org/mailman/listinfo/haskell 2. http://sequence.complete.org/ 3. http://sequence.complete.org/node/feed New Releases * Haskell' This week Isaac Jones announced that the Haskell' standardisation process is underway. Haskell' will be a conservative refinement of Haskell 98: "Announcing the Haskell' ("Haskell-Prime") process. A short time ago, I asked for volunteers to help with the next Haskell standard. A brave group has spoken up, and we've organized ourselves into a committee in order to coordinate the community's work. It will be the committee's task to bring together the very best ideas and work of the broader community in an "open-source" way, and to fill in any gaps in order to make Haskell' as coherent and elegant as Haskell 98." Read the full announcement [4]here. Presently, the following resources are available: + [5]The haskell-prime mailing list + The Haskell' [6]issue tracking system/wiki + A [7]darcs repository for larger code examples and experiments Please join us in making Haskell' a success. 4. http://article.gmane.org/gmane.comp.lang.haskell.general/13138 5. http://haskell.org/mailman/listinfo/haskell-prime 6. http://hackage.haskell.org/trac/haskell-prime 7. http://hackage.haskell.org/trac/haskell-prime/wiki/SourceCode Resources and Tools * Cabal. Isaac Jones [8]announced some changes to Cabal, including new changes to the `hooks' interface. Feedback is encouraged. Secondly, a move is underway to build [9]an exhaustive list of all Cabalised packages. Add a link if you have something! Isaac is asking people to re-send any Cabal bug reports or feature requests yet to be addressed. Report them on the [10]Cabal Wiki & Bug Tracker 8. http://article.gmane.org/gmane.comp.lang.haskell.libraries/4145 9. http://hackage.haskell.org/trac/hackage/wiki/CabalPackages 10. http://hackage.haskell.org/trac/hackage/ * Darcs switchover GHC has [11]switched to darcs. The era of CVS is at an end: From: Simon Marlow Subject: TAG final switch to darcs, this repo is now live Fri Jan 20 05:46:30 PST 2006 Simon Marlow microsoft.com> tagged final switch to darcs, this repo is now live 11. http://article.gmane.org/gmane.comp.lang.haskell.cvs.ghc/13186 Discussion * IO Regions. Oleg Kiselyov [12]describes a simple implementation of monadic regions. The technique provides static guarantees that neither a file handle nor any computation involving the handle can leak outside of the region that created it. The technique has no runtime overhead and induces no runtime errors. For some background, John Launchbury and Simon Peyton Jones's 94 paper [13]Lazy Functional State Threads is useful. 12. http://article.gmane.org/gmane.comp.lang.haskell.general/13106 13. http://www.cse.ogi.edu/~jl/Papers/stateThreads.ps * Lexically scoped type variables. Simon Peyton-Jones [14]released a proposal to change the way in which lexically-scoped typed variables work in GHC, as part of a revision to make type inference for GADTs simpler and more uniform. 14. http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/9219 * Providing an alternative to GMP. Esa Ilari Vuokko [15]began a discussion on modifying the GHC runtime and build system to support alternative arbtirary precision arithmetic libraries, other than the GPL'd GMP. 15. http://article.gmane.org/gmane.comp.lang.haskell.cvs.ghc/13198 * Arrays interfaces. (clarification) The Haskell'98 library report contains only basic Array implementation. The Hierarchical Libraries, shipped with modern versions of GHC, Hugs and NHC, includes much richer arrays library. [16]Bulat Ziganshin started [17]a wiki page describing how to use these new array interfaces. 16. http://article.gmane.org/gmane.comp.lang.haskell.general/12992 17. http://haskell.org/haskellwiki/Arrays Papers This is a new HWN section collecting paper or article abstracts on Haskell-related topics. If you have submitted a new Haskell paper, send your abstract to HWN, and the abstract will appear in the next issue. * Ralf L�mmel. Book review, "The Haskell Road to Logic, Maths and Programming" by Kees Doets and Jan van Eijck. To appear in JoLLI journal; 13 pages. [18]http://www.cs.vu.nl/~ralf/JoLLI06. The "Haskell road" is an excellent book worth considering as course material and reading anyhow. A non-Haskell road is also discussed in the review. 18. http://www.cs.vu.nl/~ralf/JoLLI06 * Ralf L�mmel. "Google's MapReduce Programming Model -- Revisited" Draft; To be submitted; feedback appreciated; 27 pages. [19]http://www.cs.vu.nl/~ralf/MapReduce. The seminal MapReduce paper had been briefly discussed at LTU without really going into technical details. The present paper discovers the concepts from a functional programming perspective. Did you ever wonder why MapReduce is called MapReduce? 19. http://www.cs.vu.nl/~ralf/MapReduce Darcs Corner * Darcs Blogging. Zooko [20]wrote an interesting blog entry on the PR issues darcs has, and on the various activities undertaken by the darcs developers. 20. http://article.gmane.org/gmane.comp.version-control.darcs.user/9258 Quote of the Week <monochrom> monadic regions? sounds neat. <monochrom> "monadic ___" sounds neat :) <dons> forall a. Monad a => Neat a Contributing to HWN Thanks to Bulat Ziganshin and Isaac Jones for contributing material to this edition of HWN. You can help us create new editions of this newsletter. Please see the [21]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 21. http://sequence.complete.org/hwn-contrib

1 0

duplicate elements in Data.Set
by Walter Moreira 22 Jan '06

22 Jan '06

Hello list. Are there situations where a set can contain duplicate elements? I have a newtype and it is an instance of 'Eq' via the 'compare' method, and it is also an instance of 'Ord'. After some Data.Set operations with sets of that type I get a set which contains two elements which compare equal. What am I doing wrong? The function 'Set.valid' returns 'False' when applied to the set. I use the function 'Set.fromList' sometimes. Is it supposed to always yield a valid set? or it may depend on the order or equality? Sorry the question is a little vague. When I try to construct small examples the problem disappear. Thanks, Walter

2 1

Pattern Matching with rank-2 types
by Bruno Oliveira 21 Jan '06

21 Jan '06

Hello, The following function is a valid function in ghc6.2.2: > func :: (forall a . [a]) -> [b] > func [] = [] However, in ghc6.4.1 it does not work anymore: Iterators4.lhs:56:6: Couldn't match `forall a. [a]' against `[a]' When checking the pattern: [] In the definition of `func': func [] = [] Is this supposed to happen? Cheers, Bruno

1 0