- Haskell-Cafe - Haskell.org

Mixing Unboxed Mutable Vectors and Parsers
by Myles C. Maxfield 10 Apr '12

10 Apr '12

CC: Maintainers of STMonadTrans, Vector, and JuicyPixels Hello, I am writing a Haskell Attoparsec parser which will modify 2-d arrays of small values (Word8, Int8, etc.). My first idea was to simply parse all the deltas, and later apply them to the input list. However, I can't do that because the value of the deltas depend on the value they're modifying. My first pass at this program used a function of the form: p :: [[Word8]] -> Parser [[Word8]] This approach works, however, the program uses far too much memory. Some quick testing shows that lists of Word8s are ~52.6x larger than unboxed vectors of Word8s, and boxed vectors of Word8s are ~7.5x larger than unboxed vectors of Word8s. A better approach would be to use Data.Vector.Unboxed.Mutable and do the mutations inline with the parser. Because mutable vectors require a monad in PrimMonad to do the mutations inside of, I'd have to use a monad transformer to combine Parser and something in PrimMonad. Attoparsec doesn't support being used as a monad transformer, so I can't say something like p :: (PrimMonad m, UM.Unbox a) => M.MVector (PrimState m) (UM.MVector (PrimState m) a) -> ParserT m () I can't use Parsec (instead of Attoparsec) because I require streaming semantics -- eventually I'm going to hook this up to Data.Conduit and parse directly from the net. There is STT (in the package STMonadTrans), however, so I could potentially make the function result in STT Parser (). However, STT doesn't work with Data.Vector.Mutable or Data.Vector.Unboxed.Mutable, because STT isn't a member of the PrimMonad class (as far as I can tell). STT itself doesn't define unboxed mutable vectors (only boxed mutable vectors), but I feel that giving up unboxing isn't really an option because of the memory footprint. As a general observation, it seems silly to have two different mutable vector implementations, one for STT and the other for PrimMonad. So here are my questions: 1. Is it possible to implement PrimMonad with STT? I looked around for a little while, but couldn't find anything that did this. 2. Otherwise, is it reasonable to try to implement unboxed mutable vectors in STT? I feel this is probably going down the wrong path. 3. Are there any parsers that support streaming semantics and being used as a monad transformer? This would require rewriting my whole program to use this new parser, but if that's what I have to do, then so be it. Thanks, Myles C. Maxfield

4 5

Call for Participation: Tests and Proofs (TAP 2012) in Prague
by Achim D. Brucker 10 Apr '12

10 Apr '12

Apologies for duplicates. ======================================================================== CALL FOR PARTICIPATION TESTS and PROOFS 2012 (TOOLS EUROPE 2012) 6th International Conference on Tests & Proofs May 31 - June 1, 2012, Prague, Czech Republic http://lifc.univ-fcomte.fr/tap2012/ Co-located with: ICMT 2012, SC 2012, MSEPT 2012 as part of TOOLS 2012: http://toolseurope2012.fit.cvut.cz/ ======================================================================== The TAP conference is devoted to the convergence of proofs and tests. It combines ideas from both sides for the advancement of software quality. Keynote Speakers ================ * Andreas Kuehlmann <http://www.eecs.berkeley.edu/%7Ekuehl/>, Coverity The Technology and Psychology of Testing Your Code as You Develop It (abstract <http://lifc.univ-fcomte.fr/tap2012/abstract_talk_Kuehlmann.pdf>) * Corina Pasareanu <http://ti.arc.nasa.gov/profile/pcorina/>, NASA Ames Research Center Combining Model Checking and Symbolic Execution for Software Testing (abstract <http://lifc.univ-fcomte.fr/tap2012/abstract_talk_Pasareanu.pdf>) * Mehdi Jazayeri, University of Lugano. Software Composition: Why, what, and how Registration: ============= Early registration, at a reduced price, will be open until 25 April 2012. http://toolseurope2012.fit.cvut.cz/index.php/registration.html Organization: ============= Conference Chair Bertrand Meyer, ETH Zurich, Eiffel Software, and ITMO Program Chairs Achim D. Brucker, SAP Research, Germany Jacques Julliand, University of Franche-Comté Local Organization Pavel Tvrdik, CTU Prague Michal Valenta, CTU Prague Jindra Vojikova, CTU Prague Jan Chrastina, CTU Prague Program: ======== Thursday 31th May, 09:00-10:30: Invited Talk * Andreas Kuehlmann, Coverity: The Technology and Psychology of Testing Your Code as You Develop It Thursday, 11:00-13:00: Paper session Model-Based Testing * Malte Lochau, Ina Schaefer, Jochen Kamischke and Sascha Lity. Incremental Model-based Testing of Delta-oriented Software Product Lines * Hernan Ponce De Leon, Stefan Haar and Delphine Longuet. Conformance Relations for Labeled Event Structures * Joseph Kiniry, Daniel M. Zimmerman and Ralph Hyland. Testing Library Specifications by Verifying Conformance Tests * Chedor Sebastien, Thierry J?ron and Morvan Christophe. Test generation from recursive tiles systems Thursday, 14:30-15:30: Paper session Scenario and UML-Based Testing * Nadia Creignou, Uwe Egly and Martina Seidl. A Framework for the Specification of Random SAT and QSAT Formulas * Jens Brüning, Martin Gogolla, Lars Hamann and Mirco Kuhlmann. Evaluating and Debugging OCL Expressions in UML Models * Uwe Egly, Sebastian Gabmeyer, Martina Seidl, Hans Tompits, .... Towards Scenario-Based Testing of UML Diagrams Thursday, 16:00-17:00: Tutorial * Nikolay Kosmatov, Nicky Williams. Automated Structural Testing with PathCrawler Friday 1st June, 09:00-10:30: Invited Talk of SC * Mehdi Jazayeri, University of Lugano. Software Composition: Why, what, and how Friday 11:00-13:00: Invited Talk of TAP * Corina Pasareanu. NASA. Combining Model Checking and Symbolic Execution for Software Testing Friday, 14:30-15:30: Paper session Test and Model-checking * Martin Sulzmann and Axel Zechner Constructive Finite Trace Analysis with Linear Temporal Logic * Alessandro Armando, Roberto Carbone, Giancarlo Pellegrino, Alessio Merlo and Davide Balzarotti. From Model-checking to Automated Testing of Security Protocols: Bridging the Gap Friday, 16:00-17:30: Paper session Test of Complex Data Structures * Valerio Senni and Fabio Fioravanti. Generation of test data structures using Constraint Logic Programming * Valeria Bengolea, Nazareno Aguirre, Darko Marinov and Marcelo Frias. Coverage Criteria on RepOK to Reduce Bounded Exhaustive Test Suites * Matthieu Carlier, Catherine Dubois and Arnaud Gotlieb. A first step in the design of a formally verified constraint-based testing tool: FocalTest -- Dr. Achim D. Brucker, SAP Research, Vincenz-Priessnitz-Str. 1, D-76131 Karlsruhe Phone: +49 6227 7-52595, http://www.brucker.ch

1 0

ANN: plugins-1.5.2.1
by Jeremy Shaw 09 Apr '12

09 Apr '12

Hello! I am pleased to announce the release of plugins-1.5.2.1: http://hackage.haskell.org/package/plugins The plugins library provides facilities to compile and dynamically load/link Haskell code into a running Haskell application. (The related, plugins-auto package adds support for file watching via inontify and automatic recompilation and reloading, http://hackage.haskell.org/package/plugins) There are three important changes in this release: 1. Support for GHC 7.0, 7.2. and 7.4. We have not *knowingly* dropped support for GHC 6.12. So, if you still use an older compiler and we broke it.. we might be willing to fix it still :) 2. New maintainer: Don Stewart has graciously allowed me to take over the project. I do not have any immediate plans for big changes. But I do plan to: keep it compiling, apply patches in a timely manner, and deal with other minor bug fixes. I would certainly love to see some major improvements. I believe plugins predates the GHC API and, accordingly, does not use it as well as it could. If someone wanted to give plugins some major love, that would be awesome. While plugins has not much recent development, there are still a lot of people that are using it, or would like to. 3. the source has moved to patch-tag and darcs 2, http://patch-tag.com/r/stepcut/plugins patch-tag only supports darcs 2 format repositories, so this forced me to run darcs convert to switch from darcs 1 to darcs 2 format. In the end that is a good thing. The only downside is that I can not directly apply any darcs 1 patches to the repo now. But I doubt there are many floating around anyway. And I can still apply them the hard way. - jeremy

1 1

Guide for converting existing code to Conduit 0.4?
by Erik de Castro Lopo 09 Apr '12

09 Apr '12

Hi all, Is there some sort of a guide for converting existing code Conduit 0.4? What happened to Control.Monad.Trans.Resource.with? What happens to stuff that used to to have a type "C.Source m a" which now seems to need type "C.Pipe Void a (ResourceT m) a"? Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

4 7

Category Theory Questions
by Sergiu Ivanov 09 Apr '12

09 Apr '12

Hello, I have a question not that directly related to Haskell, but I still think this is a good place to ask it. I am currently studying category theory by the book Joy of Cats. Are there any people whom I could ask some questions related to category theory from time to time? Or could I just post my questions here directly? The reason I'm asking is that I seen very nice discussions related to category theory on this list. I hope to be able to deal with most of the stuff myself, but having someone to discuss the matters with is always nice :-) Sergiu [0] katmat.math.uni-bremen.de/acc/acc.pdf

4 4

Re: [Haskell-cafe] Too much inlining on text package
by wren ng thornton 08 Apr '12

08 Apr '12

On 3/16/12 12:22 PM, Aleksey Khudyakov wrote: > Disclaimer. I'm no expert in text internals. > > Because it's told to do so. This is an unfortunate feature of stream > fusion. It does eliminate intermediate data structures but it requires > that everything is inlined. There are ways of mitigating that, however. In particular, the standard style is to have things inline aggressively before stage 0 or 1, and then in the last stage to "inline" things back to an indirect call to the library. This is used ubiquitously in GHC's list fusion, and is essential for stream-fusion since the intermediate stream form is a pessimation when it can't partake in fusion. -- Live well, ~wren

6 8

using FlexibleInstances and OverlappingInstances
by TP 07 Apr '12

07 Apr '12

Hello, In a module I am writing, I would like to use FlexibleInstances and OverlappingInstances. But I get errors, so I am trying to reproduce the problems on a smaller program: -------------------------------------------- {-# LANGUAGE FlexibleInstances, OverlappingInstances #-} data Foo = Foo Int deriving ( Show ) instance Show [Foo] where show [] = "[0]" show l = map show l main = do let l = [ Foo 1, Foo 2 ] print l -------------------------------------------- The first error I obtain is: -------------------------------------------- test_overlappinginstances.hs:7:19: Couldn't match expected type `Char' with actual type `[Char]' Expected type: a0 -> Char Actual type: a0 -> String In the first argument of `map', namely `show' In the expression: map show l -------------------------------------------- Where does this "Char" come from? How to solve this problem? The second error is: -------------------------------------------- test_overlappinginstances.hs:11:5: Overlapping instances for Show [Foo] arising from a use of `print' Matching instances: instance Show a => Show [a] -- Defined in GHC.Show instance [overlap ok] Show [Foo] -- Defined at test_overlappinginstances.hs:5:10-19 -------------------------------------------- The overlap is ok ("overlap ok" does not appear if not using the pragma OverlappingInstances), so it should work? Thanks in advance, TP

2 2

Conduits and Unix Pipes
by Clark Gaebel 07 Apr '12

07 Apr '12

Has anyone built an adapter between unix pipes and conduits? Something like: upipe2conduit :: String -> Conduit Char Char let someLines = "hello\nworld" nLines <- (read . runResourceT $ sourceList someLines $= upipe2conduit "wc -l" $$ consume) :: Integer If this has been done, is it on hackage? Thanks, - clark

2 2

Haskell integration with C/C++ (GSOC)
by Sutherland, Julian 07 Apr '12

07 Apr '12

Hey Guys, I'm Julian, I am reaching the end of my second year as a JMC (Joint Mathematics and Computer science) Student at Imperial College London and I'd like to apply to GSOC for a project involving Haskell and I just wanted to run my idea past the community. I've already talked about this on the haskell-soc IRC channel (I go by the pseudonym "julek"). What I would like to do is to improve the integration of C/C++ with Haskell, particularly in calling Haskell from C/C++. Currently ghc is able to generate stubs to export functions whose arguments are simple types such as CInts into C/C++. The stub generated is always in an extern "C" clause due to the fact that ghc does not as yet implement the C++ calling conventions as defined in the "The Haskell 98 Foreign Function Interface 1.0" (http://www.cse.unsw.edu.au/~chak/haskell/ffi/ffi.pdf) So a first step would be to implement this calling convention to bring it up to speed with the above referenced report. This shouldn't be too hard and mostly involves implementing C++ name mangling conventions. Next, I would like to extend the stub generation so as to be able to deal with more complex types. The type systems in C++ and Haskell have many analogous syntaxes that can be easily exploited to provide strong compatibility and interoperability between the two languages. For example a simple type such as: data Foo = A | B Could be implemented as an enum in C/C++: enum Foo {A, B}; More advanced types that take arguments such as: data Tree = Node Left Right | Leaf Could be converted to a struct in C/C++: struct Tree { struct Tree* left; struct Tree* right; }; Types that have functions that act on them such as: data IntContainer = IntContainer Int getInt :: IntContainer -> Int getInt (IntContainer a) = a could have these functions automatically converted to C/C++: struct IntContainer { int a; }; extern int getInt_hs(IntContainer a); This also opens up the possibility of exploiting C/C++ name mangling conventions, to allow the _hs postfix I'm suggesting here to be eliminated. Haskell classes: class Arithmetic a where (+) :: a -> a -> a (*) :: a -> a -> a (-) :: a -> a -> a (/) :: a -> a -> a could be implemented using C++ functions with virtual members: class Monad { public: virtual Monad add(Monad a, Monad b); virtual Monad mult(Monad a, Monad b) virtual Monad neg(Monad a, Monad b); virtual Monad div(Monad a, Monad b); } All types of single/multiple instancing (i.e. either directly or through requirements of instances) would be implemented using single/multiple inheritance. Obviously, this example is rather contrived due to the conversion of the function names. The fact that the rules that govern function naming in Haskell are much more permissive than those of C/C++ might cause compatibility issues. This can be worked around by implementing a similar syntax to that currently used for function imports by the FFI. E.g..: foreign export ccall "bind" >>= :: CInt -> CInt Similar to: foreign import ccall "f" func :: CInt -> CInt The latter is the current syntax for imports. The name given for the export would be checked for legality in the namespace of the target language. Alternatively this could be done in an automated manner using some naming conventions as well as operator polymorphism, but this would probably sacrifice ease of use. Finally polymorphic Haskell functions/types can be implemented in C++ using templates. I would like to extend ghc to implement enhanced C/C++ stub generation using the methods described above as well as to generate Haskell stubs which describe the Haskell CType equivalents of the Haskell types defined, functions for conversion between the two and function stubs to convert the types, run the Haskell function and convert back as required. On top of this I'd like to write C/C++ libraries for dealing with most of the standard Haskell types such as Maybe, Either, etc... Finally, I'd like to work on ironing out any bugs that remain in the RTS when it is used in "multilingual" situations, as well as improving it's performance in this situation. I found an example of such a bug, which I will test further before reporting it. It seems to be the opposite of the following bug: http://hackage.haskell.org/trac/ghc/ticket/5594 i.e. the stdout buffer isn't always correctly flushed when calling C/C++ in a program whose main is written in Haskell. For example, when running the code: main.hs: module Main where import Foreign.C.Types import System.IO foreign import ccall "inc" c_inc :: CInt -> CInt main :: IO () main = do putStr "Enter n: " -- hFlush stdout s <-getLine putStrLn . show . c_inc . read $ s inc.c: int inc(int i) __attribute__ ((const)); int inc(int i) { return i + 1; } Built with Makefile: all: gcc -c -o inc.o inc.c ghc --make -main-is Main main.hs inc.o -o test rm *.hi *.o The output comes out as: [julek@cryptid inc]$ ./test 2 Enter n: 3 But when the " hFlush stdout" line is commented back in, the output is: [julek@cryptid inc]$ ./test Enter n: 2 3 which is correct, but the extra line shouldn't be necessary. I am currently using ghc 7.4.1 which is the newest version, so this is a current bug. I have had a look for such a bug being reported and have found no such report. I'll look into this further before reporting it, but I am fairly certain this is a bug in the RTS. As part of this project, I would fix this bug (if it is still around when I start) as well as looking for other ones in this area. I think that extending ghc to the level required by "The Haskell 98 Foreign Function Interface 1.0" specification and above would reap significant benefit to the Haskell community. The improved integration into C/C++ would open the door for this to happen for several other languages and would make Haskell more widespread. Many Haskell beginners are daunted by the falsely perceived complexity of working with Haskell IO and monads, but love using the massive advantages that the paradigm gives in a non monadic context. Due to this, simplifying the interoperability between Haskell and C/C++ would enable many of these users to stick around for longer and perhaps encourage them to eventually look deeper into the language. This would make the size of the community grow and make the use of Haskell more widespread, potentially reaping benefits for the community at large. I believe this could be implemented within the time frame given for GSOC. Hope you like the ideas presented here and hopefully I'll be accepted into the Haskell summer of code! If anybody has any opinions on the implementability/usefulness of this and/or criticism of the idea, please inform me and I'll be happy to discuss it! Looking forward to hearing from you! Thanking you in advance. Kind regards, Julian Sutherland

7 7

Subscriber-only lists as Maintainer contacts of Cabal packges
by Joachim Breitner 07 Apr '12

07 Apr '12

Dear Cabal authors, if your package is team maintained and you put in a mailing list as the “Maintainer” contact of your package, that is in general a good thing. But if you do so, please make sure the list is not set to subscriber only; it is an unreasonable burden to subscribe for people who just want to send you one question, and possibly have to contact dozends of different package authors, e.g. as a distribution packager. Thanks, Joachim (Who really thinks that using the subscriber-only setting of mailman as an anti-spam-measure is an abuse of the feature, and that mailman should offer a “non-subscribers get a bounce that allows them to approve the message themselves“ feature which would give the same spam protection but much less hassle for the users.) -- Joachim "nomeata" Breitner Debian Developer nomeata(a)debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata(a)joachim-breitner.de | http://people.debian.org/~nomeata

2 1