January 2014 - Haskell-Cafe

ANN: MiniAgda-0.2014.1.9 Toy language with dependent and sized types
by Andreas Abel 09 Jan '14

09 Jan '14

For what it's worth, I finally uploaded MiniAgda to hackage. If you want to play around with type-based termination and coinduction in a dependently-typed setting, try: cabal install MiniAgda Some examples and pointers to literature are (still) on my old homepage: http://www2.tcs.ifi.lmu.de/~abel/miniagda/ Source code and issue tracker are on the darcs hub: http://hub.darcs.net/abel/miniagda/ Have fun playing (or despair of the horrible error messages), and have a happy new year, Andreas -- Andreas Abel <>< Du bist der geliebte Mensch.

1 0

Drop or update the upper bounds of numerals and numerals-base
by Nikita Karetnikov 09 Jan '14

09 Jan '14

I’ve built both packages locally, and they seem to work fine with GHC 7.6.3. However, I can’t install them from Hackage due to the required dependencies. Could anyone drop or update the upper bounds? Alternatively, I could try to do so myself if someone provides the required permissions.

5 5

Class Instance with ExistentialQuantification
by Andrew Gibiansky 08 Jan '14

08 Jan '14

Why is the following not allowed? {-# LANGUAGE ExistentialQuantification, ExplicitForAll, RankNTypes, FlexibleInstances #-} class Class a where test :: a -> Bool instance Class (forall m. m -> m) where test _ = True main = do putStrLn $ test id Is there a reason that this is forbidden? Just curious. -- Andrew

4 5

ANN: cheapskate 0.1, markdown parser
by John MacFarlane 07 Jan '14

07 Jan '14

I've released a new markdown library on Hackage: http://hackage.haskell.org/package/cheapskate This library is designed to be used in web applications. It is small, accurate, and fast, in pure Haskell with few dependencies. All output is sanitized through a whitelist by default. It is designed to have performance that varies linearly with the input size, even with garbage input. To illustrate: % head -c 100000 /dev/urandom | iconv -f latin1 -t utf-8 | time cheapskate >/dev/null cheapskate > /dev/null 0.15s user 0.01s system 82% cpu 0.199 total % head -c 1000000 /dev/urandom | iconv -f latin1 -t utf-8 | time cheapskate >/dev/null cheapskate > /dev/null 1.53s user 0.03s system 88% cpu 1.770 total % head -c 10000000 /dev/urandom | iconv -f latin1 -t utf-8 | time cheapskate >/dev/null cheapskate > /dev/null 15.50s user 0.20s system 89% cpu 17.632 total This is a test that many markdown parsers fail (including my own pandoc and the markdown package on Hackage). Performance is about seven times faster than pandoc (with five times less memory used), and about 25% faster than the markdown package on Hackage. Generic functions are provided that allow transformations of the AST prior to rendering (e.g., promotion of headers, insertion of syntax highlighting, or the conversion of specially marked code blocks into diagrams). Several markdown extensions are supported, and sensible decisions have been made about several aspects of markdown syntax that are left vague by John Gruber's specification. For details, see the README at https://github.com/jgm/cheapskate.

3 4

Right approach to profiling and optimizing a concurrent data structure?
by Brandon Simmons 07 Jan '14

07 Jan '14

Happy New Year, all, I started what I thought would be a pretty straightforward project to implement a concurrent queue (with semantics like Chan) which I hoped would be faster, but the process of trying to measure and test performance has been super frustrating. I started with a really big criterion benchmark suite that ran through a bunch of Chan-like implementations as well as comparing different var primitives; I was compiling that with `-O2 -threaded` and running with +RTS -N (as that seemed realistic, and results were very consistent). Short version: at some point I realized I had (in my cabal config) enabled executable-profiling, which when disabled completely changed all timing and actually *hurt* performance. Then after a lot more head-banging I realized that +RTS -N seems to run on only one core when compiled with -prof (I didn't see that documented anywhere) although I could *force* the -prof version to use more with -N2, and so apparently for my tests[1], running on a single core just *happened* to be faster (I can see why it might; I probably can't expect a speedup when I'm just measuring throughput). I'd be interested in any comments on above, but mostly I'm trying to understand what my approach should be at this point; should I be benchmarking on 1 core and trying to maximize throughput? Should I also profile on just 1 core? How should I benchmark the effects of lots of contention and interpret the results? How can I avoid benchmarking arbitrary decisions of the thread scheduler, while still having my benchmarks be realistic? Are there any RTS flags or compile-time settings that I should *definitely* have on? Thanks for any clarity on this, Brandon http://brandon.si [1] Here's the test I used while most of the forehead-bloodying occurred, here using `Control.Concurrent.Chan`; for no combination of readers/writers/messages could I manage to get this going as fast on 2 cores as on the single-core bound -prof version runC :: Int -> Int -> Int -> IO () runC writers readers n = do let nNice = n - rem n (lcm writers readers) perReader = nNice `quot` readers perWriter = (nNice `quot` writers) vs <- replicateM readers newEmptyMVar c <- C.newChan let doRead = replicateM_ perReader $ theRead theRead = C.readChan c doWrite = replicateM_ perWriter $ theWrite theWrite = C.writeChan c (1 :: Int) mapM_ (\v-> forkIO (doRead >> putMVar v ())) vs replicateM writers $ forkIO $ doWrite mapM_ takeMVar vs -- await readers

2 1

ICFP 2014: Call for papers
by David Van Horn 07 Jan '14

07 Jan '14

===================================================================== 19th ACM SIGPLAN International Conference on Functional Programming ICFP 2014 Gothenburg, Sweden, 1-3 September 2014 http://www.icfpconference.org/icfp2014 ===================================================================== Important Dates ~~~~~~~~~~~~~~~ Submissions due: Saturday, 1 March 2014, 23:59 UTC-11 (anywhere in the world) Author response: Wednesday, 23 April, 2014 Friday, 25 April, 2014 Notification: Monday, 5 May, 2014 Final copy due: Wednesday, 11 June, 2014 Scope ~~~~~ ICFP 2014 seeks original papers on the art and science of functional programming. Submissions are invited on all topics from principles to practice, from foundations to features, and from abstraction to application. The scope includes all languages that encourage functional programming, including both purely applicative and imperative languages, as well as languages with objects, concurrency, or parallelism. Topics of interest include (but are not limited to): * Language Design: concurrency and distribution; modules; components and composition; metaprogramming; interoperability; type systems; relations to imperative, object-oriented, or logic programming * Implementation: abstract machines; virtual machines; interpretation; compilation; compile-time and run-time optimization; memory management; multi-threading; exploiting parallel hardware; interfaces to foreign functions, services, components, or low-level machine resources * Software-Development Techniques: algorithms and data structures; design patterns; specification; verification; validation; proof assistants; debugging; testing; tracing; profiling * Foundations: formal semantics; lambda calculus; rewriting; type theory; monads; continuations; control; state; effects; program verification; dependent types * Analysis and Transformation: control-flow; data-flow; abstract interpretation; partial evaluation; program calculation * Applications and Domain-Specific Languages: symbolic computing; formal-methods tools; artificial intelligence; systems programming; distributed-systems and web programming; hardware design; databases; XML processing; scientific and numerical computing; graphical user interfaces; multimedia programming; scripting; system administration; security * Education: teaching introductory programming; parallel programming; mathematical proof; algebra * Functional Pearls: elegant, instructive, and fun essays on functional programming * Experience Reports: short papers that provide evidence that functional programming really works or describe obstacles that have kept it from working If you are concerned about the appropriateness of some topic, do not hesitate to contact the program chair. Abbreviated instructions for authors ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * By Saturday, 1 March 2014, 23:59 UTC-11 (anywhere in the world), submit a full paper of at most 12 pages (6 pages for an Experience Report), including bibliography and figures. The deadlines will be strictly enforced and papers exceeding the page limits will be summarily rejected. * Authors have the option to attach supplementary material to a submission, on the understanding that reviewers may choose not to look at it. * Each submission must adhere to SIGPLAN's republication policy, as explained on the web at http://www.sigplan.org/Resources/Policies/Republication * Authors of resubmitted (but previously rejected) papers have the option to attach an annotated copy of the reviews of their previous submission(s), explaining how they have addressed these previous reviews in the present submission. If a reviewer identifies him/herself as a reviewer of this previous submission and wishes to see how his/her comments have been addressed, the program chair will communicate to this reviewer the annotated copy of his/her previous review. Otherwise, no reviewer will read the annotated copies of the previous reviews. Overall, a submission will be evaluated according to its relevance, correctness, significance, originality, and clarity. It should explain its contributions in both general and technical terms, clearly identifying what has been accomplished, explaining why it is significant, and comparing it with previous work. The technical content should be accessible to a broad audience. Functional Pearls and Experience Reports are separate categories of papers that need not report original research results and must be marked as such at the time of submission. Detailed guidelines on both categories are on the conference web site. Proceedings will be published by ACM Press. Authors of accepted submissions are expected to transfer the copyright to the ACM. Presentations will be videotaped and released online if the presenter consents. The proceedings will be freely available for download from the ACM Digital Library from one week before the start of the conference until two weeks after the conference. Formatting: Submissions must be in PDF format printable in black and white on US Letter sized paper and interpretable by Ghostscript. Papers must adhere to the standard ACM conference format: two columns, nine-point font on a ten-point baseline, with columns 20pc (3.33in) wide and 54pc (9in) tall, with a column gutter of 2pc (0.33in). A suitable document template for LaTeX is available: http://www.acm.org/sigs/sigplan/authorInformation.htm Submission: Submissions will be accepted on the web at https://www.easychair.org/conferences/?conf=icfp2014 . Improved versions of a paper may be submitted at any point before the submission deadline using the same web interface. Author response: Authors will have a 72-hour period, starting at 0:00 UTC-11 on Wednesday, 23 April 2014, to read reviews and respond to them. ACM Author-Izer is a unique service that enables ACM authors to generate and post links on either their home page or institutional repository for visitors to download the definitive version of their articles from the ACM Digital Library at no charge. Downloads through Author-Izer links are captured in official ACM statistics, improving the accuracy of usage and impact measurements. Consistently linking the definitive version of ACM article should reduce user confusion over article versioning. After your article has been published and assigned to your ACM Author Profile page, please visit http://www.acm.org/publications/acm-author-izer-service to learn how to create your links for fee downloads from the ACM DL. General Chair: Johan Jeuring, Utrecht University Program Chair: Manuel Chakravarty, University of New South Wales Program Committee: Edwin Brady, University of St Andrews Derek Dreyer, Max Planck Institute for Software Systems Ralf Hinze, University of Oxford Zhenjiang Hu, National Institute of Informatics Patricia Johann, Appalachian State University Ken Larsen, University of Copenhagen Yukiyoshi Kameyama, University of Tsukuba Anil Madhavapeddy, University of Cambridge Geoffrey Mainland, Drexel University David Mazières, Stanford University Jay McCarthy, Brigham Young University Matthew Might, University of Utah Ulf Norell, Chalmers University of Technology Tiark Rompf, Swiss Federal Institute of Technology in Lausanne Chung-chieh Shan, Indiana University Mary Sheeran, Chalmers University of Technology Matt Sottile, Galois Don Syme, Microsoft Research Jesse Tov, Harvard University

1 0

happstack-fastcgi maintenance
by Thomas Bereknyei 07 Jan '14

07 Jan '14

I've patched happstack-fastcgi to work with the latest versions of ghc and happstack. The maintainers have expressed that they consider it unmaintained. I would like to gauge the interest in the library and perhaps maintain it. Let me know if this is of interest to anyone. Have you used it in the past? What features would you need added? Any changes? -Tom

2 1

relocation R_X86_64_PC32 against undefined symbol?
by Magnus Therning 07 Jan '14

07 Jan '14

I get the following error when trying to build hsimports: [7 of 7] Compiling HsImport ( src/HsImport.hs, dist/build/HsImport.dyn_o ) /usr/bin/ld: dist/build/HsImport/Args.dyn_o: relocation R_X86_64_PC32 against undefined symbol `hsimportzm0zi2zi6zi3_Pathszuhsimport_version1_closure' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status What could be causing this? /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus(a)therning.org jabber: magnus(a)therning.org twitter: magthe http://therning.org/magnus Do not meddle in the affairs of Wizards, for they are subtle and quick to anger. -- J.R.R Tolkien

2 7

"Segmentation fault/access violation" when working with FFI
by Leza Morais Lutonda 07 Jan '14

07 Jan '14

Hi, I has trying to use the portaudio [1] package to play some sound, and running the examples [2] and it results in the "Segmentation fault/access violation" error. Any idea? Thanks. [1] http://hackage.haskell.org/package/portaudio [2] https://github.com/sw17ch/portaudio/blob/master/examples/Example1.h

2 2

Associated types, kind constraints & typelits
by Nicolas Trangez 07 Jan '14

07 Jan '14

All, While toying with typelits I wanted to get the following to work, but failed to. Is it intended not to work at all, should I change something to get it to work, or is this something which needs some GHC support? Note I obviously tried to add the constraint mentioned in the compiler error, but failed to: I seem to add too many type arguments to SingI, which somewhat puzzles me. Thanks, Nicolas {-# LANGUAGE TypeFamilies, DataKinds #-} module Main where import GHC.TypeLits class C a where type T a :: Nat data D = D instance C D where type T D = 10 {- This is not allowed, as intended: data E = E instance C E where type T E = Int -} -- This works: tOfD :: D -> Integer tOfD D = fromSing $ (sing :: Sing (T D)) {- This doesn't work: - Could not deduce (SingI Nat (T a1)) arising from a use of `sing' - from the context (C a) tOf :: C a => a -> Integer tOf _ = fromSing $ (sing :: Sing (T a)) -} main :: IO () main = return ()

3 4