August 2015 - Haskell-Cafe

ANN: stack-0.1.3.0
by Emanuel Borsboom 12 Aug '15

12 Aug '15

New release of stack, a build tool. See README <https://github.com/commercialhaskell/stack#how-to-install> for installation and upgrade instructions. Note: on Windows, this version does some trickery with code pages to work around issues with GHC’s output. If you run into any trouble, please report it (see issue #757 <https://github.com/commercialhaskell/stack/issues/757>). Major changes: - Overhauled target parsing, added --test and --bench options #651 <https://github.com/commercialhaskell/stack/issues/651> - For details, see Build commands Wiki page <https://github.com/commercialhaskell/stack/wiki/Build-command> - Detect when a module is compiled but not listed in the cabal file (#32 <https://github.com/commercialhaskell/stack/issues/32>) - A warning is displayed for any modules that should be added to other-modules in the .cabal file - These modules are taken into account when determining whether a package needs to be built - Respect TemplateHaskell addDependentFile dependency changes (#105 <https://github.com/commercialhaskell/stack/issues/105>) - TH dependent files are taken into account when determining whether a package needs to be built. Other enhancements: - Set the HASKELL_DIST_DIR environment variable #524 <https://github.com/commercialhaskell/stack/pull/524> - Track build status of tests and benchmarks #525 <https://github.com/commercialhaskell/stack/issues/525> - --no-run-tests #517 <https://github.com/commercialhaskell/stack/pull/517> - Targets outside of root dir don’t build #366 <https://github.com/commercialhaskell/stack/issues/366> - Upper limit on number of flag combinations to test #543 <https://github.com/commercialhaskell/stack/issues/543> - Fuzzy matching support to give better error messages for close version numbers #504 <https://github.com/commercialhaskell/stack/issues/504> - --local-bin-path global option. Use to change where binaries get placed on a --copy-bins #342 <https://github.com/commercialhaskell/stack/issues/342> - Custom snapshots #111 <https://github.com/commercialhaskell/stack/issues/111> - —force-dirty flag: Force treating all local packages as having dirty files (useful for cases where stack can’t detect a file change) - GHC error messages: display file paths as absolute instead of relative for better editor integration - Add the --copy-bins option #569 <https://github.com/commercialhaskell/stack/issues/569> - Give warnings on unexpected config keys #48 <https://github.com/commercialhaskell/stack/issues/48> - Remove Docker pass-host option - Don’t require cabal-install to upload #313 <https://github.com/commercialhaskell/stack/issues/313> - Generate indexes for all deps and all installed snapshot packages #143 <https://github.com/commercialhaskell/stack/issues/143> - Provide --resolver global option #645 <https://github.com/commercialhaskell/stack/issues/645> - Also supports --resolver nightly, --resolver lts, and --resolver lts-X - Make stack build --flag error when flag or package is unknown #617 <https://github.com/commercialhaskell/stack/issues/617> - Preserve file permissions when unpacking sources #666 <https://github.com/commercialhaskell/stack/pull/666> - stack build etc work outside of a project - list-dependencies command #638 <https://github.com/commercialhaskell/stack/issues/638> - --upgrade-cabal option to stack setup #174 <https://github.com/commercialhaskell/stack/issues/174> - --exec option #651 <https://github.com/commercialhaskell/stack/issues/651> - --only-dependencies implemented correctly #387 <https://github.com/commercialhaskell/stack/issues/387> Bug fixes: - Extensions from the other-extensions field no longer enabled by default #449 <https://github.com/commercialhaskell/stack/issues/449> - Fix: haddock forces rebuild of empty packages #452 <https://github.com/commercialhaskell/stack/issues/452> - Don’t copy over executables excluded by component selection #605 <https://github.com/commercialhaskell/stack/issues/605> - Fix: stack fails on Windows with git package in stack.yaml and no git binary on path #712 <https://github.com/commercialhaskell/stack/issues/712> - Fixed GHCi issue: Specifying explicit package versions (#678) - Fixed GHCi issue: Specifying -odir and -hidir as .stack-work/odir (#529) - Fixed GHCi issue: Specifying A instead of A.ext for modules (#498)

1 0

Final call for papers for IFL 2015
by Jurriaan Hage 11 Aug '15

11 Aug '15

Hello, Please, find below the final call for papers for IFL 2015. Note that the draft submission date has been extended until August 15. Please forward these to anyone you think may be interested. Apologies for any duplicates you may receive. best regards, Jurriaan Hage Publicity Chair of IFL —— IFL 2015 - Call for papers 27th SYMPOSIUM ON IMPLEMENTATION AND APPLICATION OF FUNCTIONAL LANGUAGES - IFL 2015 University of Koblenz-Landau, Koblenz, Germany In cooperation with ACM SIGPLAN September 14-16, 2015 http://ifl2015.wikidot.com/ Scope The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2015 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. Peer-review Following the IFL tradition, IFL 2015 will use a post-symposium review process to produce the formal proceedings. All participants of IFL2015 are invited to submit either a draft paper or an extended abstract describing work to be presented at the symposium. At no time may work submitted to IFL be simultaneously submitted to other venues; submissions must adhere to ACM SIGPLAN's republication policy: http://www.sigplan.org/Resources/Policies/Republication The submissions will be screened by the program committee chair to make sure they are within the scope of IFL, and will appear in the draft proceedings distributed at the symposium. Submissions appearing in the draft proceedings are not peer-reviewed publications. Hence, publications that appear only in the draft proceedings do not count as publication for the ACM SIGPLAN republication policy. After the symposium, authors will be given the opportunity to incorporate the feedback from discussions at the symposium and will be invited to submit a revised full article for the formal review process. From the revised submissions, the program committee will select papers for the formal proceedings considering their correctness, novelty, originality, relevance, significance, and clarity. Important dates August 15: Submission deadline draft papers August 17: Notification of acceptance for presentation August 19: Early registration deadline August 26: Late registration deadline September 7: Submission deadline for pre-symposium proceedings September 14-16: IFL Symposium December 1: Submission deadline for post-symposium proceedings January 15, 2016: Notification of acceptance for post-symposium proceedings March 1, 2016: Camera-ready version for post-symposium proceedings Submission details Prospective authors are encouraged to submit papers or extended abstracts to be published in the draft proceedings and to present them at the symposium. All contributions must be written in English. Papers must adhere to the standard ACM two columns conference format. For the pre-symposium proceedings we adopt a 'weak' page limit of 12 pages. For the post-symposium proceedings the page limit of 12 pages is firm. A suitable document template for LaTeX can be found at: http://www.acm.org/sigs/sigplan/authorInformation.htm Authors submit through EasyChair: https://easychair.org/conferences/?conf=ifl2015 Topics IFL welcomes submissions describing practical and theoretical work as well as submissions describing applications and tools in the context of functional programming. If you are not sure whether your work is appropriate for IFL 2015, please contact the PC chair at rlaemmel(a)acm.org. Topics of interest include, but are not limited to: - language concepts - type systems, type checking, type inferencing - compilation techniques - staged compilation - run-time function specialization - run-time code generation - partial evaluation - (abstract) interpretation - metaprogramming - generic programming - automatic program generation - array processing - concurrent/parallel programming - concurrent/parallel program execution - embedded systems - web applications - (embedded) domain specific languages - security - novel memory management techniques - run-time profiling performance measurements - debugging and tracing - virtual/abstract machine architectures - validation, verification of functional programs - tools and programming techniques - (industrial) applications Peter Landin Prize The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honored article is selected by the program committee based on the submissions received for the formal review process. The prize carries a cash award equivalent to 150 Euros. Programme committee Chair: Ralf Lämmel, University of Koblenz-Landau, Germany - Malgorzata Biernacka, University of Wroclaw, Poland - Laura M. Castro, University of A Coruña, Spain - Martin Erwig, Oregon State University, USA - Dan Ghica, University of Birmingham, UK - Andrew Gill, University of Kansas, USA - Stephan Herhut, Google, USA - Zhenjiang Hu, National Institute of Informatics (NII), Japan - Mauro Jaskelioff, CIFASIS/Universidad Nacional de Rosario, Argentina - Frédéric Jouault, ESEO, France - Oleg Kiselyov, Tohoku University, Japan - Lindsey Kuper, Indiana University, USA - Rita Loogen, Philipps-Universität Marburg, Germany - Akimasa Morihata, University of Tokyo, Japan - Atsushi Ohori, Tohoku University, Japan - Bruno C. D. S. Oliveira, The University of Hong Kong, Hong Kong - Frank Piessens, Katholieke Universiteit Leuven, Belgium - Norman Ramsey, Tufts University, USA - Matthew Roberts, Macquarie University, Australia - Manfred Schmidt-Schauss, Goethe-University Frankfurt, Germany - Simon Thompson, University of Kent, UK - Stephanie Weirich, University of Pennsylvania, USA - Steve Zdancewic, University of Pennsylvania , USA Venue The 27th IFL will be held in association with the Faculty of Computer Science, University of Koblenz-Landau, Campus Koblenz. Koblenz is well connected by train to several international airports. For instance, Koblenz can be reached from Frankfurt by high-speed train ICE within an hour. The modern Koblenz campus is close to the city center and can be reached by foot, bus, or cab. See the website for more information on the venue. Social events The conference attendees are welcome at „Kaffeewirtschaft“ in the historical center of Koblenz on the evening of arrival (Sunday, 13 September). A special reception takes places on Monday in the form of a wine tasting and guided tour at „Weingut Lunnebach“. The conference banquet on Tuesday is held at the historical site „Festung Ehrenbreitstein“ at Restaurant Casino with a wonderful view over the city and the two rivers Rhine and Moselle. - http://www.kaffeewirtschaft.de/ - http://www.weingut-lunnebach.de/ - https://www.cafehahn.de/impressionen_189.html

1 0

Constraints on <$> vs <$!>
by Alexey Egorov 11 Aug '15

11 Aug '15

Hello haskellers, I wonder why <$> and <$!> have different typeclass constraints? (<$>) :: Functor f => (a -> b) -> f a -> f b (<$!>) :: Monad m => (a -> b) -> m a -> m b

6 5

Re: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=`
by Alexey Muranov 11 Aug '15

11 Aug '15

On 9 août 2015, at 15:00, haskell-cafe-request(a)haskell.org wrote: > From: Will Yager <will.yager(a)gmail.com> > Subject: Re: [Haskell-cafe] an idea for modifiyng data/newtype syntax: use `::=` instead of `=` > Date: 9 août 2015 02:30:50 UTC+3 > To: Hilco Wijbenga <hilco.wijbenga(a)gmail.com> > Cc: Haskell Cafe <haskell-cafe(a)haskell.org>, MigMit <miguelimo38(a)yandex.ru> > It is worth asking, then, if we should record these small aesthetic suggestions somewhere for consideration while designing the next major compatibility-breaking release of the Haskell specification (Haskell 2020 or what have you). +1 Alexey.

5 8

Pattern guards in comprehensions
by M Farkas-Dyck 11 Aug '15

11 Aug '15

I propose we add pattern guards in comprehensions, but I'm not sure what syntax would work. Consider this function: allMinus :: [Natural] -> [Natural] allMinus m = mapMaybe (-? m) where n -? m | m > n = Nothing | True = Just (n-m) One may wish to write such as a list comprehension, but it is cumbersome: allMinus m ns = [n' | n@((-? m) -> Just n') <- ns] This would be clearer with pattern guards, fictitious syntax here: allMinus m ns = [n' | n <- ns, Just n' <- n -? m] Alas, this conflicts with the other part of list comprehension syntax. Try we this, actual syntax now: allMinus m ns = [n' | n <- ns, let Just n' = n -? m] Nope, that's an error if (any (< m) ns). I recognize in this case the one in terms of mapMaybe is quite clear, but in the case of some other code I'm writing it's much more complicated. Ideas: 1. Modify semantics of let in comprehension to skip that element on pattern mismatch 2. Use another keyword, e.g. [n' | n <- ns where Just n' <- n -? m] Thoughts?

4 7

New Functional Programming Job Opportunities
by Functional Jobs 10 Aug '15

10 Aug '15

Here are some functional programming job opportunities that were posted recently: Software Engineer / Researcher at Galois Inc. http://functionaljobs.com/jobs/8856-software-engineer-researcher-at-galois-… Cheers, Sean Murphy FunctionalJobs.com

1 0

Appropriate location for list of language suggestions
by Will Yager 10 Aug '15

10 Aug '15

This email is in response to the (ongoing) Haskell-cafe discussion about type declaration syntax. There are a number of hypothetical changes to Haskell that could be aesthetically pleasing or convenient if implemented, but not to such a degree that the added convenience outweighs the added complexity of a pragma-gated feature or the cost of breaking existing code. (Case in point: renaming type/newtype/data to be less confusing to first-time users) However, there may be better opportunities to implement such changes in the future, and it would be a shame if every good (but perhaps somewhat trivial) idea was lost to the annals of the mailing list. Therefore, I proposed that we might maintain a list of nitpicks, which could be used to inform future decisions about breaking changes to the Haskell specification. I'm not sure what the most appropriate forum is for such a list. The mailing list is sub-optimal, because we might end up with a huge email chain littered with bikeshedding reply-alls. I would be willing to host and maintain such a list on Github, but that seems somewhat antithetical to the Haskell community's generally more distributed style of discussion. The wiki might be appropriate, but I don't know if it's conducive to proper moderation; we may have to filter out suggestions like "add for loops". --Will

3 2

monads, memoization etc
by Ilya Razenshteyn 10 Aug '15

10 Aug '15

Hi everyone, I'm new to Haskell and decided to learn a bit about monads and their utility. Actually, what worked nicely for me was: to read first several pages from "Computational lambda-calculus and monads", then do exercises from https://tonymorris.github.io/blog/posts/20-intermediate-haskell-exercises/, and then map these exercises to actual functions in the standard library. Then, I decided to implement memoization to practice a bit with ST, HashTable's and such. Here is what I managed to get: http://pastebin.com/79pwjLPL . This code computes Fibonacci numbers while caching the intermediate values in a hash table. I tried to make the code as fast as possible (it runs in under 15 seconds, when computing 1M'th Fibonacci number modulo 999983). It uses the package hashtables. I have several question about all this. First, is there a cheap way to speed this code up? Note that I'm interested in a universal memoization strategy, that is I don't want to use arrays instead of hash tables etc. Second, is this code the right way of doing what it does (assuming that I really care about the performance)? Third question. Currently, the code passes "cache" everywhere. It would be natural to combine ST with something like ReaderT to store it there. What is a way to do it? I tried something like "ReaderT (HashTable s) (ST s) Int", but I have not managed to get it work.

3 5

Re: [Haskell-cafe] Serialize to Haskell
by Corentin Dupont 08 Aug '15

08 Aug '15

Hi Matthew, yes that's exactly that. I want to do exactly what you would do with a JSON file (read, write), but with a data format that would be valid Haskell (instead of valid javascript). On Fri, Aug 7, 2015 at 8:06 PM, Matthew Pickering < matthewtpickering(a)gmail.com> wrote: > Hi Corentin, > > I don't quite understand your question please can you explain a bit > more. Do you want to read a valid haskell source file, perform some > changes to the file and then print out a valid source file? > > I am a bit confused about the bit about turing-completeness. > > Matt > > On Fri, Aug 7, 2015 at 7:55 PM, Corentin Dupont > <corentin.dupont(a)gmail.com> wrote: > > Hello! > > I'm wondering if it's possible to serialize some data to a format that is > > valid Haskell. > > In practice I would read a file like this: > > > > module Foo where > > > > myData :: MyData > > myData = MyData {name = "foo", > > descr = "test" > > ... > > } > > > > Reading this into a program is easily feasible with Hint, for example. > Then > > the program would modify some data and serialize it back to: > > > > module Foo where > > > > myData :: MyData > > myData = MyData {name = "bar", > > descr = "test2" > > ... > > } > > > > In practice I think that the format should be a subset of Haskell that is > > not Turing-complete. > > A bit like JSON, which is a subset of Javascript but not Turing complete. > > Is it possible? > > > > Thanks, > > Corentin > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe(a)haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > >

4 5

Waiting for async exception (and nothing else)
by David Turner 08 Aug '15

08 Aug '15

Hi, Is there an elegant way to have a thread wait for an async exception but nothing else? I tend to do something like forever $ threadDelay 1000000000 but this seems like a bit of a hack. Waiting on an otherwise-unused MVar or doing 'atomically retry' don't work because GHC kills them off straight away. The context is when using an API that only has a 'withMyThingy' wrapper and no explicit openMyThingy and closeMyThingy alternatives. Perhaps that's an API problem and the only way to work around this is with something a bit hacky? Cheers,

3 4