February 2006 - Haskell

RE: [Haskell] Compilation of big, computed tables
by Simon Peyton-Jones 23 Feb '06

23 Feb '06

http://haskell.org/haskellwiki/GHC:FAQ (search for cse) | -----Original Message----- | From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Bjorn Lisper | Sent: 23 February 2006 10:28 | To: haskell(a)list.mightyreason.com | Cc: Haskell(a)haskell.org | Subject: Re: [Haskell] Compilation of big, computed tables | | Chris Kuklewicz: | >Stefan Karrmann wrote: | >> Dear all, | >> | >> can ghc compile huge tables into efficient code if they are constant at | >> compile time? | >> | >> Two examples may clearify the question: | >> | >> big1 :: UArray Int Char | >> big1 = array (0,1000) $! map (\i -> (i,toEnum i)) [0..1000] | >> | >> big2 = sum [0..10000]::Int -- == 50005000 == n*(n+1)/2 where n = 10000 | >> | > | >GHC does not compute such values are compile time because | >*) The computation may not finish in reasonable time (infinite/not halting) | >*) The computation may generate a run-time error and crash the compilation | >(divide by zero, pattern march failure, etc.) | >*) Haskell is supposed to be lazy, things are computed when needed, not before | | Does this mean that GHC does not evaluate constant subexpressions at | compile-time? Or does it evaluate only some subclass of surely terminating | and non-erroneous subexpressions at compile-time? | | Constant subexpression evaluation is a common compiler optimization | technique, so I would be a bit surprised if GHC does not do it. | | Björn LIsper | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

1 0

page renaming on the Haskell Wiki
by Wolfgang Jeltsch 22 Feb '06

22 Feb '06

Hello, I just renamed several wiki pages. One reason for this renaming was the inconsistent capitalization of page titles. The thread starting with http://www.haskell.org//pipermail/haskell/2006-January/017485.html contains some background of this renaming. I think that a consistent and sensible naming of pages of the Haskell Wiki is very important. Since no further opinions were given concerning page naming and late page renamings might be inconvenient for wiki users, I decided to do this page renaming now, according to what was said in the above-mentioned thread and to what I thought was sensible. I have put some further information about the renaming on the wiki itself under http://haskell.org/haskellwiki/User:Wolfgang_Jeltsch/Page_renaming. Maybe the rationale for page titles given there can server as a basis for a kind of standard for Haskell Wiki page names? I'm open to comments. Best wishes, Wolfgang

4 5

Question for the haskell implementors: Arrays, unsafePerformIO, runST
by John Meacham 22 Feb '06

22 Feb '06

So, I finally decided that jhc needs real arrays, but am running into an issue and was wondering how other compilers solve it, or if there is a general accepted way to do so. here is what I have so far > -- The opaque internal array type > data Array__ a > > -- the array transformer quasi-monad > newtype AT a = AT (Array__ -> Array__) > > seqAT__ :: AT a -> AT a -> AT a > seqAT__ (AT a1) (AT a2) = AT $ \a -> a2 (a1 a) > > doneAT__ :: AT a > doneAT__ = AT id > > newAT__ :: Int -> AT a -> Array__ a > newAT__ n (AT a1) = a1 (prim_newAT__ n) > > writeAT__ :: Int -> a -> AT a > writeAT__ i x = AT $ \a -> prim_writeAT__ i x a > > -- none of these routines have run-time checks > foreign import primitive "prim_newAT__" :: Int -> Array__ > -- performs *update-in-place* > foreign import primitive "prim_writeAT__" :: Int -> a -> Array__ -> Array__ > foreign import primitive "unsafeAt__" :: Array__ a -> Int -> a > > -- example use > newArray :: [a] -> Array__ a > newArray xs = newAT__ (length as) $ foldr assign doneAT (zip [0..] xs) where > assign (i,v) rs = writeAT__ i v `seqAT__` rs now, the problem occurs in newAT__ > newAT__ :: Int -> AT a -> Array__ a > newAT__ n (AT a1) = a1 (prim_newAT__ n) ^ this gets floated out as a CAF. it all seems good, but the call to (prim_newAT__ n) is a constant and hence gets pulled to the top level and all arrays end up being the same array! this is no good. I always knew in the back of my mind that 'unsafePerformIO' had the same problem, but sort of punted solving it since unsafePerformIO is not really used in any critical paths. However, it pretty much fundamentally breaks arrays! I imagine the same issue would arise with runST. so, any idea how to solve it? I could brute force it and make the compiler recognize calles to prim_newAT__ as special, but I really don't like that idea. it is hard to guarentee such things across all possible optimizations and I'd like a general solution rather than hardcoding a bunch of routines as special. So far, my best idea though I don't know if it will work is adding a primitive: > foreign import primitive "prim_newWorld__" :: forall a . a -> World__ which will throw away its argument and produce a World__. but since it is primtive, the compiler will assume the world it returns might depend on its argument. then I could do something like: > foreign import primitive "prim_newAT__" :: World__ -> Int -> Array__ > newAT__ :: Int -> AT a -> Array__ a > newAT__ n (AT a1) = a1 (prim_newAT__ (prim_newWorld__ a1) n) so the initial call to newAT__ now depends on the array transformer and can't be floated out as a CAF. I have reduced several magic primitives to just one, the world creation one. but I am still not sure how happy I am about it and wanted to know what other compilers did. John -- John Meacham - ⑆repetae.net⑆john⑈

6 9

IO == ST RealWorld
by Twan van Laarhoven 22 Feb '06

22 Feb '06

Is there any reason why IO should not be defined as: > type IO a = ST RealWorld a in implementations that support ST? This way IORef/STRef and IOArray/STArray can be merged. I know under the hood they already share code, but this way they can also share an interface. Twan

5 7

RE: [Haskell] page renaming on the Haskell Wiki
by Simon Peyton-Jones 21 Feb '06

21 Feb '06

Sounds good to me. I wonder whether the haskell home page http://haskell.org should say something like "This entire site is a Wiki, and is maintained by its users. To find out how to contribute, go here", where "here" gives guidance about logging in, and your page-naming guidelines? Simon | -----Original Message----- | From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Wolfgang | Jeltsch | Sent: 20 February 2006 23:51 | To: haskell(a)haskell.org | Subject: [Haskell] page renaming on the Haskell Wiki | | Hello, | | I just renamed several wiki pages. One reason for this renaming was the | inconsistent capitalization of page titles. The thread starting with | http://www.haskell.org//pipermail/haskell/2006-January/017485.html contains | some background of this renaming. | | I think that a consistent and sensible naming of pages of the Haskell Wiki is | very important. Since no further opinions were given concerning page naming | and late page renamings might be inconvenient for wiki users, I decided to do | this page renaming now, according to what was said in the above-mentioned | thread and to what I thought was sensible. | | I have put some further information about the renaming on the wiki itself | under http://haskell.org/haskellwiki/User:Wolfgang_Jeltsch/Page_renaming. | Maybe the rationale for page titles given there can server as a basis for a | kind of standard for Haskell Wiki page names? | | I'm open to comments. | | Best wishes, | Wolfgang | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

2 1

CFP Implementation of Functional Languages IFL 2006, Budapest, 4-6, Sep. 2006
by HORVATH Zoltan 21 Feb '06

21 Feb '06

FIRST ANNOUNCEMENT and CALL FOR PAPERS ************************************************************** * 18th International Workshop on * * Implementation and Application of Functional Languages * * IFL 2006 * * * * September 4-6, 2006 * * Budapest, Hungary * * http://plc.inf.elte.hu/ifl2006 * * * * Hosted by the * * Department of Programming Languages and Compilers of * * the Faculty of Informatics at Eotvos Lorand University * ************************************************************** --------- IMPORTANT DATES --------- * July 30th 2006 Registration deadline * Aug 4th 2006 Submission deadline for draft proceedings * Oct 24th 2006 Submission deadline for post-refereeing process * Dec 8th 2006 Notification of acceptance/rejection * Jan 31th 2007 Camera-ready papers ---------------------------------------------------------------- Scope and Topics The IFL workshops form a tradition that has lasted for nearly two decades. The aim of these workshops is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. They provide an open forum for researchers who wish to present and discuss new ideas and concepts, work in progress, preliminary results, etc. related primarily but not exclusively to the implementation and application of functional languages. Topics of interest include, but are not limited to: * language concepts * concurrent/parallel programming * type checking * concurrent/parallel program execution * compilation techniques * heap management * generic programming techniques * runtime profiling * (abstract) interpretation * performance measurements * automatic program generation * debugging and tracing * (abstract) machine architectures * verification * formal aspects * tools and programming techniques * array processing * demos of well working, useable tools and applications in functional languages Papers on applications demonstrating the suitability of novel ideas in any of the above areas and contributions on related theoretical work are also welcomed. The change of the workshop name adding the term "application", introduced in 2004, is to reflect the broader scope IFL has gained over recent years. Prospective authors are encouraged to submit papers to be published in the draft proceedings and to give presentations at the workshop. All contributions must be written in English, conform to the Springer-Verlag LNCS series format. Attendees at IFL'06 will have an opportunity to submit a revised version of their paper for post-workshop reviewing. Selected papers will be published by Springer Verlag in the well-known Lecture Notes in Computer Science (LNCS) Series, as has been a long-standing tradition for the IFL Workshops. Programme Committee Matthias Blume Toyota Technological Institute, Chicago, USA Zoran Budimac University of Novi Sad, Serbia Andrew Butterfield Trinity College Dublin, Ireland Ralf Hinze University of Bonn, Germany Zoltan Horvath Eotvos Lorand University, Budapest, Hungary (Chair) Tamas Kozsik Eotvos Lorand University, Budapest, Hungary Hans-Wolfgang Loidl Ludwig-Maximilians-University Munich, Germany Rita Loogen Philipps-University Marburg, Germany Frederic Loulergue University of Orleans, France Simon Marlow Microsoft Research, Cambridge, UK Marco Morazan Seton Hall University, New Jersey, USA Yolanda Ortega-Mallen University Complutense of Madrid, Spain Rinus Plasmeijer Radboud University Nijmegen, The Netherlands Jaroslav Poruban Technical University of Kosice, Slovakia Anna Soos Babes-Bolyai University, Cluj-Napoca, Romania Doaitse Swierstra Utrecht University, The Netherlands Peter Thiemann University of Freiburg, Germany German Vidal Technical University of Valencia, Spain Workshop Organization Zoltan Horvath, Viktoria Zsok Department of Programming Languages and Compilers Faculty of Informatics Eotvos Lorand University, Budapest, Hungary Further information Web-site: http://plc.inf.elte.hu/ifl2006/ E-mail: ifl2006(a)inf.elte.hu

1 0

Long live Edison
by Robert Dockins 21 Feb '06

21 Feb '06

Haskell community, As many of you are aware, Edison is a venerable library of data structures written in Haskell, primarily by Chris Okasaki. I have though for some time that it is a great shame that Edison has been languishing in disuse. It has always seemed to me to be high quality code which is fairly well designed. I believe that the barriers to its adoption have largely been barriers of ease-of-use and project management, and not necessarily problems with the design or implementation of the code itself. Although I am not a data structures expert, several weeks ago I decided that I would try my hand at maintaining Edison and see if I could overcome these barriers. Toward this end I have taken the most recent Edison codebase I could find (from Andrew Bromage's HFL project) and updated it in the following ways: -- Put source code under darcs version control -- Moved modules into a module hierarchy rooted at "Data.Edison" -- Moved to a cabal build system -- Integrated documentation into the source code using Haddock -- Tied together the various unit testing code into a comprehensive test suite -- Altered the API to bring it more closely in line with current practice (as exemplified by the Data.Set and Data.Map standard libraries) -- Added Data.Set and Data.Map as Edison "implementations" I now feel that it is ready for release, and have consequently prepared what I am calling "Edison 1.2, release candidate 1". Before I officially dub Edison 1.2, I would like to request some feedback from the community. In particular, I would very much like to hear people's opinions about the API: naming conventions, argument orders, etc. I have already made a number of changes to the Edison 1.1 API, and if people feel other changes are warranted, I'd like to go ahead and make them all at once. Particular points about which I would like to get feedback are: -- The Sequence 'rcons' method takes its arguments in the opposite order as the 'lcons' method (for mnemonic purposes). Should the arguments to 'rcons' be reversed? -- There are a few places where 'Data.Map' and/or 'Data.Set' have methods named similarly (but not identical) to the Edison API. By and large I have left those differences. Should I instead modify Edison to match those names? -- Are there additional methods that should be added to the API? -- Are there methods that should be removed? And perhaps most important, -- looking at this version of Edison, are there any things that would make you hesitant to use it? You can find Edison 1.2rc1 at the following places: Project homepage: http://www.eecs.tufts.edu/~rdocki01/edison.html API docs: http://www.eecs.tufts.edu/~rdocki01/docs/edison/index.html Darcs repository: http://www.eecs.tufts.edu/~rdocki01/edison/ Source tarball: http://www.eecs.tufts.edu/~rdocki01/projects/edison-1.2rc1-source.tar.gz Many thanks, Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG

7 12

Re: Long live Edison
by Paul Johnson 21 Feb '06

21 Feb '06

Robert Dockins <robdockins(a)fastmail.fm> wrote: > Consistency. Almost all the other API functions take the data > structure argument last. This seems to be a kind of de facto > standard and deviations from it are likely to cause confusion. I'd always assumed that the reason that data structure functions take the data structure last is because of the commonest case of partial application, where you want a function of the form Struct -> Struct. For instance suppose you had: type MyState = State (Sequence Int) myStateFunc1:: MyState () myStateFunc1 = do x <- someThing modify $ lcons x Now you want the equivalent for rcons: myStateFunc2 :: MyState () myStateFunc2 = do x <- someThing modify $ (flip rcons) x The extra "flip" is confusing and distracting. It gets worse for functions of more than two arguments: you wind up needing a lambda. (BTW I haven't checked the code against the reference manual, so sorry if I've got it a bit wrong). Paul.

1 0

problems with Haskell 98's record system
by Wolfgang Jeltsch 21 Feb '06

21 Feb '06

Hello, is there any web resource which describes the problems with Haskell 98's record system in a compact form? The Curry people are about to adopt (parts of) this module system and I warned them that many consider it flawed. Alas, I'm not an expert in this area, so I cannot give much good arguments in this respect. Therefore, I would be happy if someone could point me to a resource describing the problems or even telling the Curry people about the problems on the Curry Mailing List [1]. Best wishes, Wolfgang [1] http://www.informatik.uni-kiel.de/~curry/mailinglist.html

4 5

Haddock ignores fixity declarations?
by Benjamin Franksen 20 Feb '06

20 Feb '06

Hello, I just wanted to check the precedence of the (.) operator from Prelude (http://www.haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html) and noticed with shock ;) that neither precedence levels nor fixity are documented. Is this a known limitation of haddock? How hard would it be to add this? Ben

2 1