- Haskell-Cafe - Haskell.org

Mascot Poll Results
by heathmatlock 28 Nov '11

28 Nov '11

Haskellers.com poll: Yes 52 votes (50%), 22 verified votes (53%) No 51 votes (49%), 19 verified votes (46%) Email: Yes 14 (64%) No 8 (36%) Seems a bit divided. -- Heath Matlock +1 256 274 4225

5 7

Current Haskell report URL
by Tom Murphy 28 Nov '11

28 Nov '11

Is there a reason that the Haskell 2010 report is in a subdirectory of haskell.org/onlinereport (which currently points to the Haskell98 standard)? http://www.haskell.org/onlinereport/ -- Haskell98 http://www.haskell.org/onlinereport/haskell2010/ -- Haskell2010 If it's for historical reasons - because books etc. use this URL for the 98 standard, then I'd highly recommend making a new directory called "currentreport" or something (if there isn't one already). The current impression that we give is that Haskell98 is the current standard, and Haskell2010 isn't compiler-supported. amindfv / Tom

4 3

ANNOUNCE: clientsession-0.7.3.4 (performance enhancement)
by Michael Snoyman 27 Nov '11

27 Nov '11

Hi all, tl;dr: randomIV is now much faster, API is the same, upgrade ASAP to avoid painful slowdowns. Version 0.7 of clientsession brought with it a much enhanced encryption and hashing algorithm, courtesy of Felipe Lessa. Beginning with this version, you now need to provide an Initialization Vector (IV) for encrypting cookies, and these IVs need to be randomly generated. To start off with, we simply used the getIVIO[1] function to generate these values. Recently, some Yesod users reported that version 0.9 of Yesod no longer lived up to previous benchmarks. After some research, I determined that the slowdown came from the call to randomIV in clientsession. The initial fix was simply to disable this call when it wasn't used, but it was still a significant slowdown for most users of Yesod. Over the past few days, Felipe and I put together a significantly more efficient version of randomIV. getIVIO simply opens up /dev/urandom on each request, which involves I/O. As a result, the average run time of the function in our testing was 1.686ms. Instead, our new code initializes with a call to /dev/urandom for the base randomness. It then uses AES encryption to work as a cryptographic random number generator for generating successive IVs. Additionally, every 1000 calls (we'll probably change that number over time), it spawns a new thread to reseed the generator from /dev/urandom again. The result is a function that takes 7.144764 us, aka 236 times faster. Thanks for the initial reporters who commented on the slowdown in Yesod. If you install the newest clientsession and rerun the benchmarks, you should see *significantly* better results. Michael [1] http://hackage.haskell.org/packages/archive/crypto-api/0.8/doc/html/Crypto-…

2 1

XML modification
by Andrew Coppin 25 Nov '11

25 Nov '11

Hi guys. I've got a folder with about 80 XML files in it. I want to take each file and make specific modifications to it. (Mostly just finding specific attributes and changing their values to make then all consistent.) Now I guess it wouldn't take me /that/ long to code something from scratch. But does anybody have a better suggestion for tools or libraries that might be useful?

2 4

blaze-textual-native and aeson-native are being deprecated
by Michael Snoyman 25 Nov '11

25 Nov '11

Hi all, In the last Yesod release, we created two new packages: blaze-textual-native and aeson-native. These were direct forks of their source packages, with just two changes: blaze-textual-native did not include a double-conversion dependency, and aeson-native depended on blaze-textual-native instead of blaze-textual. The reason for all this is that there is a GHC bug which prevents C++ code from working correctly with GHCi and Template Haskell[1]. Bryan recently released a new version of blaze-textual which no longer uses double-conversion by default (it's still available with compile-time flags if you want the extra speed and don't need TH/GHCi), and as a result, we are very happy to be deprecating the native siblings. Fortunately, there are not that many packages on Hackage using these libraries; in fact, the only packages for which I'm not a maintainer are dingo-core, dingo-widgets and hledger-web. However, since these are Yesod dependencies, I'm guessing many Yesod users reference aeson-native in their site cabal files. Technically speaking, switching from aeson-native to aeson in a library should constitute a major version bump. However, in this case, I think we want these deprecated packages to die as quickly as possible. So my plan is to switch all of my packages from using aeson-native to aeson some time next week. The result will likely be broken builds for some people; all you'll need to do is edit your cabal file and replace aeson-native with aeson (likewise for blaze-textual). Are there any objections to this course of action, or better ideas on how to handle the situation? Michael [1] Please don't ask me for details, I don't know them. And for all I know, the bug has already be fixed in newer GHCs.

1 0

FGL custom node identification (Label -> Node lookup)
by Thomas DuBuisson 24 Nov '11

24 Nov '11

All, The containers library has a somewhat primitive but certainly useful Data.Graph library. Building a graph with this library simultaneously results in the lookup functions: m1 :: Vertex -> (node, key, [key]) m2 :: key -> Maybe Vertex (where 'key' is like FGL's 'label' but is assumed to be unique) This is exactly what I wanted when building and analyzing a call graph in FGL. To that end, I started making a graph type that tracked label to Node mappings, wrapping Data.Graph.Inductive.Gr, and assuming the labels are all unique. The classes for such a graph actually aren't possible. The ability to build a mapping from a node's 'label' to the 'Node' requires extra context (ex: Hashable, Ord, or at least Eq), but such context can not be provided due to the typeclass construction. Is there any chance we can change the Graph and DiaGraph classes to expose the type variables 'a' and 'b'? class Graph gr a b where ... class (Graph gr) => DynGraph gr a b where ... This would allow instances to provide the needed context: instance (Hashable a, Hashable b) => Graph UniqueLabel a b where ... buildGraph = ... some use of containers libraries that require context ... ... lookupNode :: Hashable a => UniqueLabel a b -> a -> Node -- etc Cheers, Thomas P.S. Please do educate me if I simply missed or misunderstood some feature of FGL.

2 4

ANN: OpenCL 1.0.2.2 package
by Luis Cabellos 24 Nov '11

24 Nov '11

Hello, all. I update the OpenCL package with a better error handle using Control.Exception. Thanks all comments in the previous version, and issues in github. # Where to get it * Hackage page (http://hackage.haskell.org/package/OpenCL) * Repository (https://github.com/zhensydow/opencl) * Bugs (https://github.com/zhensydow/opencl/issues) # Changes: * Changed LICENSE to BSD3 * Changed error from 'IO (Either CLError a)' to IO a + CLError exceptions * Added creation of programs using precompiled binaries (added example program) * Better documentation. Thanks, Luis Cabellos

1 1

Re: [Haskell-cafe] type level strings?
by oleg＠okmij.org 24 Nov '11

24 Nov '11

Evan Laforge has defined > data Thing { > thing_id :: ThingId > , thing_stuff :: Stuff > } > newtype ThingId = ThingId String and wishes to statically preclude binary operations with things that have different ThingIds. However, Things and their Ids can be loaded from files and so cannot be known to the compiler. He wished for type-level strings -- which is what the enclosed code gives. When we've got two Things loaded from two different files we must do a run-time check to see if these two things have in fact the same ThingId. That is inevitable. The question is how frequently do we have to make such a test? One approach is to do such a ruin-time test on each binary operation on things. The original Thing above was of that approach: > instance Monoid Thing where > mappend (Thing id1 stuff1) (Thing id2 stuff2) > | id1 /= id2 = error "..." > | otherwise = Thing id1 (stuff1 `mappend` stuff2) Every time we mappend things, we must check their ids. It has been suggested to use existentials. We get the the following code: > maybeAppend :: Exists Thing -> Exists Thing -> Maybe (Exists Thing) > maybeAppend (Exists t1) (Exists t2) = > case thing_id t1 `equal` thing_id t2 of > Just Refl -> Just $ Exists (t1 `mappend` t2) > Nothing -> Nothing How different is this from the original mappend? Every time we wish to mappend two things, we have to do the run-time test of their ids! We added phantom times, existentials, GADTs -- and got nothing in return. No improvement to the original code, and no static guarantees. When we have to mappend things several times, it seems optimal to do the run-time ID check only once (we have to do that check anyway) and then mappend the results without any checks, and with full static assurance that only Identical things are mappended. The enclosed code implements that approach. The instance for Monoid makes patent only things with the same id may be mappended. Moreover, there is no run-time id check, and we do not have to think up the id to give to mempty. The test does read two things from a `file' (a string) and does several operations on them. The run-time test is done only once. The ideas of the code are described in the papers with Chung-chieh Shan on lightweight static capabilities and implicit configurations. {-# LANGUAGE RankNTypes, ScopedTypeVariables #-} module Thing where import Data.Monoid import Data.Char -- The data constructor Thing should not be exported newtype Thing id = Thing{ thingStuff :: Stuff } type Stuff = [Int] -- or any monoid class IDeal id where get_id :: id -> String -- The user should use make_thing make_thing :: IDeal id => id -> Stuff -> Thing id make_thing _ t = Thing t -- It is statically assured that only things with the same id -- may be mappended. Moreover, there is no run-time id check -- And we do not have to think up the id to give to mempty instance Monoid (Thing id) where Thing t1 `mappend` Thing t2 = Thing (t1 `mappend` t2) mempty = Thing mempty instance IDeal id => Show (Thing id) where show (Thing t) = show $ (get_id (undefined::id),t) -- A statically-known Id (just in case) data Id1 = Id1 instance IDeal Id1 where get_id _ = "Id1" -- Reading a thing from a file (or at least, a string) data DynId id = DynId instance Nat id => IDeal (DynId id) where get_id _ = int_to_str $ nat (undefined::id) read_thing :: String -> (forall id. IDeal id => Thing id -> w) -> w read_thing str k = reify_ideal i (\iD -> k (make_thing iD t)) where (i,t) = read str -- Run-time equality check -- If id and id' are the same, cast the second to the same id eqid_check :: forall id id'. (IDeal id, IDeal id') => Thing id -> Thing id' -> Maybe (Thing id) eqid_check _ (Thing t) | get_id (undefined::id) == get_id (undefined::id') = Just (Thing t) eqid_check _ _ = Nothing test file1 file2 = read_thing file1 (\t1 -> read_thing file2 (\t2 -> do_things t1 t2)) where -- A run-time test is inevitable, but it is done only once do_things t1 t2 | Just t2' <- eqid_check t1 t2 = do_things' t1 t2' do_things _ _ = error "bad things" -- Now it is assured we have the same id -- we can do things many times do_things' :: IDeal id => Thing id -> Thing id -> String do_things' t1 t2 = show $ mempty `mappend` t1 `mappend` t2 `mappend` t2 `mappend` t1 t1 = test "(\"id1\",[1,2])" "(\"id1\",[3,4])" -- "(\"id1\",[1,2,3,4,3,4,1,2])" t2 = test "(\"id1\",[1,2])" "(\"id2\",[3,4])" -- "*** Exception: bad things -- Reifying strings to types -- They say String kinds are already in a GHC branch. -- Edward Kmett maintains a Hackage package for these sort of things -- Assume ASCII for simplicity str_to_int :: String -> Integer str_to_int "" = 0 str_to_int (c:t) = fromIntegral (ord c) + 128 * str_to_int t int_to_str :: Integer -> String int_to_str = loop "" where loop acc 0 = reverse acc loop acc n | (n',c) <- quotRem n 128 = loop (chr (fromIntegral c) : acc) n' data Z = Z data S a = S a data T a = T a class Nat a where nat :: a -> Integer instance Nat Z where nat _ = 0 instance Nat a => Nat (S a) where nat _ = 1 + nat (undefined::a) instance Nat a => Nat (T a) where nat _ = 2 * nat (undefined::a) reify_integer :: Integer -> (forall x. Nat x => x -> w ) -> w reify_integer 0 k = k Z reify_integer n k | even n = reify_integer (n `div` 2) (\x -> k (T x)) reify_integer n k = reify_integer (n-1) (\x -> k (S x)) reify_ideal :: String -> (forall x. IDeal x => x -> w) -> w reify_ideal str k = reify_integer (str_to_int str) (k . dynid) where dynid :: x -> DynId x dynid = undefined tr1 = reify_integer 10 nat tr2 = int_to_str $ reify_integer (str_to_int "id1") nat

1 0

Munich Haskell Meeting
by Heinrich Hördegen 24 Nov '11

24 Nov '11

Dear all, next week on Tuesday, 29 November, our monthly Haskell get-together will be held at Cafe Puck in Munich. Starting time is 19h30. Please feel free to join us. We are always happy to see someone new. There have been lots of people last time and we did not have enough tables. Therefore, if you plan to join us, please go to this page and hit the button. This well help to reserve places: http://www.haskell-munich.de/dates There is also the question, what to do in December. Any suggestions? We hope to see you soon, Heinrich -- -- hoerdegen(a)funktional.info www.funktional.info --

1 0

Last CFP: 12th International Workshop on Language Descriptions, Tools, and Applications (LDTA 2012)
by Emilie Balland 24 Nov '11

24 Nov '11

LDTA 2012 Call for Papers 12th International Workshop on Language Descriptions, Tools, and Applications www.ldta.info Tallinn, Estonia March 31 & April 1, 2012 an ETAPS workshop LDTA is an application and tool-oriented workshop focused on grammarware - software based on grammars in some form. Grammarware applications are typically language processing applications and traditional examples include parsers, program analyzers, optimizers and translators. A primary focus of LDTA is grammarware that is generated from high-level grammar-centric specifications and thus submissions on parser generation, attribute grammar systems, term/graph rewriting systems, and other grammar-related meta-programming tools, techniques, and formalisms are encouraged. LDTA is also a forum in which theory is put to the test, in many cases on real-world software engineering challenges. Thus, LDTA also solicits papers on the application of grammarware to areas including, but not limited to, the following: - program analysis, transformation, generation, and verification, - implementation of Domain-Specific Languages, - reverse engineering and re-engineering, - refactoring and other source-to-source transformations, - language definition and language prototyping, and - debugging, profiling, IDE support, and testing. Note that LDTA is a well-established workshop similar to other conferences on (programming) language engineering topics such as SLE and GPCE, but is solely focused on grammarware. Paper Submission ------------------------- LDTA solicits papers in the following categories. - research papers: original research results within the scope of LDTA with a clear motivation, description, analysis, and evaluation. - short research papers: new innovative ideas that have not been completely fleshed out. As a workshop, LDTA strongly encourages these types of submissions. - experience report papers: description of the use of a grammarware tool or technique to solve a non-trivial applied problem with an emphasis on the advantages and disadvantages of the chosen approach to the problem. - tool demo papers: discussion of a tool or technique that explains the contributions of the tool and what specifically will be demonstrated. Each submission must clearly state in which of these categories it falls, and must not be published or submitted elsewhere. Papers are to use the standard LaTeX article style and the authblk style for affiliations; a sample of which is provided at www.ldta.info. Research and experience papers are limited to 15 pages, tool demonstration papers are limited to 10 pages, and short papers are limited to 6 pages. The final version of the accepted papers will, pending approval, be published in the ACM Digital Library and will also be made available during the workshop. Please submit your abstract and paper using EasyChair at http://www.easychair.org/conferences/?conf=ldta2012. The authors of each submission are required to give a presentation at LDTA 2011 and tool demonstration paper presentations are intended to include a significant live, interactive demonstration. The authors of the best papers will be invited to write a journal version of their paper which will be separately reviewed and, assuming acceptance, be published in journal form. As in past years this will be done in a special issue of the journal Science of Computer Programming (Elsevier Science). Invited Speaker --------------------- Janis Voigtländer (University of Bonn, Germany). Important Dates --------------------- Abstract submission: Nov. 28, 2011 Full paper submission: Dec. 5, 2011 Author notification: Jan. 20, 2012 Camera-ready papers: Feb. 05, 2012 LDTA Workshop: Mar. 31 - Apr. 1, 2012 LDTA Tool Challenge ----------------------------- The 2011 Workshop pioneered the LDTA Tool Challenge where tool developers were invited to develop solutions to a range of language processing tasks over a simple but evolving set of imperative programming languages. We expect a challenge to form part of LDTA every two years. The 2012 workshop will feature presentations devoted to a de-brief of the 2011 challenge, based on the paper currently being prepared by challenge participants. Program Committee --------------------------- Suzana Andova, Eindhoven University of Technology, The Netherlands (co-chair) Anya Helene Bagge, University of Bergen, Norway Kyung-Goo Doh, Hanyang University, Ansan, South Korea Jeff Gray, University of Alabama, USA Görel Hedin, Lund Institute of Technology, Sweden Zoltán Horváth, Eötvös Loránd University, Budapest, Hungary Zhenjiang Hu, National Institute of Informatics, Japan Roberto Ierusalimschy, Pontifícia Universidade Católica do Rio de Janeiro, Brazil Ivan Kurtev, University of Twente, The Netherlands Marjan Mernik, University of Maribor, Slovenia Nate Nystrom, University of Lugano, Switzerland João Saraiva, Universidade do Minho, Braga, Portuga Sylvain Schmitz, Ecole Normale Supérieure de Cachan, France Anthony Sloane, Macquarie University, Australia (co-chair) Robert Tairas, Inria, France Laurence Tratt, King's College London, UK Vadim Zaytsev, Centre for Mathematics & Computer Science, The Netherlands Organizing Committee ------------------------------ Anya Helene Bagge, University of Bergen, Norway Emilie Balland, INRIA, France Steering Committee --------------------------- Mark van den Brand, Eindhoven University of Technology, The Netherlands Görel Hedin, Lund University, Sweden Tony Sloane, Macquarie University, Australia Eric Van Wyk, University of Minnesota, United States

1 0