February 2016 - Haskell-Cafe

Combining ST with STM
by Thomas Koster 09 Feb '16

09 Feb '16

Hi friends, I have an STM transaction that needs some private, temporary state. The most obvious way is to simply pass pure state as arguments, but for efficiency, I would like this state to be some kind of mutable array, like STArray. I know, STM has TVars and TArray, but since this state is private to the transaction, I am wondering if using TVars/TArrays for private state might be overkill that will unnecessarily slow down the STM commit process. The private state is, by definition, not shared, so including it in the STM log and commit process is, as far as I can tell, pointless. ST and STArray still appear to be the most appropriate tools for the private state, because STRefs and STArrays really, really are private. So this basically means I want to interleave ST and STM in a "safe" way. That is, if the STM transaction retries, I want the ST state to be vaporised as well. Ideally, I would love to be able to say something like this: -- | Copy the value from the shared TVar into the private STRef. load :: TVar a -> STRef a -> STSTM s () load shared private = do value <- liftSTM (readTVar shared) liftST (writeSTRef private value) Naturally, that STRef must originate from a call to newSTRef earlier in the same transaction and is private to it, just like the real ST monad. As far as I can tell, I am not trying to weaken either ST or STM in any way here. I found the STMonadTrans package on Hackage [1] that claims to implement ST as a monad transformer, STT, which sounds close to what I want. While its documentation does not mention STM, it does say that some monads are unsafe to use as a base monad for STT. Is STMonadTrans safe to use with STM? [1] https://hackage.haskell.org/package/STMonadTrans Thanks, Thomas Koster

4 9

ANNOUNCE: hoppy, qtah
by Bryan Gardiner 09 Feb '16

09 Feb '16

Are you sick and tired of the ease with which Haskell code flows onto the page? Even the thrill of binding to a C library losing its lustre? Look no further! I present to you a tool restoring the good old days of pointer arithmetic, manual memory management, and hours lost to the debugger: Hoppy is a new C++ FFI generator for Haskell. It takes Haskell code that describes a C++ API, and generates C++ and Haskell code to allow the two languages to interact. It supports a good subset of C++, including functions, classes, variables, enums and bitflags, operator overloading, constness, and simple templates. Adding a function takes only a few lines of code, and you normally don't need to write C++ yourself. For example, a definition for std::string is: c_string :: Class c_string = addReqIncludes [includeStd "string"] $ classAddFeatures [Assignable, Comparable, Copyable, Equatable] $ makeClass (ident1 "std" "string") (Just $ toExtName "StdString") [] [ mkCtor "new" [] , mkCtor "newFromCString" [TPtr $ TConst TChar] ] [ mkConstMethod' "at" "at" [TInt] $ TRef TChar , mkConstMethod' "at" "get" [TInt] TChar , mkConstMethod "c_str" [] $ TPtr $ TConst TChar , mkConstMethod "size" [] TSize , mkConstMethod OpAdd [TObj c_string] $ TObj c_string ] Now, writing a FFI generator isn't much fun unless you have a project to use it with. So I am pleased to also announce Qtah, a fresh set of Qt 4/5 bindings. These include portions of QtCore, QtGui, and QtWidgets, and are on the whole wildly incomplete, but are usable for basic tasks so far, and I am working on extending coverage. (On qtHaskell/hsQt: I started Qtah before qtHaskell began being updated in 2015 and I missed when that happened. My hope is that Qtah requires less code and effort to maintain; at least, qtHaskell contains a lot of generated code and I haven't seen where it came from, so please correct me if the generator is in fact available somewhere. Hoppy also doesn't (currently) do many of the fancy things that qtHaskell does, like overloading and garbage collection.) Both Hoppy and Qtah are young, and I am very interested in discussing how to make them most useful for the community. Because of questions such as this[1], their APIs (including those of generated bindings) should be considered experimental at this time. I will be uploading Hoppy to Hackage shortly. Becuase Qtah includes a shared library, I haven't figured out how to get that on Hackage yet, so you'll have to clone the repo yourself. http://khumba.net/projects/hoppy http://khumba.net/projects/qtah Happy hacking! Bryan Gardiner [1] https://gitlab.com/khumba/hoppy/issues/3

2 2

maps over arrays that provide the position index for the array and accelerate libraries?
by Rob Stewart 09 Feb '16

09 Feb '16

In vector library there's this useful function: imap :: (Int -> a -> b) -> Vector a -> Vector b And in Data.Map there's this similar function: mapWithKey :: (k -> a -> b) -> Map k a -> Map k b I'm looking for something similar in the array and accelerate libraries, i.e. On arrays in Data.Array.IArray: imap :: (IArray a e, IArray a e', Ix i) => (i -> e -> e') -> a i e -> a i e' And on Accelerate arrays: imap :: (Shape ix, Elt a, Elt b) => (Exp ix -> Exp a -> Exp b) -> Acc (Array ix a) -> Acc (Array ix b) Is anyone aware of such map implementations for arrays in the array and accelerate libraries, that provide your mapped function not only the element at a position, but also the index at that position? Thanks, -- Rob

2 1

Including a "XXX_stub.h" file from another Haskell library?
by Alp Mestanogullari 09 Feb '16

09 Feb '16

Hello -cafe! Let's say I have two Haskell libraries, `A` and `B`. `A` uses the FFI, `foreign export` to be precise, to make a Haskell function available to C land. This generates a "stub" C header file with a corresponding C function declaration. `B` has some C code in it and needs to include the stub header that was generated when compiling `A`, in order to call the function that I 'foreign export'ed in A. When I "naively" include the stub header file for the module in A that contains the 'foreign export' statement, inside one of the C files of the `B` library, the said header can't be found. Is what I want to do at all possible? If yes, how could I make this work? Thanks! -- Alp Mestanogullari

2 1

A Sliding TChan?
by Mark Fine 09 Feb '16

09 Feb '16

We're currently using a TMChan to broadcast from a single producer thread to many consumer threads. This works well! However, we're seeing issues with a fast producer and/or a slow consumer, with the channel growing unbounded. Fortunately, our producer-consumer communication is time-sensitive and tolerant of loss: we're ok with the producer always writing at the expense of dropping communication to a slow consumer. A TMBChan provides a bounded channel (but no means to dupe/broadcast) where a writer will block once the channel fills up. In our use case, we'd like to continue writing to the channel but dropping off the end of the channel. Clojure's core-async module has some related concepts, in particular the notion of a sliding buffer <https://clojure.github.io/core.async/#clojure.core.async/sliding-buffer> that drops the oldest elements once full. Has anyone encountered something similar in working with channels and/or have any solutions? Thanks! Mark

5 5

PSA: If you're serializing floating point numbers, don't use binary
by Francesco Mazzoli 09 Feb '16

09 Feb '16

Serialization of floating point numbers with binary is fantastically slow and incorrect if you’re using NaNs, see https://github.com/kolmodin/binary/issues/64 <https://github.com/kolmodin/binary/issues/64> https://github.com/kolmodin/binary/issues/69 <https://github.com/kolmodin/binary/issues/69> I recently spent half a day debugging performance problems because of this, and since backwards compatibility with older formats is required, this problem is probably not going to be solved. We decided to switch to cereal for this reason. With some patches <https://github.com/GaloisInc/cereal/pull/46> cereal was 30x faster for the data we were serializing (scientific computing, mostly Doubles packed in nested records containing vectors). The size of the serialized data is also roughly 3 times smaller – with binary a Double takes at least 25 bytes of space instead of 8. With Float it’s even worse, 25 bytes instead of 8.

2 2

ICFP 2016 Second Call for Papers
by Lindsey Kuper 09 Feb '16

09 Feb '16

ICFP 2016 The 21st ACM SIGPLAN International Conference on Functional Programming http://conf.researchr.org/home/icfp-2016 Second Call for Papers Important dates --------------- Submissions due: Wednesday, March 16 2016, 15:00 (UTC) https://icfp2016.hotcrp.com (now open) Author response: Monday, 2 May, 2016, 15:00 (UTC) - Thursday, 5 May, 2016, 15:00 (UTC) Notification: Friday, 20 May, 2016 Final copy due: TBA Early registration: TBA Conference: Monday, 19 September - Wednesday, 21 September, 2016 (note updated conference dates) Scope ----- ICFP 2016 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, parallelism, and distribution; modules; components and composition; metaprogramming; type systems; interoperability; domain-specific languages; and relations to imperative, object-oriented, or logic programming. - Implementation: abstract machines; virtual machines; interpretation; compilation; compile-time and run-time optimization; garbage collection and 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: 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 and 3D graphics 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 Wednesday, March 16 2016, 15:00 (UTC), submit a full paper of at most 12 pages (6 pages for an Experience Report), in standard SIGPLAN conference format, including figures but ***excluding bibliography***. The deadlines will be strictly enforced and papers exceeding the page limits will be summarily rejected. ***ICFP 2016 will employ a lightweight double-blind reviewing process.*** To facilitate this, submitted papers must adhere to two rules: 1. ***author names and institutions must be omitted***, and 2. ***references to authors' own related work should be in the third person*** (e.g., not "We build on our previous work ..." but rather "We build on the work of ..."). The purpose of this process is to help the PC and external reviewers come to an initial judgement about the paper without bias, not to make it impossible for them to discover the authors if they were to try. Nothing should be done in the name of anonymity that weakens the submission or makes the job of reviewing the paper more difficult (e.g., important background references should not be omitted or anonymized). In addition, authors should feel free to disseminate their ideas or draft versions of their paper as they normally would. For instance, authors may post drafts of their papers on the web or give talks on their research ideas. We have put together a document answering frequently asked questions that should address many common concerns: http://conf.researchr.org/track/icfp-2016/icfp-2016-papers#Submission-and-R… (last updated February 8, 2016). - Authors have the option to attach supplementary material to a submission, on the understanding that reviewers may choose not to look at it. The material should be uploaded at submission time, as a single pdf or a tarball, not via a URL. This supplementary material may or may not be anonymized; if not anonymized, it will only be revealed to reviewers after they have submitted their review of your paper and learned your identity. - 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 given below. 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 at least 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 SIGPLAN 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 at http://www.sigplan.org/Resources/Author/ Submission: Submissions will be accepted at https://icfp2016.hotcrp.com. 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 15:00 UTC on Monday, 2 May, 2016, 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 free downloads from the ACM DL. AUTHORS TAKE NOTE: The official publication date is the date the proceedings are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of your conference. The official publication date affects the deadline for any patent filings related to published work. Special categories of papers ---------------------------- In addition to research papers, ICFP solicits two kinds of papers that do not require original research contributions: Functional Pearls, which are full papers, and Experience Reports, which are limited to six pages. Authors submitting such papers may wish to consider the following advice. Functional Pearls ================= A Functional Pearl is an elegant essay about something related to functional programming. Examples include, but are not limited to: - a new and thought-provoking way of looking at an old idea - an instructive example of program calculation or proof - a nifty presentation of an old or new data structure - an interesting application of functional programming techniques - a novel use or exposition of functional programming in the classroom While pearls often demonstrate an idea through the development of a short program, there is no requirement or expectation that they do so. Thus, they encompass the notions of theoretical and educational pearls. Functional Pearls are valued as highly and judged as rigorously as ordinary papers, but using somewhat different criteria. In particular, a pearl is not required to report original research, but, it should be concise, instructive, and entertaining. Your pearl is likely to be rejected if your readers get bored, if the material gets too complicated, if too much specialized knowledge is needed, or if the writing is inelegant. The key to writing a good pearl is polishing. A submission you wish to have treated as a pearl must be marked as such on the submission web page, and should contain the words ``Functional Pearl'' somewhere in its title or subtitle. These steps will alert reviewers to use the appropriate evaluation criteria. Pearls will be combined with ordinary papers, however, for the purpose of computing the conference's acceptance rate. Experience Reports ================== The purpose of an Experience Report is to help create a body of published, refereed, citable evidence that functional programming really works ? or to describe what obstacles prevent it from working. Possible topics for an Experience Report include, but are not limited to: - insights gained from real-world projects using functional programming - comparison of functional programming with conventional programming in the context of an industrial project or a university curriculum - project-management, business, or legal issues encountered when using functional programming in a real-world project - curricular issues encountered when using functional programming in education - real-world constraints that created special challenges for an implementation of a functional language or for functional programming in general An Experience Report is distinguished from a normal ICFP paper by its title, by its length, and by the criteria used to evaluate it. - Both in the proceedings and in any citations, the title of each accepted Experience Report must begin with the words ``Experience Report'' followed by a colon. The acceptance rate for Experience Reports will be computed and reported separately from the rate for ordinary papers. - An Experience Report is at most six pages long. Each accepted Experience Report will be presented at the conference, but depending on the number of Experience Reports and regular papers accepted, authors of Experience reports may be asked to give shorter talks. - Because the purpose of Experience Reports is to enable our community to accumulate a body of evidence about the efficacy of functional programming, an acceptable Experience Report need not add to the body of knowledge of the functional-programming community by presenting novel results or conclusions. It is sufficient if the Report states a clear thesis and provides supporting evidence. The thesis must be relevant to ICFP, but it need not be novel. The program committee will accept or reject Experience Reports based on whether they judge the evidence to be convincing. Anecdotal evidence will be acceptable provided it is well argued and the author explains what efforts were made to gather as much evidence as possible. Typically, more convincing evidence is obtained from papers which show how functional programming was used than from papers which only say that functional programming was used. The most convincing evidence often includes comparisons of situations before and after the introduction or discontinuation of functional programming. Evidence drawn from a single person's experience may be sufficient, but more weight will be given to evidence drawn from the experience of groups of people. An Experience Report should be short and to the point: make a claim about how well functional programming worked on your project and why, and produce evidence to substantiate your claim. If functional programming worked for you in the same ways it has worked for others, you need only to summarize the results?the main part of your paper should discuss how well it worked and in what context. Most readers will not want to know all the details of your project and its implementation, but please characterize your project and its context well enough so that readers can judge to what degree your experience is relevant to their own projects. Be especially careful to highlight any unusual aspects of your project. Also keep in mind that specifics about your project are more valuable than generalities about functional programming; for example, it is more valuable to say that your team delivered its software a month ahead of schedule than it is to say that functional programming made your team more productive. If your paper not only describes experience but also presents new technical results, or if your experience refutes cherished beliefs of the functional-programming community, you may be better off submitting it as a full paper, which will be judged by the usual criteria of novelty, originality, and relevance. If you are unsure in which category to submit, the program chair will be happy to help you decide. Organizers ---------- General Co-Chairs: Jacques Garrigue (Nagoya University) Gabriele Keller (University of New South Wales) Program Chair: Eijiro Sumii (Tohoku University) Program Committee: Koen Claessen (Chalmers University of Technology) Joshua Dunfield (University of British Columbia, Canada) Matthew Fluet (Rochester Institute of Technology) Nate Foster (Cornell University) Dan Grossman (University of Washington, USA) Jurriaan Hage (Utrecht University) Roman Leshchinskiy (Standard Chartered Bank) Keisuke Nakano (The University of Electro-Communications) Aleksandar Nanevski (IMDEA Software Institute) Scott Owens (University of Kent) Sungwoo Park (Pohang University of Science and Technology) Amr Sabry (Indiana University) Tom Schrijvers (KU Leuven) Olin Shivers (Northeastern University) Walid Taha (Halmstad University) Dimitrios Vytiniotis (Microsoft Research, Cambridge) David Walker (Princeton University) Nobuko Yoshida (Imperial College London, UK) External Review Committee: See http://conf.researchr.org/committee/icfp-2016/icfp-2016-papers-external-rev….

1 0

Matrices as Applicatives and Monads
by Strikingwolf2012 . 09 Feb '16

09 Feb '16

I have been writing code encoding matrices here <https://github.com/Strikingwolf/Learning/blob/master/haskell/src/math/Matri…> as a learning experience. However, I cannot figure out a method to make Matrix an instance of Applicative and Monad. I believe it is possible, but I cannot find an implementation. For context my form of Matrix does not have a requirement to be of integers, it is just a 2-Dimensional array in essence. Thank you in advance for any help you may provide :)

2 1

[ANN] aeson 0.11.0.0
by Adam Bergmark 08 Feb '16

08 Feb '16

Hi haskellers, As a new co-maintainer of aeson I'm happy to announce aeson 0.11.0.0[1]. v0.10 had a number of issues and v0.11 aims to fix all of these. I'm happy to see that all known regressions have been fixed, and I didn't have to write any code myself! ;) Going 0.9 to 0.11 should be no work for most users. I've built all packages in stackage nightly[2] and out of 222 only one needs a non-trivial change (sorry pagerduty maintainers!) Please help out by letting us know if we missed something, including if something should be added to the CHANGELOG[3]. A big thanks to everyone who contributed code to this release: Bryan O'Sullivan Bas van Dijk Oleg Grenrus Herbert Valerio Riedel Ben Weitzman Daniel Díaz RyanGlScott David Johnson Artyom Cale Gibbard Mikhail Glushenkov Ondrej Palkovsky Tim Bodeit mrkkrp And a thank you to everyone else who helped in other ways! All the best, Adam [1] https://hackage.haskell.org/package/aeson-0.11.0.0 [2] https://github.com/bos/aeson/issues/355 [3] https://github.com/bos/aeson/blob/master/changelog.md

2 1

Pulling an applicative/apply out of a record
by Tyson Whitehead 08 Feb '16

08 Feb '16

Quick question for the experts out there. I need to process some records. The records come in in an unordered stream of record fields. From each stream of fields I want to produce a Record entry containing the fields I need to do my calculation. > data Record = { field1 :: Type1, field2 :: Type2, ... } I was thinking this setup might work nice with something like > data RecordF d = RecordF { field1 :: f Type1, field2 :: f Type2, ... } as I could then have (1) a monoid version I could accumulate use as an accumulator over the stream > type RecordM = RecordF [] and (2) a final version. > type Record = RecordF Identity This final version seems like it should easily come from the later by pulling the [] (or anything else that has the Apply/Applicative structure) to the outside and then taking the head of the resulting list. While I could write the boilerplate to do this, it seems like something I should be able to do more elegantly. The best I have come up with so far is to use the lens package to give me an isomorphism to a tuple. Then I need a uncurried zip for arbitrarily large tuples. Follow this by an isomorphism back. RecordF (f Type1) (f Type2) ... -> (f Type1, f Type2, ....) -> f (Type1, Type2, ...) -> f (Record Type1 Type2 ...) I can't seem to find any uncurried zip implementations for arbitrarily large tuples (or any other way to do this without writing the boilerplate). Am I missing something? Is there a better way to do this? Thanks! -Tyson PS: It seems the Data.Vinyl package has something along these lines with the rtraverse function https://hackage.haskell.org/package/vinyl-0.5.1/docs/Data-Vinyl-Core.html

3 3