- Haskell-Cafe - Haskell.org

First Call for Papers for IFL 2019 (Implementation and Application of Functional Languages)
by J. Stutterheim 20 May '19

20 May '19

Dear all, Please, find below the first call for papers for IFL 2019. Please forward these to anyone you think may be interested. Apologies for any duplicates you may receive. Best regards, Jurriën Stutterheim --- ================================================================================ IFL 2019 31st Symposium on Implementation and Application of Functional Languages National University of Singapore September 25th-27th, 2019 http://2019.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 2019 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 Speaker * Olivier Danvy, Yale-NUS College ### Submissions and peer-review Differently from previous editions of IFL, IFL 2019 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 2019. 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 31, 2019 Submission of draft papers: July 15, 2019 Regular and draft papers notification: August 1, 2019 Deadline for early registration: August 15, 2019 Submission of pre-proceedings version: September 15, 2019 IFL Symposium: September 25-27, 2019 Submission of papers for post-proceedings: November 30, 2019 Notification of acceptance: January 31, 2020 Camera-ready version: February 29, 2020 ### 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=ifl2019 ### 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: Jurrien Stutterheim (Standard Chartered Bank Singapore), Wei Ngan Chin (National University of Singapore) Program Committee: - Olaf Chitil, University of Kent - Clemens Grelck, University of Amsterdam - Daisuke Kimura, The University of Tokyo - Pieter Koopman, Radboud University - Tamás Kozsik, Eötvös Loránd University - Roman Leschinskiy, Facebook - Ben Lippmeier, The University of New South Wales - Marco T. Morazan, Seton Hall University - Sven-Bodo Scholz, Heriot-Watt University - Tom Schrijvers, Katholieke Universiteit Leuven - Alejandro Serrano, Utrecht University - Tony Sloane, Macquarie University - Simon Thompson, University of Kent - Marcos Viera, Universidad de la República - Wei Ngan Chin, NUS - Jurriën Stutterheim, Standard Chartered Bank ### 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 2019 format and CFP language that describes conditionally accepted papers has been adapted from call-for-papers of OOPSLA conferences.

2 1

Mocking out external services
by Francesco Ariis 20 May '19

20 May '19

(literate Haskell follows) Hello -cafe, I recently read "Three Layer Haskell Cake" [1] and decided to give it a go. I am stuck on a simple problem and feel like I am missing something easy. One of the first examples is a mocking of an `IO UTCTime` function. > > {-# Language FlexibleInstances #-} > > data UTCTime = UTCTime Int > > class MonadTime m where > getCurrentTime :: m UTCTime > > instance MonadTime ((->) UTCTime) where > getCurrentTime = id > > -- instance IO omitted > Everything is clear. I decided to write another function, mocking a stream-of-Char input. > > class MonadKeys m where > getKeys :: m [Char] > > instance MonadKeys ((->) [Char]) where > getKeys = id > > -- instance IO omitted > Again, fine. But now, if I want to write a function which combines the two external services, like: > > someFun :: (MonadTime m, MonadKeys m) => m () > someFun = undefined > there is no non-IO instance satisfying the two constraints. I could of course write a type > > data Env = Env UTCTime [Char] > and make it instance of MonadTime and MonadKeys, but then I am passing non-relevant arguments to a mocked function like getCurrentTime, which would only need UTCTime. What am I doing incorrectly? -F [1] https://www.parsonsmatt.org/2018/03/22/three_layer_haskell_cake.html

2 2

Identity operator for types
by Juan Miguel Vilar 18 May '19

18 May '19

Hi, Café: I am not sure how to make the question, but the idea is to have a type operator that returns the same type. Let me show what I need. I have some type like this: data Example f t = Example (f t) So if I want a type variable that contains a list of integers, I can use Example [] Int and then treat the content like a list: f :: Example [] Int -> Int f (Example l) = length l Now, the problem is what can I do to have a type that contains a single Int? Is there a sort of id for types so that I can write f :: Example ?? Int -> Int f (Example i) = 2 * i ? Thanks in advance Juan Miguel Vilar -- Juan Miguel Vilar Torres Profesor titular de universidad Departamento de Lenguajes y Sistemas Informáticos Escuela Superior de Tecnología y Ciencias Experimentales Universitat Jaume I Av. de Vicent Sos Baynat s/n 12071 Castelló de la Plana (Spain) Tel: +34 964 72 8365 Fax: +34 964 72 8435 jvilar(a)uji.es

4 6

How to express a logic matrix clearly?
by Magicloud Magiclouds 17 May '19

17 May '19

Hi, I have trouble describing this clearly. Let me show code directly. data Rule1 = A1 | A2 | A3 data Rule2 = B1 | B2 | B3 foo a b = if a == A1 then if b == B1 then fun1 else if b == B2 then fun2 else if b == B3 then fun3 else fun4 ... Basically, Rule1 and Rule2 compose a matrix, for each case of Rule1 and Rule2, I need to do different things. Above is already long and not quite clear, and it is far from complete. So my question is, is there a way/lib that I can make this clear to read/understand?

4 5

Re: [Haskell-cafe] Dispatching user code at runtime, injecting appropriate typeclass instances into user code scope
by Evgeny Permyakov 16 May '19

16 May '19

Hi. reflection is about selecting a type instance of a typeclass that is known to exist over type. Completely different thing. Monads ... I guess, using monadic context in some way is an option, but not exactly what I have in mind. Still, worth looking into. On Thu, 16 May 2019 at 10:20, Georgi Lyubenov <godzbanebane(a)gmail.com> wrote: > Hi, > > It seems like the "extensible" parts you want is something similar to most > extensible effects stuff. Perhaps check out the "Member stuff" from the > "Freer Monads, More Extensible Effects" paper and some EE libraries > (freer-simple, fused-effects, polysemy)? Also, if you want runtime > typeclasses reflection <http://hackage.haskell.org/package/reflection> can > help. > > ======= > Georgi >

1 0

Dispatching user code at runtime, injecting appropriate typeclass instances into user code scope
by Evgeny Permyakov 16 May '19

16 May '19

Let's suppose that at runtime I create a hardware context and test it for a set of supported operation and want to adapt the way I work with it based on the set of operations available. (RL example: OpenGL extension discovery and use) Naturally, I can create a function that checks hardware and then, based on the result, returns different dictionaries of functions over the context, maybe as closures. This is verbose and crude, even if it shall work. However, I want to work with the context using a typeclass interface. It isn't hard when number of options is low. I suppose, we can use something like typeclass Context a where > { dispatch :: MonadIO m => forall k . Context a -> (forall a . Testable1 > a -> a -> m k) -> (forall a. Testable2 a -> a -> m k ) -> a -> m k } > Here, Context typeclass defines a function that selects appropriate handler from the set of user-provided functions and each instance takes the function it likes. Fine. The problems are twofold: - This is not extensible, the set of possible cases is defined on the definition of Context typeclass - This approach is hardly appropriate if we have a lot of cases, For example, if context may support ten optional operation sets in addtion to basic one, the number of possible cases *dispatch* needs to support A more modular approach is needed, something like (pseudocode) dispatch :: typeclassSet Defined, -- collection of defined typeclasses typeClass Tested, -- what we test for Dispatchable a, Defined a -- what we test =>forall b. (forall a . Defined a => a -> b) -- 'fallback' function -> (forall a . Defined a, Tested a => a -> b) -- this is called if A supports Tested interface. -> b This way one can gradually inject typeclass instances into scope. But how I can do it? PS. Naturally, I don't want to expose internals of the type I dispatch over, it is an abstract type.

1 0

Speeding up compilation of a happy generated parser
by Nathan Bloomfield 15 May '19

15 May '19

Hello all! I'm using Alex/Happy to generate a parser for PHP. This is my first go at using a parser generator instead of parser combinators and it's been going pretty smoothly so far, but I've hit a snag. Compiling the happy-generated parser is excruciatingly slow -- 20+ minutes with -O0 -- which messes up the typically very fast feedback loop haskell+ghci allows. Running the code is great; my quickcheck test suite is very fast. But compiling and loading into ghci are so slow that iterating on the project further is not practical until I can figure out how to speed it up. Are there any folklore techniques for dealing with this problem, or any resources about how to profile/debug slow compilation? I'm on macos using Stack with lts-13.21, which includes happy-1.19.10. I tried the ideas in this known issue: https://github.com/simonmar/happy/issues/109. I also tried downgrading to lts-6.35 (the most recent with GHC 7.*), all with similar results. I imagine some of this slowdown is inevitable because of the grammar's size; it has ~275 nonterminals and the generated `Parser.hs` module is 3.8MB. Usually for a problem like this I'd break the module up into smaller pieces that won't change as often, but in this case it's an opaque monolith generated by happy. I also see that the generated code doesn't have type signatures on all top level functions. Here's the relevant output from GHC with -v2 enabled: ``` *** Parser [PHP.Parse.Parser]: !!! Parser [PHP.Parse.Parser]: finished in 1980.24 milliseconds, allocated 3155.733 megabytes *** Renamer/typechecker [PHP.Parse.Parser]: !!! Renamer/typechecker [PHP.Parse.Parser]: finished in 243923.86 milliseconds, allocated 178189.005 megabytes *** Desugar [PHP.Parse.Parser]: Result size of Desugar (before optimization) = {terms: 1,346,664, types: 672,082,252, coercions: 789, joins: 0/9,651} Result size of Desugar (after optimization) = {terms: 834,353, types: 285,053,589, coercions: 246,053, joins: 235/735} !!! Desugar [PHP.Parse.Parser]: finished in 103983.68 milliseconds, allocated 17597.213 megabytes *** Simplifier [PHP.Parse.Parser]: Result size of Simplifier iteration=1 = {terms: 1,059,012, types: 69,942,882, coercions: 1,934,739, joins: 235/1,935} Result size of Simplifier iteration=2 = {terms: 815,760, types: 64,805,160, coercions: 1,368,873, joins: 233/1,929} Result size of Simplifier = {terms: 776,400, types: 64,474,214, coercions: 1,297,320, joins: 233/1,929} !!! Simplifier [PHP.Parse.Parser]: finished in 197842.50 milliseconds, allocated 116983.797 megabytes *** CoreTidy [PHP.Parse.Parser]: Result size of Tidy Core = {terms: 776,400, types: 64,474,214, coercions: 1,297,320, joins: 233/1,929} !!! CoreTidy [PHP.Parse.Parser]: finished in 97776.92 milliseconds, allocated 11254.968 megabytes *** CorePrep [PHP.Parse.Parser]: Result size of CorePrep = {terms: 795,714, types: 66,237,082, coercions: 1,297,320, joins: 233/4,234} !!! CorePrep [PHP.Parse.Parser]: finished in 7911.78 milliseconds, allocated 2564.067 megabytes *** Stg2Stg: *** CodeGen [PHP.Parse.Parser]: !!! CodeGen [PHP.Parse.Parser]: finished in 7048.73 milliseconds, allocated 6407.563 megabytes *** Assembler: *** CorePrep [PHP.Parse.Parser]: Result size of CorePrep = {terms: 795,714, types: 66,237,082, coercions: 1,297,320, joins: 233/4,234} !!! CorePrep [PHP.Parse.Parser]: finished in 3069.67 milliseconds, allocated 2564.018 megabytes *** Stg2Stg: *** CodeGen [PHP.Parse.Parser]: !!! CodeGen [PHP.Parse.Parser]: finished in 5970.62 milliseconds, allocated 6634.422 megabytes *** Assembler: *** Deleting temp files: Warning: deleting non-existent /var/folders/td/sxyy9wl919740vddr49g8nth0000gn/T/ghc1272_0/ghc_70.s Warning: deleting non-existent /var/folders/td/sxyy9wl919740vddr49g8nth0000gn/T/ghc1272_0/ghc_72.c Warning: deleting non-existent /var/folders/td/sxyy9wl919740vddr49g8nth0000gn/T/ghc1272_0/ghc_74.c ``` -- Nathan Bloomfield Systems Analyst, Team Neutron Automattic, Inc.

1 0

Metaprogramming Summer School (August 2019): call for applications
by Jeremy Yallop 15 May '19

15 May '19

==================================================================== Second International Summer School on Metaprogramming Schloss Dagstuhl, Leibniz Center for Informatics, Germany 11th-16th August 2019 (the week before ICFP'19) https://www.cl.cam.ac.uk/events/metaprog/2019/ ==================================================================== Metaprogramming is an approach to constructing programs by treating program fragments (such as expressions or types) as values that the program can manipulate. Metaprogramming comes in various forms --- for example, * in dependently-typed programming terms appear within types, supporting the construction of precise specifications of functions and data. * in multi-stage programming expressions are program values, making it possible to write safe program generation programs that can significantly improve performance. * in languages with macros programs execute partly during compilation and partly at run-time, eliminating the sharp distinction between built-in and user-defined constructs. * embedded domain-specific languages reuse host language features such as syntax and type-checking for convenient definition of little languages suited to a particular endeavour. Metaprogramming has many applications, including genericity, proof automation, language extensibility and user-defined optimization. The goal of the summer school is to explore the state-of-the art in metaprogramming and its applications, covering both theory and practice. -------------------------------------------------------------------- Lecturers and courses Oleg Kiselyov (Tohoku University) From the tagless-final cookbook: simple hardware description language and optimization-by-evaluation Matthew Flatt (University of Utah) Building Languages with Racket Conor McBride (University of Strathclyde) TBD Jonathan Protzenko (Microsoft Research Redmond) Meta-F*: efficient meta-programming of the F* compiler at every stage -------------------------------------------------------------------- Prerequisites The school is aimed at graduate students in programming languages and related areas, but is open to researchers, practitioners and strong masters students with the support of a supervisor. Some experience of typed functional programming in Haskell, OCaml, Scala, or a similar language will be assumed. -------------------------------------------------------------------- Costs Thanks to the Schloss Dagstuhl subsidies, accommodation costs are as follows, and the dates are immediately before ICFP'19 (also in Germany): Single-occupancy accommodation: €420 Double-occupancy accommodation: €330 Accommodation costs include full board (in a single- or double-occupancy room, including meals during stay) from Sunday 11 August (evening) to Friday 16 August (afternoon). -------------------------------------------------------------------- Application procedure You will need to complete the online registration form at: https://www.cl.cam.ac.uk/events/metaprog/2019/application.html and ensure your referees send your references to: metaprog-2019(a)cl.cam.ac.uk by the application deadline. TIMETABLE * 30 June: Application and reference letters deadline. * 10 July: Notification of acceptance. * 11 August: Summer school. -------------------------------------------------------------------- Further information For any questions relating to the school, please contact the organisers (Jeremy Yallop, Ohad Kammar, Yukiyoshi Kameyama) at metaprog-2019(a)cl.cam.ac.uk

1 0

[ANN] stdio-0.2.0.0
by Dong Han 15 May '19

15 May '19

Dear Haskellers, Today I'm very happy to announce a new beta version of stdio is released on hackage <http://hackage.haskell.org/package/stdio>, there're some large additions in this version: - Add UDP module. - Add JSON module. - Add ToText class to Std.Data.TextBuilder module. The largest addition is a new JSON module, features full RFC 8259 compliance <https://github.com/haskell-stdio/JSONTestSuite> and 2~3x faster performance <https://github.com/haskell-stdio/stdio/tree/master/bench/json>. Try to bring big improvements over a very mature library like aeson is not an easy task, parts of the improvements come from faster Parser and Builder infrastructures in stdio. But we also made a few other improvements: - To improve building lookup table during JSON parsing(and many other formats as well), An ordered map module based on sorted vectors and binary-search is also added, there're actually four modules providing similar functions to containers: - Std.Data.Vector.FlatMap - Std.Data.Vector.FlatIntMap - Std.Data.Vector.FlatSet - Std.Data.Vector.FlatIntSet These data structures have different time and memory characteristics from tree-based ones, and suits some situations better, e.g. intermediate lookup table. - To improve JSON string parsing, we made an UTF-8 validation state machine with JSON unescaping logic built-in written in C, combine with the ability to scan a whole chunk of input(provided by our new Parser, namely scanChunks), we now have faster JSON string parsing performance than some native code(JSON.parse from nodejs). - Numeric parsing is also improved, e.g. we changed Integer decoding loop to use machine words if range permits, then covert the result to Integer rather than use Integer all the time. There're also lots of improvements and simplifications contribute to faster performance. Overall this is good proof that our new Parser and Builder infrastructures work well. Besides the JSON module, another important addition is the ToText class in Std.Data.TextBuilder, which is also derivable via generics. The format is chosen to follow Show class as much as possible, this is a very handy class when you need to quickly turn something into a builder or text. A UDP module is added quite easily since the IO manager part is in place. Due to the message based nature, the API is quite different from TCP, design suggestions are welcomed! Happy hacking! ~Cheers Han Dong

1 0

Scrap your boilerplate
by The FLOSS Information 15 May '19

15 May '19

4 4