- Haskell-Cafe - Haskell.org

ANN: network-2.6.3.6
by evan＠evan-borden.com 07 Jul '18

07 Jul '18

Announcing network-2.6.3.6 This is a bug fix release for the 2.6 branch of network. * Removed unnecessary withMVar, which caused locking on close. [#330](https://github.com/haskell/network/pull/330) Thank you to network contributors for finding and diagnosing the bug. -- Evan Borden

1 0

[GSoC 2018] Benchmarking Haskell graph libraries
by Alexandre Moine 06 Jul '18

06 Jul '18

[ Results are here: https://github.com/haskell-perf/graphs/tree/master/results/ ] Hi, I am french 2nd year student in maths and computer sciences and I am running a {Google,Haskell} Summer of Code now. One of my goals is to write a benchmarking suite for graphs libraries in Haskell (Fgl, Alga, Containers and Hash-Graph) and I reached a state where I can produce reasonable numbers. If you are interested, I have wrote a little blog article explaining the results I obtained: https://blog.nyarlathotep.one/2018/07/benchmarking-haskell-graph-libraries/ Feel free to comment or to send feedback on the Github :) -- Alexandre Moine

1 0

Bool is not...safe?!
by PY 06 Jul '18

06 Jul '18

Hello, Cafe! There is an opinion that Bool type has problems. It's "dangerous", because it's not good to be used as flag for success/fail result. I read this post: https://existentialtype.wordpress.com/2011/03/15/boolean-blindness/ and was shocked. How popular is such opinion? Is it true, that bool is "bad" type? As I understand arguments of the post, Bool is bad because: 1) you don't know what does True/False mean 2) after comparison you get bit (!) only but then you may need to "recover" the comparing value which was "shrink" to bit already. Let's begin from 2. As I understand the author talks about one register computers ;) if he have to "recover" a value. But shown examples are in ML, where function arguments are bound to all function body, so you don't need to "recover" anything, what was bound as function argument or with "let". Sounds totally weird and more close to psychology than to CS :) Argument #1 is more interesting. A Boolean,/b/, is either*true*, or *false*; that’s it. There is no/information/carried by a Boolean beyond its value, and that’s the rub. As Conor McBride puts it, to make use of a Boolean you have to know its/provenance/so that you can know what it/means./ Really, what does True/False mean? How to find semantic of True? It's very simple, because there is A) contract/interface which interprets True/False and also B) there is a help from science. A) There are a lot of languages (Unix shell, ML, Basic, Haskell, C/C++...) with short-circuit expressions. Ex., e1 || e2 e1 && e2 e1 orelse e2 where interface is described by its operations: ||, &&, orelse, etc and it has absolutely accurate and clear meaning: "||" executes e2 iff e1 *fails, was not success*. "&&" executes e2 iff e1 was succeeded. I don't use words "True" and "False". Because, in different languages marker of success/fail is different. For example, in Bash, the fail is any integer except 0. In Haskell fail is False. In C is 0... What does mean False (and True) is defined by contract/interface of short-circuit operations, related to boolean algebra. A rare case when type is bound with semantic! We read them literally (native English): e1 or-else e2! *This means that using of False to indicate success - is error! And no way to miss provenance/knowledge what True or False means.* (the same: what does Right/False mean?) B) The help from science. Math (and CS) has own history. And one of its mail-stones was birth of formal logic and then of Boolean algebra. CS implemented those in declarative languages (Prolog, for example). If we have some predicate in Prolog, "true" for that predicate means "it was achieved", as goal. If that predicate has side-effects, "true" means it was achieved, i.e. all its steps (side-effects) were successfully executed. Predicate write_text_to_file/2 is "true" when it wrote text to file. And no way to return False on success or to think about sacral sense of True/False :) And that sense traditionally is the same in all programming language. If you invert it, you deny contract, semantic and begin to use "inverted" logic :) We can repeat the same logic with 3.1415926.. What does it mean? Meaning, semantic is described, but contract/interface: this magic irrational was born from part of algebra, called trigonometry. And this algebra defines semantic of Pi, not programmer's usage of Pi, programming context, etc. True/False semantic is defining by its algebra: boolean. So, programmer should not change their semantic, am I right? So, my question is: is this post a april 1st trolling or author was serious? :) --- Best regards, Paul

7 9

Measuring memory usage
by Vlatko Basic 04 Jul '18

04 Jul '18

Hello, I've come to some strange results using Weigh package. It shows that HashMap inside 'data' is using much, much more memory. The strange thing is that I'm seeing too large mem usage in my app as well (several "MapData" like in records), and trying to figure out with 'weigh' what's keeping the mem. Noticed that when I change the code to use HashMap directly (not inside 'data', that's the only change), the mem usage observed with top drops down for ~60M, from 850M to 790M. These are the test results for 10K, 5K and 3.3K items for "data MapData k v = MapData (HashMap k v)" (at the end is the full runnable example.) Case Allocated GCs HashMap 262,824 0 HashMap half 58,536 0 HashMap third 17,064 0 MapData 4,242,208 4 I tested by changing the order, disabling all but one etc., and the results were the same. Same 'weigh' behaviour with IntMap and Map. So, if anyone knows and has some experience with such issues, my questions are: 1. Is 'weigh' package reliable/usable, at least to some extent? (the results do show diff between full, half and third) 2. How do you measure mem consumptions of your large data/records? 3. If the results are even approximately valid, what could cause such large discrepancies with 'data'? 4. Is there a way to see if some record has been freed from memory, GCed? module Main where import Prelude import Control.DeepSeq (NFData) import Data.HashMap.Strict (HashMap, fromList) import GHC.Generics (Generic) import Weigh (mainWith, value) data MapData k v = MapData (HashMap k v) deriving Generic instance (NFData k, NFData v) => NFData (MapData k v) full, half, third :: Int full = 10000 half = 5000 third = 3333 main :: IO () main = mainWith $ do value "HashMap" ( mkHMList full) value "HashMap half" ( mkHMList half) value "HashMap third" ( mkHMList third) value "MapData" (MapData $ mkHMList full) mkHMList :: Int -> HashMap Int String mkHMList n = fromList . zip [1..n] $ replicate n "some text"

4 8

Typechecker Plugin Constraint Solving
by Armin Wurzinger 04 Jul '18

04 Jul '18

Good day, I am currently developing a typechecker plugin for GHC for realizing an idea regarding types based on regular expressions to describe the contents of a string. This is done using type-level literals to denote a particular regex. Additionally there are additional constraints for working with such types. One of those constraints is called Intersectable and denotes whether an intersection between two regexes would be possible in the sense that there is some common alphabet between them. Furthermore there is a type-level function that calculates the actual intersection between two regex types and returns the resulting regex type: type family Intersectable (a :: Symbol) (b :: Symbol) :: Constraint type family Intersection (a :: Symbol) (b :: Symbol) :: Symbol Now i've created a typechecker plugin that resolves such constraints by using a finite-automata representation of the regexes to do the actual work. While my plugin is already able to proof progams where regexes are fully applied, i.e. they can reduce terms to a single regex and then verify the constraints accordingly or reject them, it fails to type "intermediate" functions. As a small example assume the following program: checkFour :: Intersectable a "[0-4]" => RgxString a -> RgxString (Intersection a "[0-4]") checkFour a = undefined checkEight :: Intersectable a "[0-8]" => RgxString a -> RgxString (Intersection a "[0-8]") checkEight a = undefined test = checkFour . checkEight -- this fails to type correctly test2 = checkFour $ checkEight $ (RgxString :: RegexString ".*") -- this works fine The constraint solver wants me to proof the following constraints for test: tcPluginSolve given = [] derived = [] wanted = [ [WD] irred_a2GV {0}:: Intersectable (Intersection a0 "[0-8]") "[0-4]" (CNonCanonical), [WD] irred_a2GY {0}:: Intersectable a0 "[0-8]" (CNonCanonical)] My plugin reduces the first constraint to Intersectable a0 [0-4] as regex intersection is commutative so i can intersect [0-8] with [0-4] first. But i haven't found out yet how i would tell the compiler to put this reduced constraint to the type signature instead of the current one where the constraint got dropped at all instead of at least remain unnormalized, and the return type remains unnormalized as well: RgxString a -> RgxString (Intersection (Intersection a "[0-8]") "[0-4]") I'd need to tell the typechecker somehow that (Intersection (Intersection a "[0-8]") "[0-4]") is equal to Intersection a "[0-4]" so it substitutes it accordingly. My idea is that i have to generate given type and function equality constraints during the typechecking telling it that those representations are equal, but i am really not sure what kind of constraints i need. CTyEqCan for instance seems to require a TyVar on one side while i though i could generate something like Intersection (Intersection a "[0-8]") "[0-4]" ~ Intersection a "[0-4]" I have already tried a lot but there is little documentation on the whole constraint solving process and i am slowly getting stuck. Thanks for helping!

1 0

ForeignPtrs, Finalizers and thread-local storage
by Justin Paston-Cooper 03 Jul '18

03 Jul '18

glpk-hs defines a binding to glpk, a linear programme library. A linear programme is created by calling `glp_create_prob` and deleted by calling `glp_delete_prob`. These two C functions manage memory themselves using thread-local storage. They are called by glpk-hs using the foreign function interface in the following code. Note that glpDelProb and glpCreateProb are imported foreign functions. runGLPK :: GLPK a -> IO a runGLPK m = do lp <- newForeignPtr glpDelProb =<< glpCreateProb withForeignPtr lp (execGLPK m) ( https://github.com/jyp/glpk-hs/blob/master/src/Data/LinearProgram/GLPK/Type… ) It seems that sometimes the finaliser is called in a thread different to the one where glp_create_prob is called. This leads to glpk aborting with a dynamic memory allocation error when tries to de-allocate the linear programme in the wrong thread-local storage, which has never seen that programme. Given that the ForeignPtr is used only in runGLPK, runGLPK could of course be fixed by using Control.Concurrent.bracket instead. However, I'm interested to know whether there is a solution to this problem. I'm only assuming that the finaliser sometimes runs in a different thread. If this is indeed the case, then is there any way to ensure that a finaliser runs in the thread where the pointer is created?

1 1

GHC's timing: Now solid enough for music?
by Jeffrey Brown 03 Jul '18

03 Jul '18

I just discovered Tom Murphy's Vivid-Synth[1], a Haskell library that lets you control SuperCollider. (A few very slight changes allowed me to get it to work in Stack instead of Cabal, as described here[2,3].) TidalCycles[4] also controls SuperCollider from Haskell. It does tortuous backflips to hand the timing job over to SuperCollider. If I recall correctly, that was because SC's timing was more solid than Haskell's. I modified the Vivid demo to go faster and have a few more voices[5], and tried running it at the same time as Spotify and Youtube and apt upgrade and loading LibreOffice and playing some music in VLC, and I detected (by ear) no timing errors. Can I expect GHC's maybe-new rhythmic stability to hold up? [1] http://www.vivid-synth.com/ [2] https://github.com/vivid-synth/vivid/issues/5 [3] https://github.com/JeffreyBenjaminBrown/vivid/commit/3d25266d4495d9dd8e573f… [4] https://tidalcycles.org/ [5] https://github.com/JeffreyBenjaminBrown/vivid/blob/jbb/jbb/sine.hs -- Jeff Brown | Jeffrey Benjamin Brown Website <https://msu.edu/~brown202/> | Facebook <https://www.facebook.com/mejeff.younotjeff> | LinkedIn <https://www.linkedin.com/in/jeffreybenjaminbrown>(spammy, so I often miss messages here) | Github <https://github.com/jeffreybenjaminbrown>

3 2

ANN: hledger-1.10
by Simon Michael 02 Jul '18

02 Jul '18

hledger (http://hledger.org) is a friendly, robust, cross-platform program for tracking money, time or other commodities, using double-entry accounting, simple plain text file formats, and command-line, curses or web UIs. I'm very pleased to announce hledger 1.10, including work by release contributors: Alex Chen, Everett Hildenbrandt, Jakub Zárybnický, Nolan Darilek, Dmitry Astapov, Jacob Weisz, Peter Simons, Stephen Morgan, Pavlo Kerestey, Trevor Riles, Léo Gaspard, Mykola Orliuk, Wad, Nana Amfo. You'll note this is not 2.0 as previously planned - we will spend a bit more time on that. The next major release is expected to be on 2018/09/30. Please see http://hledger.org/release-notes#hledger-1.10 for the changes (as soon as I can get to those; until then, the package changelogs): http://hackage.haskell.org/package/hledger-1.10/changelog http://hackage.haskell.org/package/hledger-ui-1.10/changelog http://hackage.haskell.org/package/hledger-web-1.10/changelog http://hackage.haskell.org/package/hledger-api-1.10/changelog http://hackage.haskell.org/package/hledger-lib-1.10/changelog How to get started: ------------------- See http://hledger.org/download for all install methods. One of the easiest is the hledger-install script, which requires only bash and will build and install the hledger tools in $HOME/.local/bin/: $ curl -O https://raw.githubusercontent.com/simonmichael/hledger/master/hledger-insta… $ less hledger-install.sh # (do security review) $ bash hledger-install.sh # (add -v for more detail; use bash -x to show commands being run) or (insecure): $ curl https://raw.githubusercontent.com/simonmichael/hledger/master/hledger-insta… | bash After installation, ensure $HOME/.local/bin is in your $PATH, and try some commands: $ hledger -h # quick help $ hledger help # list built-in manuals $ hledger add # record some transactions $ hledger # list available commands Next, I encourage you to at least skim the tutorials and docs at http://hledger.org. Say hello and ask questions in the #hledger IRC channel on Freenode: http://irc.hledger.org. New users and contributors are always welcome! Give feedback, report bugs, send pull requests, write, evangelise, donate. Best! -Simon

1 1

2nd Call for Talks -- Haskell Implementors' Workshop
by Joachim Breitner 02 Jul '18

02 Jul '18

Call for Contributions ACM SIGPLAN Haskell Implementors’ Workshop https://icfp18.sigplan.org/track/hiw-2018-papers Co-located with ICFP 2018 St. Louis, Missouri, US https://conf.researchr.org/home/icfp-2018 Important dates --------------- Proposal Deadline: Friday, 20 July, 2018 Notification: Friday, 3 August, 2018 Workshop: Sunday, 23 September, 2018 Keynote speaker --------------- This year, the Haskell Implementors’ Workshop is proud to present Rahul Muttineni as the keynote speaker. Rahul brough the joys of Haskell to the realm of Java by creating the Eta programming language. Title: Let's Go Mainstream with Eta! Eta is a fork of GHC that focuses on three core principles: user experience, performance, and safety. We'll discuss how we used these principles to guide the re-implementation of the GHC runtime and code generator on the JVM. Moreover, will also cover the inner workings of the FFI and the typechecker support we added for subtyping to make it smooth to interact with Java libraries. Finally, we'll round out with a look at where Eta is headed and how Eta and GHC can collaborate in the future. About the Haskell Implementors’ Workshop ---------------------------------------- The 10th Haskell Implementors’ Workshop is to be held alongside ICFP 2018 this year in St. Louis. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure, to share their work and discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings. The workshop will be informal and interactive, with open spaces in the timetable and room for ad-hoc discussion, demos and lightning talks. Scope and Target Audience ------------------------- It is important to distinguish the Haskell Implementors’ Workshop from the Haskell Symposium which is also co-located with ICFP 2018. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors’ Workshop will have no proceedings – although we will aim to make talk videos, slides and presented data available with the consent of the speakers. The Implementors’ Workshop is an ideal place to describe a Haskell extension, describe works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. Members of the wider Haskell community encouraged to attend the workshop – we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are specially encouraged to share their work. The scope covers any of the following topics. There may be some topics that people feel we’ve missed, so by all means submit a proposal even if it doesn’t fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Talks ----- We invite proposals from potential speakers for talks and demonstrations. We are aiming for 20-minute talks with 5 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions can be made via HotCRP at https://icfp-hiw18.hotcrp.com/ until July 20th (anywhere on earth). We will also have lightning talks session. These have been very well received in recent years, and we aim to increase the time available to them. Lightning talks be ~7mins and are scheduled on the day of the workshop. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Program Committee ----------------- * Edwin Brady (University of St. Andrews, UK) * Joachim Breitner – chair (University of Pennsylvania) * Ben Gamari (Well-Typed LLP) * Michael Hanus (Kiel University) * Roman Leshchinsky (Facebook) * Niki Vazou (University of Maryland) Contact ------- * Joachim Breitner <joachim(a)cis.upenn.edu> -- Joachim Breitner Post-Doctoral researcher http://cis.upenn.edu/~joachim

1 0

Re: [Haskell-cafe] [ANNOUNCE] GHC 8.6.1-alpha1 available
by Ben Gamari 02 Jul '18

02 Jul '18

George Colpitts <george.colpitts(a)gmail.com> writes: > I don't see an apple/darwin binary. Not sure if that is an oversight or was > planned. > Yikes! Thank you for mentioning this. This is indeed a mistake. I'm uploading the Darwin distribution right now; it will be done within 20 minutes. Cheers, - Ben

1 0

[ANNOUNCE] GHC 8.6.1-alpha1 available
by Ben Gamari 01 Jul '18

01 Jul '18

The GHC development team is pleased to announce the first alpha release leading up to GHC 8.6.1. The usual release artifacts are available from https://downloads.haskell.org/~ghc/8.6.1-alpha1 This is the first release (partially) generated using our new CI infrastructure. One known issue is that the haddock documentation is currently unavailable. This will be fixed in the next alpha release. Do let us know if you spot anything else amiss. As always, do let us know if you encounter any trouble in the course of testing. Thanks for your help! Cheers, - Ben

4 6

need help understanding how to specify constraints on monads
by Dennis Raddle 29 Jun '18

29 Jun '18

I'm writing a program with several functions, some of which depend on certain fields in a state monad, others of which depend on others, but no routine needs all the fields. So I thought I would declare a two classes, one for each type of data need that a function has: -- as an aside, here's an example of data which is parameterized by two types. data ReportData t1 t2 = ... -- this is rolling my own state monad with a random generator class Monad m => RandMonad m where getGen :: m StdGen putGen :: StdGen -> () -- this is a class of state monad which logs ReportData: class Monad m => LogMonad m where putReport :: ReportData t1 t2 -> m () For a particular use case, I declare a type of State monad: data MyStateData t1 t2 = MyStateData t1 t2 { theGen :: StdGen , theReports :: [StepReport t1 t2] } type MyState t1 t2 = State (MyStateData t1 t2) And I try to define my instances: instance RandMonad (MyState t1 t2) where getGen = gets theGen putGen g = modify (\s -> s { theGen = g}) instance LogMonad (MyState t1 t2) where putReport r = modify (\s -> s { theReports = r : theReports s}) I get an error on the LogMonad instance, saying that there's no instance for (MonadState (MyState t1 t2) (StateT (MyState t1 t2) Identity)) I guess I don't really understand typeclasses once you start using higher kinded types, so please enlighten me. Any reading on this subject would be helpful, too.

5 12

(New to Conduits) mixing lazy lists and Conduits?
by Jon Fairbairn 29 Jun '18

29 Jun '18

Suppose I’m writing some code using Conduits, but need to use some old function f::[a]->[b] (defined in a library somewhere) that transforms a lazy list. Is there a way of turning f into a Conduit without ending up with all of the list being in memory? ie something that looks like toConduit:: ([a]->[b]) -> ConduitT a b m () I’ve got nowhere with Hoogle or Hayoo -- Jón Fairbairn Jon.Fairbairn(a)cl.cam.ac.uk

3 7

Re: [Haskell-cafe] Lattice and calculation of Least Upper Bounds
by Olaf Klinke 29 Jun '18

29 Jun '18

Aaron, the lattices package provides some modules to extend a given lattice by some elements, e.g. new top and bottoms. There are also derived typeclass instances for combinations like tuples, endomorphisms and so forth. But the way of choice really depends on what you know about your multiple inheritance hierarchy. In universal algebra one powerful method of constructing (semi-)lattices is by generators and relations. That means you define the lattice as a quotient of a free lattice. The quotient itself is defined as a set of ineqalities on the generators. I don't know how one would implement that without dependent types, though, as the type would be another type together with a function. To make things worse, the word problem is undecidable in general. Looking at Algebra.Lattice.Free I'm surprised that the free (semi-)lattice types don't have a Monad instance. Does anyone know why they are not implemented? Under the hood the free lattice types are identical to the continuation monad. Olaf >Hi, > >I am trying to work out how to use the Algebra.Lattice family of Lattice >data structures. > >Firstly how do I construct a lattice ? > >What I am wanting to do is to be able to construct a lattice to represent a >multiple inheritance hierarchy. Then I to be able to find the Least Upper >Bound of a set of classes/types. This is in order to find the type of a >multiple case expression. > >I am not sure if the Haskell classes are actually applicable ? but if they >are how do I apply them to the following problem please ?

3 3

Deadline extension for FARM 2018 (now July 8) - Workshop on Functional Art, Music, Modelling, and Design
by Brent Yorgey 28 Jun '18

28 Jun '18

The FARM submission deadline for papers and demo proposals has been extended to July 8 (the same as the performance submission deadline). 6th ACM SIGPLAN International Workshop on Functional Art, Music, Modelling and Design St. Louis, Missouri, USA, September 29th 2018 Call for Papers and Performances Key Dates ========= Paper submission deadline (extended) July 8 Performance submission deadline July 8 Author Notification July 21 Camera Ready August 5 Workshop September 29 About FARM ========== The ACM SIGPLAN International Workshop on Functional Art, Music, Modelling and Design (FARM) gathers together people who are harnessing functional techniques in the pursuit of creativity and expression. It is co-located with ICFP 2018, the 23rd ACM SIGPLAN International Conference on Functional Programming, and with Strange Loop, in St. Louis, Missouri, USA. Functional Programming has emerged as a mainstream software development paradigm, and its artistic and creative use is booming. A growing number of software toolkits, frameworks and environments for art, music and design now employ functional programming languages and techniques. FARM is a forum for exploration and critical evaluation of these developments, for example to consider potential benefits of greater consistency, tersity, and closer mapping to a problem domain. FARM encourages submissions from across art, craft and design, including textiles, visual art, music, 3D sculpture, animation, GUIs, video games, 3D printing and architectural models, choreography, poetry, and even VLSI layouts, GPU configurations, or mechanical engineering designs. Theoretical foundations, language design, implementation issues, and applications in industry or the arts are all within the scope of the workshop. The language used need not be purely functional (“mostly functional” is fine), and may be manifested as a domain specific language or tool. Moreover, submissions focusing on questions or issues about the use of functional programming are within the scope. FARM 2018 website : http://functional-art.org/2018/ Call for Performances ===================== Submission deadline: July 8, 2018. Submission URL: https://easychair.org/conferences/?conf=farm2018 . FARM also hosts a traditional evening of performances. For this year’s event, FARM 2018 is seeking proposals for live performances which employ functional programming techniques, in whole or in part. We would like to support a diverse range of performing arts, including music, dance, video animation, and performance art. We encourage both risk-taking proposals which push forward the state of the art and refined presentations of highly-developed practice. In either case, please support your submission with a clear description of your performance including how your performance employs functional programming and a discussion of influences and prior art as appropriate. Call for Papers and Demos ========================= Submission deadline (extended): July 8 Submission URL: https://easychair.org/conferences/?conf=farm2018 . We welcome submissions from academic, professional, and independent programmers and artists. Submissions are invited in three categories: 1) Original papers We solicit original papers in the following categories: - Original research - Overview / state of the art - Technology tutorial All submissions must propose an original contribution to the FARM theme. FARM is an interdisciplinary conference, so a wide range of approaches are encouraged. An original paper should have 5 to 12 pages, be in portable document format (PDF), using the ACM SIGPLAN style guidelines and the ACM SIGPLAN template. [ http://www.sigplan.org/Resources/Author/ -- use the 'sigplan' sub-format. ] Accepted papers will be published in the ACM Digital Library as part of the FARM 2018 proceedings. See http://authors.acm.org/main.cfm for information on the options available to authors. Authors are encouraged to submit auxiliary material for publication along with their paper (source code, data, videos, images, etc.); authors retain all rights to the auxiliary material. 2) Demo proposals Demo proposals should describe a demonstration to be given at the FARM workshop and its context, connecting it with the themes of FARM. A demo could be in the form of a short (10-20 minute) tutorial, presentation of work-in-progress, an exhibition of some work, or even a performance. Demo proposals should be in plain text, HTML or Markdown format, and not exceed 2000 words. A demo proposal should be clearly marked as such, by prepending Demo Proposal: to the title. Demo proposals will be published on the FARM website. A summary of the demo performances will also be published as part of the conference proceedings, to be prepared by the program chair. 3) Calls for collaboration Calls for collaboration should describe a need for technology or expertise related to the FARM theme. Examples may include but are not restricted to: - art projects in need of realization - existing software or hardware that may benefit from functional programming - unfinished projects in need of inspiration Calls for collaboration should be in plain text, HTML or Markdown format, and not exceed 5000 words. A call for collaboration should be clearly marked as such, by prepending Call for Collaboration: to the title. Calls for collaboration will be published on the FARM website. 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. All presentations at FARM 2018 will be recorded. Permission to publish the resulting video (in all probability on YouTube, along with the videos of ICFP itself and the other ICFP-colocated events) will be requested on-site. Questions ========= If you have any questions about what type of contributions that might be suitable, or anything else regarding submission or the workshop itself, please contact the organisers at: farm-2018(a)functional-art.org Workshop Organization ==================== Brent Yorgey (general chair) Donya Quick (program chair) Tom Murphy (performance chair) Program Committee ================= Heinrich Apfelmus (self-employed) Chuck Jee Chau (Hong Kong University of Science and Technology, Hong Kong) Brian Heim (Yale, USA) Can Ince (ince.io) Chris Martens (NC State University, USA) Eduardo Miranda (University of Plymouth, UK) Ivan Perez Dominguez (University of Nottingham, UK) Iris Ren (Utrecht University, Netherlands) Henning Thielemann (self-employed) Didier Verna (EPITA, France) Dan Winograd-Cort (Target, USA) Halley Young (University of Pennsylvania, USA) Code of Conduct =============== FARM adheres to ICFP 2018's Code of Conduct: http://icfp18.sigplan.org/attending/code-of-conduct

1 0

Alternative Preludes
by Hilco Wijbenga 28 Jun '18

28 Jun '18

Hi all, I've been looking for a different Prelude to, at minimum, default to Text instead of String but I'm sure there are other things that would be helpful. E.g., less focus on lists. I had a look at [1] and protolude, classy-prelude, basic-prelude, foundation, safe-prelude, and rio all seem interesting. Maybe even base-noprelude? I'm an advanced beginner (I don't think I qualify as intermediate yet). Going by [1], classy-prelude might not be such a good idea because of "scary error messages". And, I'm guessing, I would need to know Haskell better to take advantage of base-noprelude? I would like to know your thoughts/suggestions/opinions/ideas. Also, if there are other preludes that might be of interest, do tell! Cheers, Hilco [1] https://guide.aelve.com/haskell/alternative-preludes-zr69k1hc

5 4

Call for Presentations and Demonstrations: Workshop on Functional High-Performance Computing 2018 at ICFP
by Kei Davis 25 Jun '18

25 Jun '18

7th ACM SIGPLAN Workshop on Functional High-Performance Computing September 29, 2018, St. Louis, Missouri, USA https://icfp18.sigplan.org/track/FHPC-2018-papers The 7th ACM SIGPLAN Workshop on Functional High-Performance Computing (FHPC 2018) is being held as in previous years in conjunction with the International Conference on Functional Programming (ICFP 2018) together with numerous other workshops/symposia, and as a first, colocated with Strange Loop, in St. Louis, MO, USA. Workshop Objectives The FHPC 2018 workshop seeks to bring together researchers and practitioners exploring uses of functional (or more generally, declarative or high-level) programming systems or concepts in application domains where high performance is essential. The aim of the meeting is to enable sharing of results, experiences, and novel ideas about how high-level, declarative specifications of computationally challenging problems can serve as maintainable and portable code that approaches (or even exceeds) the performance of machine-oriented (low-level) imperative implementations. All aspects of performance-critical programming and parallel programming are in scope for the workshop, irrespective of hardware target. This includes both traditional large-scale distributed-memory scientific computing (HPC), as well as work targeting single node systems with SMPs, GPUs, FPGAs, or embedded processors. FHPC 2018 seeks to encourage a range of submissions, focusing on work in progress and facilitating early exchange of ideas and open discussion on innovative and/or emerging results. Original research, experience reports, case studies, and evaluations of programming systems are all welcome. Work on incorporation of functional programming concepts into more traditional (imperative) HPC applications is explicitly solicited. Papers, Presentations, and Demonstrations The refereed paper deadline has passed. In the workshop spirit, the refereed paper presentation program is being augmented to include less formally reviewed presentations in the form of talks not based on accepted papers, and software demonstrations. Topic areas of interest include research or development in progress, experience reports, and position/white paper statements. Proposals will be subject to a mild reviewing process to insure relevance and general interest to FHPC. We expect time slots to be between one-half and one hour. Prospective presenters are requested to submit an abstract describing their proposed contribution via the paper submission site. The deadline is July 29, 2018, midnight anywhere on Earth, but the PC reserves the right to accept proposals at any time after submission. As such, early submission is strongly encouraged. Important Dates - Submission Deadline: Midnight July 29, 2018 Anywhere on Earth. - Notification: early-mid August (TBD) - FHPC 2018: Saturday Sept. 29, 2018. Official website, submissions, registration details https://icfp18.sigplan.org/track/FHPC-2018-papers Previous FHPC websites https://icfp17.sigplan.org/track/FHPC-2017-papers https://sites.google.com/site/fhpcworkshops/ ICFP and related workshops https://conf.researchr.org/home/icfp-2018 https://icfp18.sigplan.org Strange Loop https://www.thestrangeloop.com/ Questions or comments? fhpc18(a)gmail.com

1 0

ANN: network-2.7.0.1
by evan＠evan-borden.com 24 Jun '18

24 Jun '18

Announcing network-2.7.0.1 * A new API: socketPortSafe. [#319](https://github.com/haskell/network/pull/319) * Fixing a drain bug of sendAll. [#320](https://github.com/haskell/network/pull/320) * Porting the new CALLCONV convention from master. [#313](https://github.com/haskell/network/pull/313) * Withdrawing the deprecations of packFamily and unpackFamily. [#324](https://github.com/haskell/network/pull/324) Thank you to network contributors for bug reports in the push to 3.0.0.0. As well as the continued effort to increase windows reliability and support. -- Evan Borden

1 0

Munich Haskell Meeting, 2018-06-26 @ 19:30
by Leah Neukirchen 23 Jun '18

23 Jun '18

Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Tuesday, June 26 at Cafe Puck at 19h30. For details see here: http://muenchen.haskell.bayern/dates.html If you plan to join, please add yourself to this dudle so we can reserve enough seats! It is OK to add yourself to the dudle anonymously or pseudonymously. https://dudle.inf.tu-dresden.de/haskell-munich-jun-2018/ Everybody is welcome! cu, -- Leah Neukirchen <leah(a)vuxu.org> http://leah.zone

1 0

Colored Haskell Listings in LaTeX
by Artem Pelenitsyn 23 Jun '18

23 Jun '18

Dear Cafe, In his recent Stitch manuscript, https://cs.brynmawr.edu/~rae/papers/2018/stitch/stitch.pdf Richard Eisenberg mentions that he uses lhs2TeX to typeset Haskell listings, but I'm not aware of the support for colors in lhs2TeX. Can anyone suggest how to get such a nice code highlighting (presumably with lhs2TeX). -- Best wishes, Artem

3 4

Type level seq
by Benjamin Franksen 23 Jun '18

23 Jun '18

I have observed that type functions seem to be lazy. A type function that is partial does not give me a type error when it is called with an argument for which it is not defined. Is there a 'seq' at the type level? Here is my use case, simplified of course. Suppose we want to statically track the state of a switch with a phantom type parameter: > {-# LANGUAGE DataKinds, TypeFamilies #-} > > data State (s :: Bool) = State Bool deriving Show > > off :: State False > off = State False We want user code to be able to call the function 'turnOff' only if the switch is currently on: > turnOff :: State True -> State False > turnOff (State True) = State False This works fine: *Main> turnOff off <interactive>:1:9: error: ? Couldn't match type ?'False? with ?'True? Expected type: State 'True Actual type: State 'False But now I want to abstract this pattern and write a (closed) type function > type family TurnOff s where > TurnOff True = False > turnOff' :: State x -> State (TurnOff x) > turnOff' (State True) = State False > bad = turnOff' off *Main> :t bad bad :: State (TurnOff 'False) *Main> bad *** Exception: TypeLevelSeq.lhs:37:3-37: Non-exhaustive patterns in function turnOff'

4 4

Call for a maintainer of protocol-buffers
by Kostiantyn Rybnikov 22 Jun '18

22 Jun '18

Hey everyone, I'm looking for a person who would become the major maintainer of the protocol-buffers package. Details here: https://github.com/k-bx/protocol-buffers/issues/64 Please comment on the issue or send me an email if you'd like to apply. Thank you

1 0

dfinity-radix-tree: A Merkleized key–value data store.
by Enzo 21 Jun '18

21 Jun '18

I am pleased to announce the first release of dfinity-radix-tree: A Merkleized key–value data store. The library provides a simple and easy to use data integrity layer for LevelDB. For more information, please see: [1] https://github.com/dfinity-lab/hs-radix-tree [2] https://hackage.haskell.org/package/dfinity-radix-tree Warm regards, Enzo Haussecker DFINITY Stiftung *We're hiring Haskell developers in Palo Alto and Zürich. Apply now:* [3] https://dfinity.org/openings

1 0

Timeouts inside a ConduitParser
by Luke Lau 21 Jun '18

21 Jun '18

I have a ConduitParser <https://hackage.haskell.org/package/conduit-parse-0.2.1.0/docs/Data-Conduit…> (a Sink with some parsing state) with a version of satisfy that can time out: satisfy :: MonadIO m => (a -> Bool) -> ConduitParser a m a satisfy pred = do tId <- liftIO myThreadId timeoutThread <- liftIO $ forkIO $ do threadDelay 1000000 throwTo tId TimeoutException x <- await liftIO $ killThread timeoutThread if pred x then return x else empty However I would rather not deal with the risks involved with handling concurrency myself and use a system library like System.Timeout: satisfy :: MonadIO m => (a -> Bool) -> ConduitParser a m a satisfy pred = do x <- timeout 1000000 await if pred x then return x else empty This doesn’t work though since I need to be able to both lift and unlift await from IO, and ConduitParser lies on top of ConduitT, which is one of the types of monads that UnliftIO cannot be an instance of <https://github.com/fpco/unliftio#limitations>. Are there any better approaches to this? <https://github.com/fpco/unliftio#limitations> <https://github.com/fpco/unliftio#limitations> <https://github.com/fpco/unliftio#limitations>

2 1

Re: [Haskell-cafe] How to use Reader?
by Hilco Wijbenga 21 Jun '18

21 Jun '18

Ah, quite simple. Thanks! On Tue, Jun 19, 2018 at 9:39 PM, Matt <parsonsmatt(a)gmail.com> wrote: > showText text = do > a <- showA > return ("[" `append` text `append` a `append` "]") > > > Matt Parsons > > On Tue, Jun 19, 2018 at 10:35 PM, Hilco Wijbenga <hilco.wijbenga(a)gmail.com> > wrote: >> >> Hi all, >> >> I think I'm pretty close but not quite there yet. Let's say I have the >> following: >> >> {-# LANGUAGE OverloadedStrings #-} >> >> module Main where >> >> import Prelude (IO) >> import Data.Text (Text, append) >> import Data.Text.IO (putStrLn) >> >> main :: IO () >> main = >> putStrLn (showText "Hello World!" config) >> where >> config :: Config >> config = Config (A "Boo") >> >> data A = A Text >> >> data Config = Config { a :: A } >> >> showText :: Text -> Config -> Text >> showText text config = >> "[" `append` text `append` (showA config) `append` "]" >> >> showA :: Config -> Text >> showA config = >> "'" `append` text `append` "'" >> where >> A text = a config >> >> Now I want to use Reader. This is as close as I can get: >> >> {-# LANGUAGE OverloadedStrings #-} >> >> module Main where >> >> import Prelude (IO, return, ($)) >> import Data.Text (Text, append) >> import Data.Text.IO (putStrLn) >> import Control.Monad.Reader (Reader, asks, runReader) >> >> main :: IO () >> main = >> putStrLn (runReader (showText "Hello World!") config) >> where >> config :: Config >> config = Config (A "Boo") >> >> data A = A Text >> >> data Config = Config { a :: A } >> >> showText :: Text -> Reader Config Text >> showText text = >> return $ >> "[" `append` text `append` showA `append` "]" >> >> showA :: Reader Config Text >> showA = do >> A text <- asks a >> return $ >> "'" `append` text `append` "'" >> >> This is almost correct, except for the showA invocation in showText. >> It wants a Text but it's getting a Reader Config Text. What is the >> magic to make this work? >> >> Cheers, >> Hilco >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > >

1 1

Looking for simple C statements parser for Parsec, MegaParsec or Happy
by Bulat Ziganshin 20 Jun '18

20 Jun '18

Hello all, I develop a preprocessor transpiling subset of C statements into gcc _asm statements. For this project, I will be happy to reuse existing C statements parser written with any popular Haskell technology, or just start with some simple C subset parser in order to avoid redoing existing work. Unfortunately, so far I found grammars just for everything but C. And while I can start with Parsec grammars for Java/Go, it seems that MegaParsec now is better choice? I can quickly develop grammar for small C subset, but ready-to-use grammar for larger C subset will allow me to completely skip the development of C statement parser and focus on the meat of project - asm code generation. Eventually, it may turn into LLVM pass transpiling parts of C++ code, but for quick prototype, I prefer Haskell, especially if I can find ready-to-use parser. PS: It was the first time I ever asked at SO, but it turned out to be offtopic there: https://stackoverflow.com/questions/50949118/simple-c-grammar-for-haskell-p… -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 2

Re: [Haskell-cafe] GHCi: how to load another file than .ghci ?
by Artem Pelenitsyn 20 Jun '18

20 Jun '18

It worked for me on a dummy project, but I may miss something. Maybe, it is `stack ghci` you want to use, not `stack exec ghci`. But I wasn't able to convince stack to catch `-ghci-script` for some reason. My best bet was: stack ghci --ghci-options="-ghci-script ~/my-ghci" PS You probably want to reply not just to me but to the whole mailing-list, so that people know that your problem hasn't been resolved. -- Best, Artem On Wed, 20 Jun 2018 at 16:08 PY <aquagnu(a)gmail.com> wrote: > strange, because result is different (I got a lot of errors about not > found modules, etc). > > 20.06.2018 16:21, Artem Pelenitsyn пишет: > > Hello Paul, > > You can supply arguments for commands run by stack like this: stack exec > CMD -- ARGS > In your case the argument you're interested in is -ghci-script. So the > answer is > > stack exec ghci -- -ghci-script path/to/somefile.txt > > -- > Best wishes, Artem > > > On Wed, 20 Jun 2018 at 14:44 PY <aquagnu(a)gmail.com> wrote: > >> Hello, Cafe! If I have typical .ghci file, but it's called somefile.txt, >> how to call "stack exec ghci" to load and exec this "somefile.txt" (as >> it does with ".ghci" usual)? >> >> >> === >> >> Best regards, Paul >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > >

1 0

GHCi: how to load another file than .ghci ?
by PY 20 Jun '18

20 Jun '18

Hello, Cafe! If I have typical .ghci file, but it's called somefile.txt, how to call "stack exec ghci" to load and exec this "somefile.txt" (as it does with ".ghci" usual)? === Best regards, Paul

2 1

Re: [Haskell-cafe] Memory leak in infinite recursion
by Dr.Koster 20 Jun '18

20 Jun '18

In general infinite monadic recursion will leak, since the tail position is always >> or >>= instead of your own recursive function, but under certain situations, e.g. IO without arguments, the compiler will figure there's no need to push new stack frame. But anyway it's better to checkout yourself rather relying on some weak assumptions. 发自我的iPhone ------------------ Original ------------------ From: Никита Фуфаев <kitttoran(a)gmail.com> Date: Wed,Jun 20,2018 2:37 AM To: haskell-cafe <haskell-cafe(a)haskell.org> Subject: Re: [Haskell-cafe] Memory leak in infinite recursion Hello everyone In C you can't implement main loop with recursion like void mainLoop() { doSomething(); mainLoop(); } because without optimisations stack will overflow. In haskell it's common to write mainLoop = doSomething >> mainLoop, and it doesn't leak memory because of haskell's evaluation model. Does memory leak or argument stack overflow happen in this case? mainLoop = doSomething >> mainLoop >> exit ExitSuccess What about this case? mainLoopModeA = do doSomething when condition mainLoopModeB mainLoopModeA mainLoopModeB = do doSomethingElse when anotherCondition mainLoopModeA mainLoopModeB or this case? mainLoopModeA = do doSomething if condition then mainLoopModeB else mainLoopModeA mainLoopModeB = do doSomethingElse if anotherCondition then mainLoopModeA else mainLoopModeB -- Nikita Fufaev

3 2

How to define CPP macro definition with stack?
by PY 20 Jun '18

20 Jun '18

Hello all, I'm using conditional compilation: #ifdef BLAH blahBlah #endif And I want to define BLAH, but not in *.hs file. For example, with `stack` option or as environment variable... How can I do it? For example, `stack -DBLAH=1 build` or something else. I tried stack build --flag='*:BLAH' - no effect. Also I tried stack build --flag=my-library:BLAH and get error that my-library package does not define flag BLAH. So, it's total secret for me how to make such thing (like we can do with gcc, make, etc) :-) === Best regards, Paul

2 2

How to use Reader?
by Hilco Wijbenga 20 Jun '18

20 Jun '18

Hi all, I think I'm pretty close but not quite there yet. Let's say I have the following: {-# LANGUAGE OverloadedStrings #-} module Main where import Prelude (IO) import Data.Text (Text, append) import Data.Text.IO (putStrLn) main :: IO () main = putStrLn (showText "Hello World!" config) where config :: Config config = Config (A "Boo") data A = A Text data Config = Config { a :: A } showText :: Text -> Config -> Text showText text config = "[" `append` text `append` (showA config) `append` "]" showA :: Config -> Text showA config = "'" `append` text `append` "'" where A text = a config Now I want to use Reader. This is as close as I can get: {-# LANGUAGE OverloadedStrings #-} module Main where import Prelude (IO, return, ($)) import Data.Text (Text, append) import Data.Text.IO (putStrLn) import Control.Monad.Reader (Reader, asks, runReader) main :: IO () main = putStrLn (runReader (showText "Hello World!") config) where config :: Config config = Config (A "Boo") data A = A Text data Config = Config { a :: A } showText :: Text -> Reader Config Text showText text = return $ "[" `append` text `append` showA `append` "]" showA :: Reader Config Text showA = do A text <- asks a return $ "'" `append` text `append` "'" This is almost correct, except for the showA invocation in showText. It wants a Text but it's getting a Reader Config Text. What is the magic to make this work? Cheers, Hilco

1 0

Memory leak in infinite recursion
by Никита Фуфаев 20 Jun '18

20 Jun '18

Hello everyone In C you can't implement main loop with recursion like void mainLoop() { doSomething(); mainLoop(); } because without optimisations stack will overflow. In haskell it's common to write mainLoop = doSomething >> mainLoop, and it doesn't leak memory because of haskell's evaluation model. Does memory leak or argument stack overflow happen in this case? mainLoop = doSomething >> mainLoop >> exit ExitSuccess What about this case? mainLoopModeA = do doSomething when condition mainLoopModeB mainLoopModeA mainLoopModeB = do doSomethingElse when anotherCondition mainLoopModeA mainLoopModeB or this case? mainLoopModeA = do doSomething if condition then mainLoopModeB else mainLoopModeA mainLoopModeB = do doSomethingElse if anotherCondition then mainLoopModeA else mainLoopModeB -- Nikita Fufaev

4 4

Anybody interested in Dart? Maintainer needed.
by Mario Blažević 18 Jun '18

18 Jun '18

There is package named language-dart on Hackage by Kwang Yul Seo. The package includes the Dart AST and pretty-printer, but no parser. It hasn't been updated in 2 years. I have implemented a parser in a pull request (https://github.com/kseo/language-dart/pull/1) but the original author says he doesn't have time to maintain this package at the moment and is willing to transfer its maintainance. As for myself, I'd be happy to help as a co-maintainer but I feel that a proper feeding and care of the package requires somebody with interest in Google Dart per se. Does anybody here fit this description?

1 0

ghc_ticker not checking return code?
by Jon Fairbairn 18 Jun '18

18 Jun '18

I’ve just been rebuilding something I wrote ages ago, using stack with lts-11.6 (so that I can use a recent Conduit). Part (not a part I was modifying) of the code runs as a CGI script, and I was horrified to find that when run by httpd it soaked up CPU like nobody’s business without producing any output. Running it at the command line worked fine, so I traced the problem via audit: type=AVC msg=audit(1529223103.790:1705516): avc: denied { read } for pid=36764 comm="ghc_ticker" path="[timerfd]" dev=anon_inodefs ino=4597 scontext=system_u:system_r:httpd_sys_script_t:s0 tcontext=system_u:object_r:anon_inodefs_t:s0 tclass=file type=AVC msg=audit(1529223103.790:1705517): avc: denied { read } for pid=36764 comm="ghc_ticker" path="[timerfd]" dev=anon_inodefs ino=4597 scontext=system_u:system_r:httpd_sys_script_t:s0 tcontext=system_u:object_r:anon_inodefs_t:s0 tclass=file The solution is to add an audit rule to allow that, but surely ghc_ticker shouldn’t be trying again so fast when whatever it is trying to do isn’t permitted? I don’t know what component ghc_ticker belongs to, so where should I report the problem? -- Jón Fairbairn Jon.Fairbairn(a)cl.cam.ac.uk

2 3

Announcement: MPC 2019, Porto, Portugal
by Graham Hutton 18 Jun '18

18 Jun '18

Dear all, I'm delighted to announce that the next Mathematics of Program Construction (MPC) conference will be held in the historic city of Porto, Portugal in October 2019, co-located with Formal Methods (FM). Please share, and submit your best papers! Best wishes, Graham ====================================================================== 13th International Conference on Mathematics of Program Construction 7-9 October 2019, Porto, Portugal Co-located with FM 2019 https://tinyurl.com/MPC-Porto ====================================================================== BACKGROUND: The International Conference on Mathematics of Program Construction (MPC) aims to promote the development of mathematical principles and techniques that are demonstrably practical and effective in the process of constructing computer programs. MPC 2019 will be held in Porto, Portugal from 7-9 October 2019, and is co-located with the International Symposium on Formal Methods, FM 2019. Previous conferences were held in Königswinter, Germany (2015); Madrid, Spain (2012); Québec City, Canada (2010); Marseille, France (2008); Kuressaare, Estonia (2006); Stirling, UK (2004); Dagstuhl, Germany (2002); Ponte de Lima, Portugal (2000); Marstrand, Sweden (1998); Kloster Irsee, Germany (1995); Oxford, UK (1992); Twente, The Netherlands (1989). SCOPE: MPC seeks original papers on mathematical methods and tools put to use in program construction. Topics of interest range from algorithmics to support for program construction in programming languages and systems. Typical areas include type systems, program analysis and transformation, programming language semantics, security, and program logics. The notion of a 'program' is interpreted broadly, ranging from algorithms to hardware. Theoretical contributions are welcome, provided that their relevance to program construction is clear. Reports on applications are welcome, provided that their mathematical basis is evident. We also encourage the submission of 'programming pearls' that present elegant and instructive examples of the mathematics of program construction. IMPORTANT DATES: Abstract submission 26th April 2019 Paper submission 3rd May 2019 Author notification 14th June 2019 Camera ready copy 12th July 2019 Conference 7-9 October 2019 SUBMISSION: Submission is in two stages. Abstracts (plain text, maximum 250 words) must be submitted by 26th April 2019. Full papers (pdf, formatted using the llncs.sty style file for LaTex) must be submitted by 3rd May 2019. There is no prescribed page limit, but authors should strive for brevity. Both abstracts and papers will be submitted using EasyChair. Papers must present previously unpublished work, and not be submitted concurrently to any other publication venue. Submissions will be evaluated by the program committee according to their relevance, correctness, significance, originality, and clarity. Each submission 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. Accepted papers must be presented in person at the conference by one of the authors. The proceedings of MPC 2019 will be published in the Lecture Notes in Computer Science (LNCS) series, as with all previous instances of the conference. Authors of accepted papers will be expected to transfer copyright to Springer for this purpose. After the conference, authors of the best papers from MPC 2019 and MPC 2015 will be invited to submit revised versions to a special issue of Science of Computer Programming (SCP). For any queries about submission please contact the program chair, Graham Hutton <graham.hutton(a)nottingham.ac.uk>. PROGRAM COMMITTEE: Graham Hutton University of Nottingham, UK (chair) The full committee will be announced as soon as it is available. VENUE: The conference will be held at the Alfândega Porto Congress Centre, a 150 year old former custom's house located in the historic centre of Porto on the bank of the river Duoro. The venue was renovated by a Pritzer prize winning architect and has received many awards. LOCAL ORGANISERS José Nuno Oliveira University of Minho, Portugal For any queries about local issues please contact the local organiser, José Nuno Oliveira <jno(a)di.uminho.pt>. ====================================================================== This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law.

1 0

DataHaskell Newsletter #1, June 2018
by Marco Zocca 17 Jun '18

17 Jun '18

Hi all, I'd like to share with you a few of the things that happened during the past months on and around DataHaskell (DH), and a summary of the current state of things. Time permitting, this will become a regular newsletter, with the idea to keep up to date those who don't usually hang out on our Gitter chatroom [1]. ---------------------------------------------------------------------------------------------------------------- * Outreach activities and related meetings ICFP 2017 : Early September 2017 we had an hour-long lunch mini-workshop at ICFP during which a few people presented how they use Haskell in their numerical and data-crunching work. Mostly positive opinions, as well as a "contrarian" viewpoint (from an expert practitioner) who lamented the low-performance of native Haskell numerical code (e.g. the large memory footprint of boxed data). Michal Gajda presented how he uses IHaskell for interactive data exploration (btw, it's a thing and you can try it today!), Trevor McDonell introduced Accelerate (the high-performance array library that can target CUDA GPUs), Adam Scibior presented `monad-bayes` and Praveen Narayan presented `hakaru` (two probabilistic progamming laguages embedded in Haskell). ZuriHac 2018 : community bonding mostly (read: no hacking was done). Received more feedback of the usual sort "how do I do X in Haskell?" "I was expecting a more advanced state of machine learning capabilities in Haskell", etc. There may or may not be a set of Haskell bindings for Apache Arrow in the works, stay tuned! ICFP 2018 : There will be two very interesting workshops (FHPC, functional programming in high-performance computing and NPFL, numerical programming in functional languages), for those who will be attending the conference. One of the workshop chairs of NPFL is Dominic Steinitz of Tweag, author of the excellent idontgetoutmuch.wordpress.com blog. ---------------------------------------------------------------------------------------------------------------- * DH survey On April 5 I've published a survey [2], that tried to gauge the community interest and pain points related to doing "data science" in our beloved language. The survey is still open but I won't be collecting data anymore (70 people have taken the questionnaire and 62 have completed it), and I've scraped and formatted the dataset (you can find it at https://github.com/DataHaskell/surveys) Some of the free text answers are particularly interesting. I don't have much time currently to create the plots and publish a blog post about it, but it would be a Good Thing to have, if anyone wants to step up. The project backbone is ready for new contributors! ---------------------------------------------------------------------------------------------------------------- * Contributors wanted : External projects At regular intervals, new exciting projects appear and it's becoming quite hard to keep track of everything that's happening in this area. I'd like to highlight here a few that are seeing significant activity as of late and have large impact potential. ** General-purpose (e.g. numerics-related) `numhask` [3] is an experiment at replacing the numerical typeclasses of `base`, in particular those related to `Num`, in favor of a finer-grained and more principled hierarchy. It is already available and receiving quite a bit of attention recently, but there still are a number of areas that could use some help, for example property checking, test coverage, the `accelerate` bindings, etc. ** Data science `boke-hs` [4] : a native Haskell interface to generate Bokeh plots. The project was mostly developed during the ZuriHac weekend; currently it's functional and you can create line plots with it, but helping out with the domain mapping would be a very valuable contribution. In particular, the library emits JSON blobs that are interpreted in the browser by BokehJS ; "domain mapping" means creating the Haskell data that will serialize into JSON appropriately. A currently-unnamed library for linking databases and Haskell dataframes. This is Gagandeep Bhatia's ongoing Summer of Haskell project, and you can find a writeup and links to his current work (which uses `beam` as a database binding library and `Frames` as type-safe in-memory representation) here: https://www.gagandeepbhatia.com/blog/ . `haskell.do` [5] : a native Haskell notebook/interactive editor/IDE for the browser. The project started well, has a website and a few initial releases, but currently needs some love to achieve its full potential. Interactive development with visual feedback is a crucial part of data science work, and contributions to this project will be very valuable. ** Machine learning `hasktorch` [6] is in developer beta ! This is a set of Haskell bindings for `torch` (the deep learning C library), and comes wrapped in a typed interface that provide statically-checked vector dimensions, and the like. ** Probabilistic programming languages `deanie` [7] is a probabilistic EDSL. Currently it's lacking code for its general-purpose inference engine (see https://github.com/jtobin/deanie/blob/master/lib/Deanie/Inference/Comonadic…) The implementation technique is related to "Co-Free for interpreters" as shown in [8]. ---------------------------------------------------------------------------------------------------------------- * Contributors wanted : DataHaskell internal projects We do have a few projects set up that could use some collaborators. If you are willing to contribute to any of these, please open a ticket on the project issue tracker and the maintainers will be in touch shortly. * `type-providers` : a unified code generation library for accessing structured data in a type-safe way : https://github.com/DataHaskell/type-providers . Michal Gajda is willing to mentor a student who wants to translate his own `json-autotype` to a new library that can generate type-safe code for XML, and can be queried in-memory via Frames. Contributing to this library will likely require some knowledge of Template Haskell. * A fork of the venerable `statistics` library, that separates the dense linear algebra library as a standalone library : https://github.com/DataHaskell/statistics . There is currently a PR to the upstream library (https://github.com/bos/statistics/pull/143) longer-term plans include giving it a typeclass-based interface, for example based on `numhask`. * `numhask-linear-algebra` : this is a longer shot at unifying native linear algebra libraries under a single typeclass representation, as provided by `numhask` (project at https://github.com/DataHaskell/numhask-linear-algebra ). This is something that's currently unavailable in the Haskell ecosystem and will be a highly relevant contribution to many. ---------------------------------------------------------------------------------------------------------------- * DataHaskell internal administration In addition to helping out with the survey blogpost, some help in the following areas would be much appreciated ** Knowledge base : testers wanted ! The knowledge base ( http://www.datahaskell.org/docs/community/current-environment.html ) is a growing curated collection of libraries for doing data science-related tasks; anything from manipulating storable data to statistical inference. It's pretty useful as it is, but I think the entries should be annotated with additional information, such as the degree of completeness and developer- and user-friendliness. For this, some help in testing out the libraries and reporting back would be very useful. Ultimately, it would be very useful to contribute such an assessment back to the "state of the ecosystem" document [9], which is highly visible but not so much up to date on the data-science related things. ** Maintainers wanted ! Currently, Nikita and I are the only owners of the github organization. It would be great if additional people stepped up for "tending the garden", e.g. keeping track of issue tickets, filling out the documentation, lending a hand on the gitter channel to address newcomers' issues, etc. Historically, data science and numerical computing have been underserved niches of the Haskell ecosystem, and while things are steadily improving, together we can bring about this change soon ! ---------------------------------------------------------------------------------------------------------------- That's it for now, I hope you enjoyed this Newsletter; don't hesitate to share your thoughts either here or on our Gitter chatroom! [1] Marco github.com/ocramz ---------------------------------------------------------------------------------------------------------------- References : [1] DH Gitter chatroom : https://gitter.im/dataHaskell/Lobby [2] DH user survey April 2018: https://www.surveymonkey.com/r/3FBBJWR [3] numhask : github.com/tonyday567/numhask [4] boke-hs , native Haskell bindings for Bokeh : https://github.com/ahaym/boke-hs [5] HaskellDO, the interactive Haskell editor: http://haskell.do/ , https://github.com/theam/haskell-do [6] hasktorch, the Haskell bindings to Torch : https://github.com/hasktorch/hasktorch [7] deanie , probabilistic programming language : https://github.com/jtobin/deanie [8] "Free for DSLs, co-free for interpreters" http://dlaing.org/cofun/posts/free_and_cofree.html [9] State of the Haskell ecosystem : https://github.com/Gabriel439/post-rfc/blob/master/sotu.md

1 0

the purpose of QuickCheck's size parameter
by Petr Pudlák 17 Jun '18

17 Jun '18

Hi everyone, I'd like to better understand the principles behind the 'size' parameter. Looking at quickCheckWithResult [1], its computation seems to be somewhat non-trivial, or even arbitrary. As far as I understand it, the size is varied throughout tests, increasing from small to larger values. I see two main purposes: - Test on smaller as well as larger values. But with generators having proper distribution of values, this should happen anyway, just as if we had a constant, larger 'size' parameter. - Starting with smaller sizes allows to find smaller count-examples first. But with shrinking, it doesn't matter that much, big counter-examples are shrunk to smaller ones anyway in most cases. So is this parameter actually necessary? Would anything change considerably if it was dropped? Thanks, Petr [1] http://hackage.haskell.org/package/QuickCheck-2.11.3/docs/src/Test-QuickChe…

6 7

Lattice and calculation of Least Upper Bounds
by Aaron Gray 16 Jun '18

16 Jun '18

Hi, I am trying to work out how to use the Algebra.Lattice family of Lattice data structures. Firstly how do I construct a lattice ? What I am wanting to do is to be able to construct a lattice to represent a multiple inheritance hierarchy. Then I to be able to find the Least Upper Bound of a set of classes/types. This is in order to find the type of a multiple case expression. I am not sure if the Haskell classes are actually applicable ? but if they are how do I apply them to the following problem please ? -- Aaron Gray Independent Open Source Software Engineer, Computer Language Researcher, Information Theorist, and amateur computer scientist.

1 0

Hedgehog - Integrated shrinking, shrinks obey invariants by construction.
by Petr Pudlák 15 Jun '18

15 Jun '18

Hi everyone, I found the above interesting sentence in Hedgehog's [1] documentation. What does this mean? Is construction there somewhat tied to shrinking, perhaps something like going in the reverse direction? Thanks, Petr [1] https://github.com/hedgehogqa/haskell-hedgehog#features

3 4

Re: [Haskell-cafe] LIA bindings?
by ARJANEN Loïc Jean David 15 Jun '18

15 Jun '18

Hello, It was purely curiosity which made me ask that question given that the report mentions this standard but as you said, if no one maintains it there’s little point in making bindings for it. Regards, ARJANEN Loïc Le 2018-06-13 à 22:48, Richard O'Keefe a écrit : > A couple of years ago I inquired about adding a new module to > the LIA standards to describe binary and decimal fixed point > arithmetic, having run into a standard which deferred the > semantics of its fixed point arithmetic to LIA. That was a > bit odd, because LIA explicitly refused to say anything about > the matter. The result was the implementations not agreeing, > in quite fundamental ways, with each other. I offered a > draft executable specification in Haskell, checked with > QuickCheck. I basically got the answer "nice work, but nobody > in the industry cares about LIA any more, which is why LIA-1 > was revised but LIA-2 and LIA-3 never were and never will be." > > So the question has to be asked: what exactly would be the > benefit in building library code to support a standard that > nobody wants to maintain any more? > > On 13 June 2018 at 20:44, ARJANEN Loïc Jean David > <arjanen.loic(a)gmail.com <mailto:arjanen.loic@gmail.com>> wrote: > > Dear Café, > > I saw in the report that the standard libraries’ operations don’t > conform to LIA and that such operations should be done in an > external library. Does such a library exist? > > Regards, > ARJANEN Loïc > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe> > Only members subscribed via the mailman list are allowed to post. >

1 0

Call for draft papers for presentation at IFL 2018 (Implementation and Application of Functional Languages)
by Jurriaan Hage 15 Jun '18

15 Jun '18

Hello, Please, find below the fourth call for papers for IFL 2018. 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 --- Call for Draft papers for presentations ================================================================================ IFL 2018 30th Symposium on Implementation and Application of Functional Languages University of Massachusetts Lowell, MA, USA September 5th-7th, 2018 http://iflconference.org ================================================================================ ### 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 2018 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. Topics of interest to IFL 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 ### Keynote Speakers * Adam Chlipala, Massachusetts Institute of Technology CSAIL * Arjun Guha, University of Massachusetts Amherst ### Submissions and peer-review Differently from previous editions of IFL, IFL 2018 solicits two kinds of submissions: * Regular papers (12 pages including references) * Draft papers for presentations ('weak' limit between 8 and 15 pages) Regular papers will undergo a rigorous review by the program committee, and will be evaluated according to their correctness, novelty, originality, relevance, significance, and clarity. A set of regular papers will be conditionally accepted for publication. Authors of conditionally accepted papers will be provided with committee reviews along with a set of mandatory revisions. Regular papers not accepted for publication will be considered as draft papers, at the request of the author. Draft papers will be screened to make sure that they are within the scope of IFL, and will be accepted for presentation or rejected accordingly. Prior to the symposium: Authors of conditionally accepted papers and accepted presentations will submit a pre-proceedings version of their work that will appear in the draft proceedings distributed at the symposium. The draft proceedings does not constitute a formal publication. We require that at least one of the authors present the work at IFL 2018. After the symposium: Authors of conditionally accepted papers will submit a revised versions of their paper for the formal post-proceedings. The program committee will assess whether the mandatory revisions have been adequately addressed by the authors and thereby determines the final accept/reject status of the paper. Our interest is to ultimately accept all conditionally accepted papers. If you are an author of a conditionally accepted paper, please make sure that you address all the concerns of the reviewers. Authors of accepted presentations 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 post-proceedings. The program committee will evaluate these submissions according to their correctness, novelty, originality, relevance, significance, and clarity, and will thereby determine whether the paper is accepted or rejected. ### Publication The formal proceedings will appear in the International Conference Proceedings Series of the ACM Digital Library. 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 ### Important dates Submission of regular papers: May 25, 2018 [PASSED!] Submission of draft papers: July 17, 2018 [UPCOMING!] Regular and draft papers notification: July 20, 2018 Deadline for early registration: August 8, 2018 Submission of pre-proceedings version: August 29, 2018 IFL Symposium: September 5-7, 2018 Submission of papers for post-proceedings: November 7, 2018 Notification of acceptance: December 22, 2018 Camera-ready version: February 10, 2019 ### Submission details All contributions must be written in English. Papers must use the ACM two columns conference format, which can be found at: http://www.acm.org/publications/proceedings-template Authors submit through EasyChair: https://easychair.org/conferences/?conf=ifl2018 ### 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. ### Organization and Program committee Chairs: Jay McCarthy & Matteo Cimini, University of Massachusetts Lowell, USA Program Committee: * Arthur Chargueraud, Inria, FR * Ben Delaware, Purdue University, USA * Christos Dimoulas, Northwestern University, USA * David Darais, University of Vermont, USA * Dominic Orchard, University of Kent, UK * Ekaterina Komendantskaya, Heriot-Watt University, UK * Garrett Morris, University of Kansas, USA * Heather Miller, EPFL & Northeastern University, CH & USA * Jeremy Yallop, University of Cambridge, UK * Keiko Nakata, SAP Innovation Center Potsdam, DE * Laura Castro, University of A Coruna, ESP * Magnus Myreen, Chalmers University of Technology, SWE * Natalia Chechina, Bournemouth University, UK * Peter Achten, Radboud Universiteit Nijmegen, NL * Peter-Michael Osera, Grinnell College, USA * Richard Eisenberg, Bryn Mawr College, USA * Trevor McDonell, University of New South Wales, AUS * Yukiyoshi Kameyama, University of Tsukuba, JAP ### Venue The 30th IFL is organized by the University of Massachusetts Lowell. The City of Lowell is located at the heart of the Merrimack Valley just 30 miles northwest of Boston. Lowell can be easily reached by train or taxi. See the website for more information on the venue. ### Acknowledgments This call-for-papers is an adaptation and evolution of content from previous instances of IFL. We are grateful to prior organizers for their work, which is reused here. A part of IFL 2018 format and CFP language that describes conditionally accepted papers has been adapted from call-for-papers of OOPSLA conferences.

1 0

How far can you take overloading with type classes?
by Hilco Wijbenga 14 Jun '18

14 Jun '18

Hi all, Given definitions of Line and Lines is it possible to define a type class (or maybe multiple type classes) that would allow for the following: (++) :: Line -> Line -> Lines (++) :: Line -> Lines -> Lines (++) :: Lines -> Line -> Lines (++) :: Lines -> Lines -> Lines I.e. is there a way to overload (++) such that it supports each of these 4 combinations? (Let's ignore that (++) already exists for the moment.) Cheers, Hilco

3 2

CFP: One Month Until Left For Submitting to The Workshop in OCL and Textual Modeling (OCL 2018)
by Achim D. Brucker 14 Jun '18

14 Jun '18

(Apologies for duplicates) ********************************************************** ** Only one month left until the submission deadline! *** ********************************************************** CALL FOR PAPERS 18th International Workshop on OCL and Textual Modeling Co-located with MODELS 2018: ACM/IEEE 21th International Conference on Model Driven Engineering Languages and System, October 14, 2018, Copenhagen, Denmark http://oclworkshop.github.io Modeling started out with UML and its precursors as a graphical notation. Such visual representations enable direct intuitive capturing of reality, but they have weaknesses: for example, detailed visual representations bear the risk of becoming overcrowded faster than textual models and some of the visual features lack the level of precision required to create complete and unambiguous specifications. These weaknesses of graphical notations encouraged the development of text-based modeling languages that either integrate with or replace graphical notations for modeling. Typical examples of such languages are OCL, textual MOF, Epsilon, and Alloy. Textual modeling languages have their roots in formal language paradigms like logic, programming and databases. The goal of this workshop is to create a forum where researchers and practitioners interested in building models using OCL or other kinds of textual languages can directly interact, report advances, share results, identify tools for language development, and discuss appropriate standards. In particular, the workshop will encourage discussions for achieving synergy from different modeling language concepts and modeling language use. The close interaction will enable researchers and practitioners to identify common interests and options for potential cooperation. ## Topics of interest Topics of interest include (but are not limited to): - Mappings between textual modeling languages and other languages/formalisms - Mathematical models and/or formal semantics for textual modeling languages - Algorithms, evaluation strategies and optimizations in the context of textual modeling languages for: - validation, verification, and testing, - model transformation and code generation, - meta-modeling and DSLs, and - query and constraint specifications - Alternative graphical/textual notations for textual modeling languages - Evolution, transformation and simplification of textual modeling expressions - Libraries, templates and patterns for textual modeling languages - Tools that support textual modeling languages (e.g., verification of OCL formulae, runtime monitoring of invariants) - Model-driven security using textual modeling languages - Complexity results for textual modeling languages - Quality models and benchmarks for comparing and evaluating textual modeling tools and algorithms - Successful applications of textual modeling languages - Case studies on industrial applications of textual modeling languages - Experience reports: - usage of textual modeling languages and tools in complex domains, - usability of textual modeling languages and tools for end-users - Empirical studies about the benefits and drawbacks of textual modeling languages - Innovative textual modeling tools - Comparison, evaluation and integration of modeling languages - Correlation between modeling languages and modeling tasks We particularly encourage submissions describing applications and case studies of textual modeling as well as test suites and benchmark collections for evaluating textual modeling tools. ## Venue This workshop will be organized as a part of MODELS 2018 Conference in Copenhagen, Denmark. Similar to its predecessors, the workshop addresses both people from academia and industry. The aim is to provide a forum for addressing integration of OCL and other textual modeling languages, as well as tools for textual modeling, and for disseminating good practice and discussing the new requirements for textual modeling. ## Workshop Format The workshop will include short (about 15 min) presentations, parallel sessions of working groups, and sum-up discussions. ## Submissions Two types of papers will be considered: * Short contributions (between 5 and 7 pages) describing new ideas, innovative tools or position papers. * Full papers (between 10 and 14 pages). in LNCS format. Submissions should be uploaded to [EasyChair](https://easychair.org/conferences/?conf=ocl2018). The program committee will review the submissions (minimum 2 reviews per paper, usually 3 reviews) and select papers according to their relevance and interest for discussions that will take place at the workshop. Accepted papers will be published online, as part of the MODELS workshop proceedings, in [CEUR](http://www.ceur-ws.org). ## Important Dates - Submission of papers: July 17, 2018 - Notification: August 17, 2018 - Workshop date: October 14, 2018 -- Dr. Achim D. Brucker | Software Assurance & Security | University of Sheffield https://www.brucker.ch | https://logicalhacking.com/blog @adbrucker | @logicalhacking

1 0

LIA bindings?
by ARJANEN Loïc Jean David 13 Jun '18

13 Jun '18

Dear Café, I saw in the report that the standard libraries’ operations don’t conform to LIA and that such operations should be done in an external library. Does such a library exist ? Regards,ARJANEN Loïc

1 0

Re: [Haskell-cafe] Announce: Haskell Platform 8.4.3
by Johannes Waldmann 13 Jun '18

13 Jun '18

> Haskell Platform 8.4.3 Nice. Now I'm wondering - is there an estimated release date for stackage LTS for ghc-8.4.3? That's a genuine question. I know stackage has (a lot) more packages (platform: less than 100?, last LTS: 2474?) so it involves more interfaces (to software, to humans) that can break in many more ways. - J.W.

2 1

Disable default-to-DeriveAnyClass warning with DerivingStrategies?
by Theodore Lief Gannon 11 Jun '18

11 Jun '18

Is there a flag to disable this warning? There's no mystery or surprise to the default, but if I want all three of GeneralizedNewtypeDeriving, DeriveAnyClass and DerivingStrategies enabled, I'm currently stuck with a warning for e.g. deriving (Generic, ToJSON). The only way to use strategy keywords is on standalone deriving lines, which seems unnecessarily verbose.

1 0

how to prevent 'stack' from installing 'ghc'?
by Johannes Waldmann 10 Jun '18

10 Jun '18

Dear Cafe, 'stack' tries to download and install a 'ghc' binary in case 'ghc' in $PATH does not match what is needed for the resolver given in 'stack.yaml' How can I switch this off completely and reliably? I much rather 'stack' just fails when it detects the mismatch. putting 'system-ghc: true' in 'stack.yaml' and '~/.stack/config.yaml' apparently is not enough. 'stack' does warn before downloading, but sometimes I'm not seeing the warning, e.g., because the whole thing is triggered silently from using 'intero'. I do have several ghc executables (built from source) in /opt/ghc/ghc-$version/bin/ghc and I just need to set PATH accordingly. It would be even better if I could tell 'stack' (once and for all) about these locations. I think I understand why 'stack' does what it does (reproducible builds) but I really want to minimize the number of other people's binaries on my machine. I do use the auto-download feature for easier CI builds - so I agree it can be useful. - J.W.

2 1

removing a cookie via ghcjs
by Michael Litchard 08 Jun '18

08 Jun '18

Using ghcjs, I am able to read a cookie using getCookie. There's no corresponding remove/deleteCookie that I can find. Could I get some assistance in how to remove the same cookie I can see using getCookie?

3 3

TyDe 2018: SUBMISSION DEADLINE EXTENDED TO JUNE 13th.
by Niki Vazou 07 Jun '18

07 Jun '18

Hey all, the TyDe submission deadline got extended for one week! CALL FOR CONTRIBUTIONS: DEADLINE EXTENDED TO JUNE 13th. TyDe 2018: Type-Driven Development https://icfp18.sigplan.org/track/tyde-2018 23-29 Sep, 2018, St. Louis, Missouri (co-located with ICFP) ============================================== *Call for Contributions* We welcome all contributions, both theoretical and practical, on a range of topics including: dependently typed programming; generic programming; design and implementation of programming languages, exploiting types in novel ways; exploiting typed data, data dependent data, or type providers; static and dynamic analyses of typed programs; tools, IDEs, or testing tools exploiting type information; pearls, being elegant, instructive examples of types used in the derivation, calculation, or construction of programs. *Important Dates* **Extended paper submission deadline: Wednesday, June 13, 2018** Extended abstract deadline: Wednesday, June 13, 2018 Author notification: Friday, June 29, 2018 Deadline for camera ready version: August 5, 2018 Workshop: Thursday, September 27, 2018 *Program Committee* - Guillaume Allais, Radboud University Nijmegen, Netherlands - Zena M. Ariola, University of Oregon, USA - David Darais, University of Vermont, USA - Richard Eisenberg, Bryn Mawr College, USA (co-chair) - Jennifer Hackett, University of Nottingham, UK - Shin-ya Katsumata, National Institute of Informatics, Japan - Daan Leijen, Microsoft Research, USA - Shin-Cheng Mu, Academia Sinica, Taiwan - Dominic Orchard, University of Kent, UK - Peter-Michael Osera, Grinnell College, USA - Zoe Paraskevopoulou, Princeton University, USA - Alberto Pardo, Universidad de la Republica, Uruguay - Matthieu Sozeau, University of Paris Diderot, Paris 7, France - Niki Vazou, University of Maryland, USA (co-chair) *Submission details* Submissions should fall into one of two categories: - Regular research papers (12 pages) - Extended abstracts (2 pages) The bibliography will not be counted against the page limits for either category. Regular research papers are expected to present novel and interesting research results, and will be included in the formal proceedings. Extended abstracts should report work in progress that the authors would like to present at the workshop. Extended abstracts will be distributed to workshop attendees but will not be published in the formal proceedings. We welcome submissions from PC members (with the exception of the two co-chairs), but these submissions will be held to a higher standard. Submission is handled through HotCRP: https://tyde18.hotcrp.com/ All submissions should be in portable document format (PDF) and formatted using the ACM SIGPLAN style guidelines: http://www.sigplan.org/Resources/Author/ Note that the ACM SIGPLAN style guidelines have changed from previous years! In particular, submissions should use the new ‘acmart’ format and the two-column ‘sigplan’ subformat (not to be confused with the one-column ‘acmlarge’ subformat!). Extended abstracts must be submitted with the label ‘Extended abstract’ clearly in the title. Best, Niki Vazou

1 0

Usage of `pure`
by PY 07 Jun '18

07 Jun '18

Hello, Dear Cafe! Consider, I have big application with monad and applicative related code. What problems I can hit if I will replace all `return`s with `pure` (in `do`-blocks, anywhere). So, `return` will be totally eliminated. === Best regards, Paul

3 2