- Haskell-Cafe - Haskell.org

FLOPS 2014 Final CFP (Reminder)
by Eijiro Sumii 09 Dec '13

09 Dec '13

Final Call For Papers ===================== Twelfth International Symposium on Functional and Logic Programming (FLOPS 2014) June 4-6, 2014 Kanazawa, Japan http://www.jaist.ac.jp/flops2014/ ---------------------------------------------------------------------- - Submission deadline: December 13, 2013 - Journal publications in JFP (Jounral of Functional Programming) and TPLP (Theory and Practice of Logic Programming) are planned (see below). - Hyakumangoku Matsuri ( https://www.google.com/search?q=hyakumangoku%20matsuri&tbm=isch ) is scheduled *just* after FLOPS 2014. ---------------------------------------------------------------------- FLOPS is a forum for research on all issues concerning declarative programming, including functional programming and logic programming, and aims to promote cross-fertilization and integration between the two paradigms. Previous FLOPS meetings were held at Fuji Susono (1995), Shonan Village (1996), Kyoto (1998), Tsukuba (1999), Tokyo (2001), Aizu (2002), Nara (2004), Fuji Susono (2006), Ise (2008), Sendai (2010), and Kobe (2012). Topics ====== FLOPS solicits original papers in all areas of functional and logic programming, including (but not limited to): - Language issues: language design and constructs, programming methodology, integration of paradigms, interfacing with other languages, type systems, constraints, concurrency and distributed computing. - Foundations: logic and semantics, rewrite systems and narrowing, type theory, proof systems. - Implementation issues: compilation techniques, memory management, program analysis and transformation, partial evaluation, parallelism. - Applications: case studies, real-world applications, graphical user interfaces, Internet applications, XML, databases, formal methods and model checking. The proceedings will be published as an LNCS volume. The proceedings of the previous meetings (FLOPS 1999, 2001, 2002, 2004, 2006, 2008, 2010, and 2012) were published as LNCS 1722, 2024, 2441, 2998, 3945, 4989, 6009, and 7294. PC Co-Chairs ============ Michael Codish (Ben-Gurion University of the Negev) Eijiro Sumii (Tohoku University) PC Members ========== Lars Birkedal (Aarhus University) Michael Codish (Ben-Gurion University of the Negev) [co-chair] Marina De Vos (University of Bath) Moreno Falaschi (Universita degli studi di Udine) Carsten Fuhs (University College London) John Gallagher (Roskilde Universitet / IMDEA Software Institute) Samir Genaim (Universidad Complutense de Madrid) Laura Giordano (Universita del Piemonte Orientale) Ichiro Hasuo (University of Tokyo) Fritz Henglein (University of Copenhagen) Andy King (University of Kent) Oleg Kiselyov Vitaly Lagoon (MathWorks) Shin-Cheng Mu (Academia Sinica) Keiko Nakata (Institute of Cybernetics at Tallinn University of Technology) Luke Ong (University of Oxford) Peter Schachte (University of Melbourne) Takehide Soh (Kobe University) Eijiro Sumii (Tohoku University) [co-chair] Tachio Terauchi (Nagoya University) Joost Vennekens (KU Leuven) Janis Voigtlaender (Universitaet Bonn) Stephanie Weirich (University of Pennsylvania) Local Chair =========== Yuki Chiba (JAIST) Submission ========== Submissions must be unpublished and not submitted for publication elsewhere. Work that already appeared in unpublished or informally published workshops proceedings may be submitted. See also ACM SIGPLAN Republication Policy: http://www.sigplan.org/Resources/Policies/Republication Submissions should fall into one of the following categories: - Regular research papers: they should describe new results and will be judged on originality, correctness, and significance. - System descriptions: they should contain a link to a working system and will be judged on originality, usefulness, and design. - Declarative pearls: new and excellent declarative programs or theories with illustrative applications. System descriptions and declarative pearls must be explicitly marked as such in the title. Submissions must be written in English and can be up to 15 pages long including references, though pearls are typically shorter. Authors are required to use LaTeX2e and the Springer llncs class file, available at: http://www.springer.de/comp/lncs/authors.html Regular research papers should be supported by proofs and/or experimental results. In case of lack of space, this supporting information should be made accessible otherwise (e.g., a link to a Web page, or an appendix). Papers should be submitted electronically at: https://www.easychair.org/conferences/?conf=flops2014 Important Dates =============== Submission deadline: December 13, 2013 Author notification: February 10, 2014 Camera-ready copy: March 7, 2014 Journal Publication =================== - Journal of Functional Programming and - Theory and Practice of Logic Programming 2-4 of the best papers in each of the two areas: Functional Programming and Logic Programming, will be invited for inclusion in a designated FLOPS section within each of the two journals. The Theory and Practice of Logic Programming papers will appear as "Rapid Publications". All of the these submissions are expected to represent high-quality revisions and extensions of the selected FLOPS papers and will be reviewed under the standard criteria of each journal. Venue ===== Main Hall, Ishikawa Prefectural Museum of Art, 2-1 Dewa-machi, Kanazawa, Ishikawa 920-0963 JAPAN. Some Previous FLOPS =================== FLOPS 2012, Kobe: http://www.org.kobe-u.ac.jp/flops2012/ FLOPS 2010, Sendai: http://www.kb.ecei.tohoku.ac.jp/flops2010/ FLOPS 2008, Ise: http://www.math.nagoya-u.ac.jp/~garrigue/FLOPS2008/ Sponsor ======= Japan Society for Software Science and Technology (JSSST), Special Interest Group on Programming and Programming Languages (SIG-PPL) In Cooperation With =================== ACM SIGPLAN Asian Association for Foundation of Software (AAFS) Association for Logic Programming (ALP)

1 0

Re: [Haskell-cafe] converting between a Ptr a and an Integer
by keydana＠gmx.de 08 Dec '13

08 Dec '13

Hi, thanks for your answers, I've found a way (or rather, was pointed to it ;-) ) in the meantime, using something like nullPtr `plusPtr` <desired address> Thanks all the same, Sigrid

1 0

existential quantification
by TP 08 Dec '13

08 Dec '13

Hi everybody, I try to understand existential quantification. I have two questions. 1/ I have just read the answer of yairchu at http://stackoverflow.com/questions/3071136/what-does-the-forall-keyword-in-… He writes: """ So with Existential-Quantification, foralls in data definitions mean that, the value contained *can* be of *any* suitable type, not that it *must* be of *all* suitable types. """ This made me think to an error I obtained with the code: --------------- test :: Show s => s test = "foobar" --------------- The error is: Could not deduce (s ~ [Char]) from the context (Show s) bound by the type signature for test :: Show s => s [...] `s' is a rigid type variable bound by the type signature for test :: Show s => s Indeed, `test :: Show s => s` means "for any type s which is an instance of Show, test is a value of that type s". But for example "foobar" can't be an Int that is an instance of Show, so it yields an error. By comparison, --------------- test :: Num a => a test = 42 --------------- works because 42 can be a value of type Int or Integer or Float or anything else that is an instance of Num. So I thought that by using existential quantification, the first example could work: --------------- {-# LANGUAGE ExistentialQuantification #-} test :: forall s . Show s => s test = "asd" --------------- But I obtain the same error, why? 2/ Is the notion of existential type related in some way to the classical mathematical quantifier "∃" (Unicode symbol U+2203: "There exists")? If yes, then why using "forall" for an "existential type"? At the following address http://www.haskell.org/ghc/docs/6.12.1/html/users_guide/data-type-extension… we read """ 7.4.4.1. Why existential? What has this to do with existential quantification? Simply that MkFoo has the (nearly) isomorphic type MkFoo :: (exists a . (a, a -> Bool)) -> Foo But Haskell programmers can safely think of the ordinary universally quantified type given above, thereby avoiding adding a new existential quantification construct. """ But I don't understand the explanation. Thanks in advance, TP

7 10

STM interfacing with GLFW
by Pavel Krajcevski 07 Dec '13

07 Dec '13

Hi, I'm new to STM and to Haskell in general. I've been writing a small library to try some graphics algorithms in Haskell, but using GLFW's callbacks seems to be causing me problems. I have a (relatively heavyweight?) object wrapped in a TVar (Data.Set) that I'm sharing across all threads. Unfortunately, once I run the program, it becomes unresponsive although the main loop is still running. I'm not sure exactly what the semantics are for getting STM right, but ideally I'm trying to modify the TVar in GLFW event callbacks and then finally read out the value of the TVar at the end (or beginning) of my rendering loop. I've been able to get a small program working that reproduces my problem: https://gist.github.com/Mokosha/34eda7bd2d6b5cafd5a3 Any help would be great! Thanks! - Pavel

1 1

converting between a Ptr a and an Integer
by keydana＠gmx.de 07 Dec '13

07 Dec '13

Hi, is there any way to convert between a Ptr a and an Integer? (I would like to attach to shared memory and dereference pointers to certain memory addresses, as you would do in C.) If there is no way at all, I think I could still get along by defining c_shmat as c_shmat :: CInt -> CInt -> CInt -> IO (Ptr a) and perform calculations using plusPtr, but then how do I check if I got back the correct address, and not (void *) -1, which is what shmat returns on error? Any help very much appreciated! Thanks Sigrid

3 2

Higher order functions and strictness
by Joachim Breitner 06 Dec '13

06 Dec '13

Hi, we currently have a pattern where a higher order function (like foldl, or Map.unionWith), which naively build thunks without the passed function having a chance to prevent that. Therefore, there are variants like foldl', which seq the result of the function. Can one have one function that allows for both? I take mapMaybe :: (a -> b) -> Maybe a -> Maybe b as an (simple, and not very relevant) example. With that signature, there is not much "mapMaybe f x" can do. It either applies f lazily to x, or strictly. One could have data Box a = Box a mapMaybe :: (a -> Box b) -> Maybe a -> Maybe b and have mapMaybe pattern-match on Box. Then it will evaluate _something_ of the return value of f, and f can have control over whether the thing inside the box is evaluated or not. So this is nice, but unfortunately we now allocate and destruct a box that we do not care about. But since I had been looking at some unboxed tuples recently, I noticed that the singleton unboxed tuple allows for exactly that: Call a function in a way that it has control (i.e. can force stuff), but do not necessarily evaluate its result, and all that without extra allocations. Here is some example code: {-# LANGUAGE UnboxedTuples #-} import GHC.HeapView mapMaybe :: (a -> (# b #) ) -> Maybe a -> Maybe b mapMaybe _ Nothing = Nothing mapMaybe f (Just x) = case f x of (# y #) -> Just y f_plain :: Int -> Int f_plain x = x + 1 f_lazy :: Int -> (# Int #) f_lazy x = (# x + 1 #) f_strict :: Int -> (# Int #) f_strict x = let y = x + 1 in y `seq` (# y #) main = do let x = Just 1 Just y1 <- return $ fmap f_plain x Just y2 <- return $ mapMaybe f_lazy x Just y3 <- return $ mapMaybe f_strict x let results = (y1,y2,y3) buildHeapTree 10 (asBox results) >>= putStrLn . ppHeapTree and here the result: (_thunk _fun{0} (I# 1),_thunk (I# 1),I# 2) as expected and desired, fmap and mapMaybe with the lazy f left a thunk in the Just constructor, while the strict f had a chance to evaluate its result. Of course (#..#) has it downsides, e.g. you cannot make a newtype for it (newtype Box a = (# x #)) does not work... but it might be an interesting design pattern if you need it – imagine a "mapTuple10", which takes 10 function arguments – you can’t have '-variants for every 2^10 possible strictness combinations. Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata(a)debian.org

2 1

Haskell on Heroku (improved)
by Joe Nelson 06 Dec '13

06 Dec '13

Hey all, I just created a buildpack to deploy Haskell apps to Heroku. If you use Yesod or Snap or whatever give it a try. It uses GHC 7.6.3 and Cabal 1.18 so it should support all the modern goodies you like to use. https://github.com/begriffs/heroku-buildpack-ghc Also some people have reported an issue with cabal-install choosing the wrong versions of packages. Anyone run into this kind of thing before? https://github.com/begriffs/heroku-buildpack-ghc/issues/7 Regards, Joe Nelson

1 0

hash tables, judy arrays, and more
by Ketil Malde 06 Dec '13

06 Dec '13

Hi, As some of you may know¹, I've been playing around with associative data structures, and in particular Judy arrays, using the "judy" package by Don S. Now, I find these to be fast and (more importantly) frugal concerning memory - but now I see what I can only interpret as memory corruption - a bit depending on the ordering of the code and/or insertion of print statements, output is truncated or contaminated. The strange thing is that this only occurs when I also use Data.Vector or Data.HashTable.IO in the same program - if it's all Judy, then things work as expected - as far as I have seen, anyway. First I thought it was my dubious "insertWith" function, but when I reverted to separate "insert" and "lookup", I can still provoke the behavior. Has anybody else seen anything similar? Any idea how to debug something like this? Then I thought I'd look at hash tables, using the 'hashtables' package. I haven't tested it much yet, but it appears to be a lot slower than Judy (maybe as much as 10x), and uses a lot more memory (also perhaps a factor of 10). I guess I might be able to improve things a bit by judiciously applying strictness, but it seems to be storing both keys and values unboxed, so I don't expect to come close to Judy - I guess there isn't any unboxed hash table implementations around? Anyway - I seem to have programmed myself into a corner here, so suggestions welcome! -k ¹ http://blog.malde.org/posts/frequency-counting.html and http://blog.malde.org/posts/k-mer-counting.html -- If I haven't seen further, it is by standing in the footprints of giants

2 1

Return of the revenge of the revisit of the extensible records, reiterated
by Atze van der Ploeg 06 Dec '13

06 Dec '13

Dear all, Extensible records have been a long outstanding feature request for GHC. Using the new closed type families and type literals, it is actually possible to implement Daan Leijen's "`Extensible Records with Scoped Labels" system as a library. I have implemented this library at https://github.com/atzeus/openrec (the documentation is at http://homepages.cwi.nl/~ploeg/openrecvardocs/) The only thing it requires is the availability of a closed type family that compares two type level symbols (i.e. the ordering on strings): type family (m :: Symbol) <=.? (n :: Symbol) :: Bool patches to GHC that implement this built-in closed type family are also at the github site. I would like to generate some discussion about: * Is this the interface we would like for open records and variants? * Would it be worthwhile to invest in syntactic sugar for open record operations? * Any comments on the interface and or its implementation? Cheers! Atze van der Ploeg

6 20

Help with profiling
by Uri Braun 06 Dec '13

06 Dec '13

Hi Café, I'm attempting to profile my rather large (~18K LOC) Haskell program that primarily manipulates graph structures based on Data.IntMap. The program is chewing up _lots_ of memory (approx. 4G for 2.5K nodes & 2.5K edges) and I have profiled it in an attempt to figure out why. It appears that the .prof and .hp (which I visualize with hp2ps -c) files do not agree on the source of the problem. The hp results are located at: http://www.eecs.harvard.edu/~uribraun/sybil.ps and the top of the .prof file looks like this: COST CENTRE MODULE %time %alloc compare Policy.Edge 21.7 50.0 eqPartition.edges Policy.EdgeQuad 6.5 3.7 toConstructedSet Types.TaggedIntMultimap 6.1 3.6 elems Types.TaggedIntMap 6.0 6.8 elems Types.TaggedIntSet 5.7 3.8 toPairs Types.TaggedIntMultimap 3.9 5.2 assocs Types.TaggedIntMap 3.2 4.1 eqIsValid Policy.EdgeQuad 2.9 0.5 rIsValid Policy.Relations 2.2 0.2 assocs.\ Types.TaggedIntMap 1.8 0.0 keysSet Types.TaggedIntMap 1.5 1.7 mergeIdenticalNodesT.exactMap Minimize.MergeIdentical 1.4 1.2 fromList Types.TaggedIntSet 1.3 1.6 tePartitionSrc Policy.TaggedEdge 1.2 0.9 null Types.TaggedIntSet 1.2 0.0 scc.comps Policy.Scc 1.2 0.9 tePartitionTgt Policy.TaggedEdge 1.1 0.8 member Types.TaggedIntSet 1.1 0.8 alter Types.TaggedIntMap 1.0 1.1 Also, the line in the .prof that corresponds to the anormUnion.name (what the hprof image claims is taking up space) looks like (some spaces removed): anormUnion.name Anormalize.Anormalize 2914 60 0.0 0.0 0.0 0.0 My main questions at this point are: 1. What are the chances the hprof image is just wrong? 2. What would you suggest I try next in debugging my space issue? This is my first big Haskell program, please do inform me of any big war tools I dont know about. Many thanks in advance! +Uri

2 2