- Haskell-Cafe - Haskell.org

Haddock anchors
by Mark Lentczner 16 Jul '10

16 Jul '10

I've been re-working on the Haddock HTML back end to get it to generate "semantic markup" and legal XHTML. One of the problems is that the anchors that Haddock currently generate aren't always legal in HTML, XHTML, or XML. I'd like to fix the anchor generation so that they are. If I do, then links between old and new generated Haddock pages will land on the right page, but won't always get to the right spot on the page. Will this be a problem for anyone? On one's own machine, I imagine we can come up with a simple script that will just rebuild all the Haddock docs and that will take care of it. What about on Hackage? Eventually, as packages update, the issue will diminish. Can we just bulk re-build the haddock for the latest rev of all packages? - Mark Mark Lentczner http://www.ozonehouse.com/mark/ IRC: mtnviewmark

3 2

cryptohash and an incremental API
by Thomas M. DuBuisson 15 Jul '10

15 Jul '10

Vincent, Due to spam-like comments on -cafe I hadn't been subscribed for a while and missed your cryptohash discussion! Particularly: > The main reason for this library is the lack of incremental api exposed by > current digest libraries, and filling the void about some missing digest > algorithms; Also the speed comes as a nice bonus. I've been working on a new crypto library specifically to provide a unified API for packages implementing cryptographic algorithms. You can see the discussions on libraries(a)haskell.org [1] [2]. Please feel free to take a look, comment, contribute, and hopefully move to the interface. I should be finishing up BlockCipher modes and adding hash tests soon. Cheers, Thomas [1] http://www.haskell.org/pipermail/libraries/2010-May/013688.html [2] http://www.haskell.org/pipermail/libraries/2010-June/013782.html

3 3

Expression dye
by Andrew Coppin 15 Jul '10

15 Jul '10

I'm trying to write a function that builds a series of results in a very complicated way. Eventually I ended up writing things like > newtype Dye = Dye String deriving (Eq, Show) > > instance Num Dye where > (Dye x) + (Dye y) = Dye (x ++ " + " ++ y) > (Dye x) - (Dye y) = Dye (x ++ " - " ++ y) > (Dye x) * (Dye y) = Dye (x ++ " * " ++ y) > abs (Dye x) = Dye ("abs " ++ x) and so on. In this way, you can do something like > sum [Dye "x", Dye "y", Dye"z"] and get "0 + x + y + z" as the result. (In reality you probably want to keep track of bracketing and so forth.) In this way, you can take functions that accept any Num instance and feed the "dye" through them to see what they're actually computing on a given run. Has anybody ever put anything like this on Hackage? I'd prefer to not invent this stuff if somebody has already done it... (The small problem with the approach above, of course, is that as soon as the function wants to do comparisons or take flow control decisions, you've got trouble. It's not impossible to solve, but it *is* a lot of work...)

4 8

IFL 2010: 3rd CFP and 1st Call for Participation
by Don Stewart 14 Jul '10

14 Jul '10

3RD CALL FOR PAPERS and 1ST CALL FOR PARTICIPATION 22nd Symposium on Implementation and Application of Functional Languages (IFL 2010) September 1-3, 2010 Utrecht University Alphen aan den Rijn, The Netherlands http://www.cs.uu.nl/ifl2010 ******************************************************************************************* ** Submission and Registration are now both OPEN ** ** If you intend to participate in IFL 2010, help us by registering as soon as possible. ** ** ** ** Submission closes July 25, Registration closes August 1 ** ******************************************************************************************* After a first successful visit to the USA, the Symposium on Implementation and Application of Functional Languages returns to Europe for its 22nd edition. The hosting institution is Utrecht University in the Netherlands, although the conference itself will take place in the ornithological theme park Avifauna in Alphen aan den Rijn, situated conveniently close to Schiphol (Amsterdam Airport). The symposium dates are September 1-3, 2010. The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2010 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. Following the IFL tradition, IFL 2010 will use a post-symposium review process to produce formal proceedings which will be published by Springer Verlag in the Lecture Notes in Computer Science series. All participants in IFL 2010 are invited to submit either a draft paper or an extended abstract describing work to be presented at the symposium. At no time may work submitted to IFL be simultaneously submitted to other venues. Here we follow the ACM Sigplan republication policy as defined on http://www.sigplan.org/republicationpolicy.htm. The submissions will be screened by the program committee chair to make sure they are within the scope of IFL, and will appear in the draft proceedings distributed at the symposium. Submissions appearing in the draft proceedings are not peer-reviewed publications. After the symposium, authors will be given the opportunity to incorporate the feedback from discussions at the symposium and will be invited to submit a revised full article for the formal review process. These revised submissions will be reviewed by the program committee using prevailing academic standards to select the best articles, which will appear in the formal proceedings. INVITED SPEAKER Johan Nordlander of Lulea University, the designer and developer of the Timber language, is the invited speaker at IFL 2010. Timber is a functional programming language that draws some of its concepts from object-oriented programming, and has built-in facilities for concurrent execution. The language is specifically targeted at implementing real-time embedded systems. TOPICS IFL welcomes submissions describing practical and theoretical work as well as submissions describing applications and tools. If you are not sure that your work is appropriate for IFL 2010, please contact the PC chair at jur(a)cs.uu.nl. Topics of interest include, but are not limited to: language concepts type checking contracts compilation techniques staged compilation runtime function specialization runtime code generation partial evaluation (abstract) interpretation generic programming techniques automatic program generation array processing concurrent/parallel programming concurrent/parallel program execution functional programming and embedded systems functional programming and web applications functional programming and security novel memory management techniques runtime profiling and performance measurements debugging and tracing virtual/abstract machine architectures validation and verification of functional programs tools and programming techniques industrial applications of functional programming PAPER SUBMISSIONS Prospective authors are encouraged to submit papers or extended abstracts to be published in the draft proceedings and to present them at the symposium. All contributions must be written in English, conform to the Springer-Verlag LNCS series format and not exceed 16 pages. The draft proceedings will appear as a technical report of the Department of Computer Science of Utrecht University. SPONSORS IFL 2010 is sponsored by Microsoft Research. As a result we can offer decreased participation fees for Master students and PhD students who plan to attend or present at IFL 2010. PETER LANDIN PRIZE The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honored article is selected by the program committee based on the submissions received for the formal review process. The prize carries a cash award equivalent to 150 Euros. IMPORTANT DATES Draft proceedings submission deadline July 25, 2010 Registration deadline August 1, 2010 IFL 2010 Symposium September 1-3, 2010 Submission for review process deadline October 25, 2010 Notification Accept/Reject December 22, 2010 Camera ready version February 17, 2011 PROGRAM COMMITTEE Jost Berthold University of Copenhagen (DIKU), Denmark Olaf Chitil University of Kent, UK John Clements California Polytechnic State University, USA Matthew Fluet Rochester Institute of Technology, USA Andy Gill Kansas University, USA Jurriaan Hage (Chair) University of Utrecht, Netherlands Bastiaan Heeren Open University, Netherlands Ralf Hinze University of Oxford, UK John Hughes Chalmers University of Technology, Sweden Yukiyoshi Kameyama University of Tsukuba, Japan Gabriele Keller University of New South Wales, Australia Pieter Koopman Radboud University Nijmegen, Netherlands Luc Maranget INRIA, France Simon Marlow Microsoft Research, UK Marco T. Morazán Seton Hall University, USA Rex Page University of Oklahoma, USA Ricardo Peña Universidad Complutense de Madrid, Spain Sven-Bodo Scholz University of Hertfordshire, UK Tom Schrijvers Catholic University of Leuven, Belgium Don Stewart Galois, USA Wouter Swierstra Vector Fabrics, Netherlands Don Syme Microsoft, UK Peter Thiemann University of Freiburg, Germany Phil Trinder Heriott-Watt University, Scotland Janis Voigtländer University of Bonn, Germany Viktória Zsók Eötvös Loránd University, Hungary

1 0

Call for Copy: Monad.Reader Issue 17
by Brent Yorgey 14 Jul '10

14 Jul '10

Whether you're an established academic or have only just started learning Haskell, if you have something to say, please consider writing an article for The Monad.Reader! The submission deadline for Issue 17 will be: **Friday, October 1, 2010** The Monad.Reader ~~~~~~~~~~~~~~~~ The Monad.Reader is a electronic magazine about all things Haskell. It is less formal than journal, but somehow more enduring than a wiki page. There have been a wide variety of articles: exciting code fragments, intriguing puzzles, book reviews, tutorials, and even half-baked research ideas. Submission Details ~~~~~~~~~~~~~~~~~~ Get in touch with me if you intend to submit something -- the sooner you let me know what you're up to, the better. Please submit articles for the next issue to me by e-mail (byorgey at cis.upenn.edu) Articles should be written according to the guidelines available from http://themonadreader.wordpress.com/contributing/ Please submit your article in PDF, together with any source files you used. The sources will be released together with the magazine under a BSD license. If you would like to submit an article, but have trouble with LaTeX please let me know and we'll work something out.

1 0

Comments on Haskell 2010 Report
by Alex Stangl 14 Jul '10

14 Jul '10

based upon final version PDF created 7/6/2010 11:44:27 1. I.E. and e.g. should be followed by commas -- unless UK usage differs from US standards. (Page 3 and elsewhere, although FFI chapter seems to have the commas.) Also, inconsistent mix of British and American usage throughout (-ize and -ise, flavour, behaviour, behavior, analyse, color, colour, finaliser, finalizer, etc.) 2. Inconsistent spelling (lowercase/uppercase in section 1.4; lower-case/upper-case in section 2.4) 3. In section 3.11, boolean misspelled boolen. 4. LaTeX macros involving @ showing up in text. See sects 3.12, 6.4.2, 11.1, and in Chapter 9. 5. In section 3.15.2, reference to third bullet seems like it should be fourth bullet. 6. In section 3.17.2, the example that is supposed to return [undefined,undefined,undefined] seems like it really ought to return undefined, although I can see in the description above for ~apat matching where the other interpretation would hold. I actually tried this in GHC 10.4.2, binding the result to a variable and then applying the function length to it, and it comes back with undefined, whereas performing "length [undefined,undefined,undefined]" returns 3. So it appears that in this case, at least GHC 10.4.2 is returning undefined rather than [undefined,undefined,undefined]. 7. In section 6.3.4, "[LT..]" needs whitespace in the middle to parse correctly. 8. I'm curious about last part of section 6.4.3 that says 0**y is undefined. It seems to work reasonably under GHC, returning 0 in every case except 0**0, which returns 1 (the ^0 == 1 rule taking precedence, apparently.) Saying 0**0 is undefined seems reasonable, but why 0**y? 9. In section 6.4.6, statement about b^(d-1) <= m < b^d doesn't seem to hold when m < 0. Should it be |m| in the equation, rather than m? 10. Section 7.1 uses "function" in places where it ought to use "action". It seems more correct to describe print as returning an action that outputs a value. Most of the "Input Functions" (e.g., getChar, getLine, getContents, readLn) should be described as actions, not functions. It switches to using the term "operation", which seems better, but then reverts back to "function". 11. In section 8.4, variable misspelled varibale. 12. In section 8.5.1, in "we require that chname ends on .h", "on" should be "in". 13. Also in section 8.5.1, dependent misspelled "dependant". 14. Last paragraph of section 8.5,1 has extra "a" -- "... defined to a accept a ...". Following sentence has a semicolon where it should have a comma. 15. In section 10.3, "(i.e. the programmer..." has no closing paren. 16. In section 10.4, "... other lines are comment", "comments" sounds better. This occurs twice. 17. Also in section 10.6, anything misspelled "anyything". 18. In Chapter 15, it would be more clear to describe "bit i" as producing a value with the ith bit set, and all other bits clear. 19. In section 20.3.1, caveats about finiteness of lists similar to ones given for "and" and "or" could also apply to "any" and "all". Ditto for elem, notElem, etc. Maybe a single paragraph could summarize this short-circuiting behavior for all of them. 20. In heading for 20.9.2, quotes around "Set" are not balanced. Both are closing quotes. Ditto for 20.10.1, 20.10.2. 21. In section 29.1.1, "finaliser" and "finalizer" used in same paragraph. 22. In section 38.2, first occurrence of 'dual' has mismatched quotes. 23. In section 41.1, quotes around "perform" are mismatched. Word "function" is mildly misused again here. 24. In section 41.3.1, it would be nice to document what happens if act terminates abnormally, and then a secondary exception occurs during the closing of the handle. Oftentimes systems lose the primary exception and propagate out the secondary exception, whereas in reality we may be more interested in the original primary exception. 25. In section 41.4.4, bullet before isPermissionError isn't rendered correctly. Alex

15 20

Applying a value to a function generically
by Arnaud Bailly 14 Jul '10

14 Jul '10

Hello, I would like to construct a collection of function-like objects on which I could apply some value, in a typesafe and clean way. Let's say I have something like this: > data Fun = forall a b . F (a -> b) > type Callables = Map String Fun I would like to be able to write: > invoke :: Callables -> a -> String -> b > invoke m d k = case lookup k m of > Just (F f) -> f d > Nothing -> error $ "unable to find function for key " ++ k which of course does not compile nor even make sense. I suspect I need to have more information in Fun to be able to apply functions correctly, but don't know where to look at. I read recently an article about implicit configurations that used some type wizardry to ensure correct and typesafe use of external data and sounded pretty cool, (http://www.cs.rutgers.edu/~ccshan/prepose/prepose.pdf) but I suspect this is 1) too complex for me an 2) overkill for my problem. Could someone point me in the right direction ? Thanks in advance Arnaud

3 2

Collecting MonadError errors generically
by oleg＠okmij.org 14 Jul '10

14 Jul '10

Leon Grynszpan wrote: > What I want, instead, is to run a whole bunch of > computations that may throw errors. If there are any errors, I want to > collect them all into one big master error. If not, I want a list of > results. Here's an example of usage: > > couldThrowError :: (Error e, MonadError e m) => t1 -> m t2 > getParams :: (Error e, MonadError e m) => [t1] --> m [t2] > getParams = groupErrors . map couldThrowError > > I found it pretty easy to implement groupErrors for Either String: > ... > The problem, though, is that running this function now causes type > inference to provide "Either String" as my MonadError implementation... > It would be nice if I could stay generic. You might find the following two functions useful: > reify :: (Error e, MonadError e m) => m a -> m (Either e a) > reify m = (m >>= return . Right) `catchError` (return . Left) > > -- Not needed here, but very nice to have anyway > reflect :: (Error e, MonadError e m) => m (Either e a) -> m a > reflect m = m >>= either throwError return Then groupErrors can be written almost the same way you wrote for the Either String monad -- but now generically > groupErrors :: (Monoid e, Error e, MonadError e m) => [m a] -> m [a] > groupErrors lst = mapM reify lst >>= \lst -> > case partitionEithers lst of > ([],xs) -> return xs > (errs,_) -> throwError (mconcat errs) If you don't like the Monoid constraint, this is fine. But you have to provide then some other way to group errors. For example, you could use the new extensible exceptions. Here is the rest of the code: > couldThrowError :: (MonadError String m) => String -> m Int > couldThrowError s = case reads s of > [(n,"")] -> return n > _ -> throwError $ "parse error: " ++ s ++ "\n" > > getParams :: (Monoid e, Error e, MonadError e m) => > (t1 -> m t2) -> [t1] -> m [t2] > getParams f = groupErrors . map f > > test :: Either String [Int] > test = getParams couldThrowError ["1","2","a","b"] If you wish to know more about reify and reflect, a good paper to start is the following. Section 1.2 talks directly about exception monads. @InProceedings{ filinski-representing, author = "Andrzej Filinski", title = "Representing Monads", pages = "446--457", crossref = "popl1994", url = "http://www.diku.dk/~andrzej/papers/RM-abstract.html http://www.diku.dk/~andrzej/papers/RM.dvi http://www.diku.dk/~andrzej/papers/RM.ps.gz", abstract = "We show that any monad whose unit and extension operations are expressible as purely functional terms can be embedded in a call-by-value language with ``composable continuations''. As part of the development, we extend Meyer and Wand's characterization of the relationship between continuation-passing and direct style to one for continuation-passing vs.~general ``monadic'' style. We further show that the composable-continuations construct can itself be represented using ordinary, non-composable first-class continuations and a single piece of state. Thus, in the presence of two specific computational effects---storage and escapes---\emph{any} expressible monadic structure (e.g., nondeterminism as represented by the list monad) can be added as a purely definitional extension, without requiring a reinterpretation of the whole language. The paper includes an implementation of the construction (in Standard ML with some New Jersey extensions) and several examples." } There is a follow-up: @InProceedings{ filinski-layered, author = "Andrzej Filinski", title = "Representing Layered Monads", pages = "175--188", crossref = "popl1999", url = "http://www.diku.dk/~andrzej/papers/RLM-abstract.html http://www.diku.dk/~andrzej/papers/RLM.dvi http://www.diku.dk/~andrzej/papers/RLM.ps.gz", } The term reification has been introduced 26 years ago: @InProceedings{ friedman-reification, author = {Daniel P. Friedman and Mitchell Wand}, title = {Reification: Reflection without Metaphysics}, pages = {348--355}, crossref = "lfp1984", abstract = {We consider how the data structures of an interpreter may be made available to the program it is running, and how the program may alter its interpreter's structures. We refer to these processes as reification and reflection. We show how these processes may be considered as an extension of the fexpr concept in which not only the form and the environment, but also the continuation, are made available to the body of the procedure. We show how such a construct can be used to effectively add an unlimited variety of ``special forms'' to a very small base language. We consider some trade-offs in how interpreter objects are reified. Our version of this construct is similar to one in 3-Lisp [Smith 82, 84], but is independent of the rest of 3-Lisp. In particular, it does not rely on the notion of a tower of interpreters.} }

1 0

Collecting MonadError errors generically
by Leon Grynszpan 13 Jul '10

13 Jul '10

Hello, This is my first post to the Haskell Café, and I'm hoping the issue I'm tackling here isn't one that's been thoroughly explored elsewhere. If that's the case, I'll apologize in advance for my insufficient google chops. Otherwise, here goes... I do a lot of work within the error monad. Having read Eric Kidd's blog on error reporting in Haskell (http://www.randomhacks.net/articles/2007/03/10/haskell-8-ways-to-report-err…) I'm always a bit paranoid about dealing with errors in the most generic, flexible way possible. As a result, a lot of the functions I use that could result in errors have signatures along these lines: couldThrowError :: (Error e, MonadError e m) => t1 -> t2 -> m t3 The way I figure it, this means that I can use these functions within any particular MonadError, which keeps me happy if I decide to change implementations at any particular point during development. Usually, I use these couldThrowError functions in a standard do block. Something along the lines of: couldThrowError :: (Error e, MonadError e m) => t1 -> t2 -> m t3 couldThrowError = do x <- processWithPossibleError t1 y <- processWithPossibleError t2 ... return (z :: t3) Things stay generic at this level. I can still choose any MonadError implementation I want, and if any of the computations in the do block throws an Error, the whole function short-circuits. Often enough, however, I don't want this kind of short-circuiting behavior. What I want, instead, is to run a whole bunch of computations that may throw errors. If there are any errors, I want to collect them all into one big master error. If not, I want a list of results. Here's an example of usage: couldThrowError :: (Error e, MonadError e m) => t1 -> m t2 getParams :: (Error e, MonadError e m) => [t1] --> m [t2] getParams = groupErrors . map couldThrowError I found it pretty easy to implement groupErrors for Either String: groupErrors :: (Error e, MonadError e m) => [Either String a] -> m [a] groupErrors eithers = case partitionEithers eithers of ([], xs) -> return xs (es, _) -> strError $ unlines es The problem, though, is that running this function now causes type inference to provide "Either String" as my MonadError implementation. If any of the potential error sources are dealing with a different concrete implementation, I'm stuck! It would be nice if I could stay generic. I made an effort at this that you can see below, but it strikes me as very awkward. collectErrors :: (Monoid e, Error e, MonadError e m) => m a -> m [a] -> m [a] collectErrors m1 m2 = do m1r <- (m1 `catchError` (\e1 -> (m2 `catchError` (\e2 -> throwError $ mappend e1 e2)) >> throwError e1)) m2r <- m2 return $ m1r : m2r groupErrors' :: (Monoid e, Error e, MonadError e m) => [m a] -> m [a] groupErrors' = foldr collectErrors (return []) As you can see, I now require an error type that implements monoid. An example I've tested is: newtype ErrorString = ES String deriving (Read, Show, Eq, Ord, Error) instance Monoid ErrorString where mempty = ES "" mappend (ES s1) (ES s2) = ES $ s1 `mappend` "\n" `mappend` s2 This seems to work, but something strikes me as being very hackish here. Maybe it's just that collectErrors looks very ugly, and in Haskell my intuition tells me that what looks ugly on the surface is often ugly down below. I suspect that I might really not be approaching this problem the right way, but after a lot of time spent wrestling with it, I'm eager to read your suggestions. Is there a better way to do groupErrors, or should I be looking at an entirely different philosophy? Thanks, Grynszpan

2 1

library for objective-j?
by Günther Schmidt 13 Jul '10

13 Jul '10

Hi all, is there a haskell library for generating Objective-J? Günther

2 3