- Haskell-Cafe - Haskell.org

First and Only Call for Participation for IFL 2020 (Implementation and Application of Functional Languages)
by Jurriaan Hage 26 Aug '20

26 Aug '20

Hello, Please, find below the first and final call for participation for IFL 2020. Please forward these to anyone you think may be interested. Apologies for any duplicates you may receive. best regards, Jurriaan Hage Publicity Chair of IFL ======================================================= IFL 2020 32nd Symposium on Implementation and Application of Functional Languages Call for Participation venue: online 2nd - 4th September 2020 https://www.cs.kent.ac.uk/events/2020/ifl20/ ======================================================== ### 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 2020 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. ### Registration The symposium will be run via Zoom (zoom.us). If you can use Zoom, then you can participate. Please register for free via Eventbrite on the symposium webpage: https://www.cs.kent.ac.uk/events/2020/ifl20/ ### Programme Day 1: Wednesday, 2 September 12:45 Welcome 13:00 Nico Naus and Johan Jeuring: End-user feedback in multi-user workflow systems 13:30 Mart Lubbers, Haye Böhm, Pieter Koopman and Rinus Plasmeijer: Asynchronous Shared Data Sources 14:00 Pieter Koopman, Steffen Michels and Rinus Plasmeijer: Dynamic Editors for Well-Typed Expressions 14:30 Bas Lijnse and Rinus Plasmeijer: Asymmetric Composable Web Editors in iTasks 15:00 Social break 15:30 Sven-Olof Nyström: A subtyping system for Erlang 16:00 Andrew Marmaduke, Christopher Jenkins and Aaron Stump: Generic Zero-Cost Constructor Subtyping 16:30 Joris Burgers, Jurriaan Hage and Alejandro Serrano: Heuristics-based Type Error Diagnosis for Haskell - The case of GADTs and local reasoning 17:00 Social break 17:30 Kavon Farvardin and John Reppy: A New Backend for Standard ML of New Jersey 18:00 Chaitanya Koparkar, Mike Rainey, Michael Vollmer, Milind Kulkarni and Ryan R. Newton: A Compiler Approach Reconciling Parallelism and Dense Representations for Irregular Trees 18:30 Hans-Nikolai Vießmann and Sven-Bodo Scholz: Effective Host-GPU Memory Mangement Through Code Generation 20:00 Virtual Pub Day 2: Thursday, 3 September 10:00 Virtual Breakfast 13:00 Michal Gajda: Less Arbitrary waiting time 13:30 Sólrún Halla Einarsdóttir and Nicholas Smallbone: Template-based Theory Exploration: Discovering Properties of Functional Programs by Testing 14:00 Péter Bereczky, Dániel Horpácsi, Judit Kőszegi, Soma Szeier and Simon Thompson: Validating Formal Semantics by Comparative Testing 14:30 Social break 15:00 Gergo Erdi: An Adventure in Symbolic Execution 15:30 Joshua M. Schappel, Sachin Mahashabde and Marco T. Morazan: Using OO Design Patterns in a Functional Programming Setting 16:00 Filipe Varjão: Functional Programming and Interval Arithmetic with High Accuracy 16:30 Social break 17:00 Laith Sakka, Chaitanya Koparkar, Michael Vollmer, Vidush Singhal, Sam Tobin-Hochstadt, Ryan R. Newton and Milind Kulkarni: General Deforestation Using Fusion, Tupling and Intensive Redundancy Analysis 17:30 Benjamin Mourad and Matteo Cimini: A Declarative Gradualizer with Lang-n-Change 18:00 Maheen Riaz Contractor and Matthew Fluet: Type- and Control-Flow Directed Defunctionalization 19:30 Virtual Pub Day 3: Friday, 4 September 10:00 Virtual Breakfast 13:00 Michal Gajda: Towards a more perfect union type 13:30 Folkert de Vries, Sjaak Smetsers and Sven-Bodo Scholz: Container Unification for Uniqueness Types 14:00 Alejandro Díaz-Caro, Pablo E. Martínez López and Cristian Sottile: Polymorphic System I 14:30 Social break 15:00 Michal Gajda: Schema-driven mutation of datatype with multiple representations 15:30 Alexandre Garcia de Oliveira, Mauro Jaskelioff and Ana Cristina Vieira de Melo: On Structuring Pure Functional Programs with Monoidal Profunctors 16:00 Sara Moreira, Pedro Vasconcelos and Mário Florido: Resource Analysis for Lazy Evaluation with Polynomial Potential 16:30 Social break 17:00 Neil Mitchell, Moritz Kiefer, Pepe Iborra, Luke Lau, Zubin Duggal, Hannes Siebenhandl, Matthew Pickering and Alan Zimmerman: Building an Integrated Development Environment (IDE) on top of a Build System 17:30 Evan Sitt, Xiaotian Su, Beka Grdzelishvili, Zurab Tsinadze, Zongpu Xie, Hossameldin Abdin, Giorgi Botkoveli, Nikola Cenikj, Tringa Sylaj and Viktoria Zsok: Functional Programming Application for Digital Synthesis Implementation 18:00 Jocelyn Serot: HoCL: High level specification of dataflow graphs 19:30 Virtual Pub All times are in British Summer Time (BST), the local time in Canterbury, UK. So please translate these into your own time zone, using a service such as time and date.

1 0

doctest-extract
by Henning Thielemann 22 Aug '20

22 Aug '20

I have started an alternative implementation of 'doctest'. In contrast to the original one, doctest-extract extracts Haskell test-modules from doctest comments. This integrates better with Cabal and its package version resolution and the tests are compiled, not interpreted in GHCi. Disadvantage is that doctest-extract does not support all features of 'doctest', e.g. IO-tests. I uploaded a preview as package candidates to Hackage: $ cabal install $(for pkg in doctest-extract-0.0 doctest-lib-0.0 utility-ht-0.0.16 non-empty-0.3.3; do echo https://hackage.haskell.org/package/$pkg/candidate/$pkg.tar.gz; done) Extract test modules like so: $ doctest-extract -i src/ -o test/ --executable-main=Test/Main.hs --import-tested $$(cat test-module.list) There is still a problem: A failing QuickCheck test does not abort the whole test-suite. 'cabal test' will report success even if one QuickCheck property test fails. I wonder what is the proposed way to make a failing property fail the test-suite? I could use (QC.whenFail exitFailure). Is this the intended way?

4 8

ICFP tutorial on hardware design using BH (Bluespec Haskell)
by Rishiyur Nikhil 20 Aug '20

20 Aug '20

REMINDER: My tutorial "Designing Hardware Systems and Accelerators with Open-Source BH (Bluespec Haskell)" on Aug 23 at #ICFP2020 (online). Please pre-install tools; instructions in tutorial repo README: https://tinyurl.com/y29zxrow . ICFP web page: https://icfp20.sigplan.org . #RISCV #Bluespec #BSV #BH.

1 0

Dhall for Word8, Word16, Double, etc
by ☂Josh Chia (謝任中) 20 Aug '20

20 Aug '20

Hi, Let's say I have a record type: data Foo = Foo { v :: Word16 } I want to have a FromDhall instance for Foo. I know this is easy to do if v is Integer instead of Word16. But v is Word16. Does Dhall enable the user to cleanly express how to input a Word16 with the requisite range checks, or is the user expected to only use Integer and do his own conversion and range checks within Haskell after inputting the Integer from Dhall? I have a record with Word32, Word16, Word8 & Double fields instead of Integer & Scientific.

3 3

Third Call for Participation: ICFP 2020
by Sam Tobin-Hochstadt 19 Aug '20

19 Aug '20

===================================================================== Third Call for Participation ICFP 2020 25th ACM SIGPLAN International Conference on Functional Programming and affiliated events August 23 - August 28, 2020 Online http://icfp20.sigplan.org/ Pre-registration ends August 21! ==================================================================== ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. The conference covers the entire spectrum of work, from practice to theory, including its peripheries. Watch our new video, and Don't Stop ICFP: https://www.youtube.com/watch?v=Fte5wwnwCws Pre-registration ends August 21st! https://icfp20.sigplan.org/attending/Registration This year, the conference will be a virtual event. All activities will take place online. There are training sessions for Clowdr, our new online platform, on August 20 and 21. https://icfp20.sigplan.org/track/icfp-2020-clowdr-training#program The main conference will take place from August 24-26, 2020 during two time bands. The first band will be 9AM-5:30PM New York, and will include both technical and social activities. The second band will repeat (with some variation) the technical program and social activities 12 hours later, 9AM-5:30PM Beijing, the following day. We've written a blog post about how conference mirroring will work for ICFP: https://blog.sigplan.org/2020/08/04/come-to-virtual-icfp/ We’re excited to announce our two invited speakers for 2020: Evan Czaplicki, covering the Elm programming language and hard lessons learned on driving adoption of new programming languages; and Audrey Tang, Haskeller and Taiwan’s Digital Minister, on how software developers can contribute to fighting the pandemic. ICFP has officially accepted 37 exciting papers, and (as a fresh experiment this year) there will also be presentations of 8 papers accepted recently to the Journal of Functional Programming. Co-located symposia and workshops will take place the day before and two days immediately after the main conference. Registration is now open. The early registration deadline is August 8th, 2020. Registration is not free, but is significantly lower than usual. Students who are ACM or SIGPLAN members may register for FREE before the early deadline. https://regmaster.com/2020conf/ICFP20/register.php New this year: Attendees will be able to sign-up for the ICFP Mentoring Program (either to be a mentor, receive mentorship or both). * Overview and affiliated events: http://icfp20.sigplan.org/home * Full Schedule: https://icfp20.sigplan.org/program/program-icfp-2020 * Accepted papers: http://icfp20.sigplan.org/track/icfp-2020-papers#event-overview * JFP Talks: https://icfp20.sigplan.org/track/icfp-2020-jfp-talks#event-overview * Registration is available via: https://regmaster.com/2020conf/ICFP20/register.php Early registration ends 8 August, 2020. * Programming contest: https://icfpcontest2020.github.io/ * Student Research Competition: https://icfp20.sigplan.org/track/icfp-2020-Student-Research-Competition * Tutorials https://icfp20.sigplan.org/track/icfp-2020-tutorials#program * Follow us on Twitter for the latest news: http://twitter.com/icfp_conference This year, there are 10 events co-located with ICFP: * Erlang Workshop (8/23) * Haskell Implementors' Workshop (8/28) * Haskell Symposium (8/27-8/28) * Higher-Order Programming with Effects (8/23) * miniKanren Workshop (8/27) * ML Family Workshop (8/27) * OCaml Workshop (8/28) * Programming Languages Mentoring Workshop (8/23) * Scheme Workshop (8/28) * Type-Driven Development (8/23) As well as tutorials on 8/23, 8/27, and 8/28. ### ICFP Organizers General Chair: Stephanie Weirich (University of Pennsylvania, USA) Program Chair: Adam Chlipala (MIT, USA) Artifact Evaluation Co-Chairs: Brent Yorgey (Hendrix College, USA) Ben Lippmeier (Ghost Locomotion, Australia) Industrial Relations Chair: Alan Jeffrey (Mozilla Research, USA) Programming Contest Organizer: Igor Lukanin (Kontur, Russia) Publicity and Web Chair: Sam Tobin-Hochstadt (Indiana University, USA) Student Research Competition Chair: Youyou Cong (Tokyo Institute of Technology, Japan) Workshops Co-Chair: Jennifer Hackett (University of Nottingham, UK) Leonidas Lampropoulos (University of Pennsylvania, USA) Video Chair: Leif Andersen (Northeastern University, USA) Student Volunteer Co-Chair: Hanneli Tavante (McGill University, Canada) Victor Lanvin (IRIF, Université Paris Diderot, France)

1 0

Re: [Haskell-cafe] Counterintuitive ScopedTypeVariables behaviour
by Anthony Clayden 18 Aug '20

18 Aug '20

Well I'll go to 'foot of our stairs! > [Erik] the above feels very similar to writing something like: > add :: _ => a -> b -> _ > add x y = x + y > > But that doesn't type check, since the types `a` and `b` are not the same, > but `+` needs them to be. Replying to both Erik's and Tom's replies. I'm afraid Alexis' went completely over my head. As I mentioned, the `PatternSignatures` part of `ScopedTypeVariables` has been around a long time. So long that it's in Hugs 2006. The same? Not quite. If I try Tom's O.P. add (x :: aa) (y :: b) = x + y Hugs complains 'Type annotation uses distinct variables aa and b where a single variable was inferred'. So the short answer is: if that's how your intuitions go, use Hugs. My explanation was going to be (this now only applies for GHC): just as using `x, y` as the dummy arguments to `add` doesn't come with any guarantees they're distinct values; so using `aa, b` as the dummy variables doesn't come with any guarantees they're distinct types. Specifying distinct tyvars in a stand-alone signature is different: you're giving the most general type to which `add` must conform. And using distinct tyvars means `add` must cope with those being distinct types. (Which it's equation doesn't.) BTW GHC accepts: add (x :: aa) (y :: b) = (x + y :: aa) :: b which shows how happy it is to use distinct tyvars for the same type. AntC

1 0

Re: [Haskell-cafe] Counterintuitive ScopedTypeVariables behaviour
by Anthony Clayden 18 Aug '20

18 Aug '20

Hi Tom, I see nothing bizarre nor counterintuitive. Perhaps you need to retrain your intuitions ;-) > I have just noticed that with ScopedTypeVariables one can write the > following bizarre definition > > -- Inferred signature: > -- add :: Num a => a -> a -> a > add (x :: a) (y :: b) = x + y What do you think is bizarre? GHC makes a reasonable attempt to use the tyvar names you put in a signature -- remembering that alpha-renaming means the name is not really significant. I can get `add :: Num c => c -> c -> c`, etc. > The reason for this behaviour is that > >>* in all patterns other than pattern bindings, a pattern type *>>* signature may mention a type variable that is not in scope; in this *>>* case, the signature brings that type variable into scope. * OK so your `PatternSignatures` (a part of `ScopedTypeVariables` that existed long before the more dubious parts of that extension) are bringing `a`, `b`, into scope. It might have been clearer if you'd used `b`, `c`, to avoid confusing yours with some `a` that might have been lurking in the environment. Anyhoo your definition is equivalent to this, by eta-reduction: add = (+) and `(+) :: Num a => a -> a -> a` from the Prelude. So the inferred signature for `add` must be the same, possibly alpha-renamed. Perhaps you think you could add an Int to a Float, as you can in languages (COBOL, Algol 68) with implicit type coercion? That's not what the signatures from the Prelude Num methods support. And with Haskell's proclivity for partial application, type inference would rapidly become incoherent; so we don't do that. > But this leads to a rather puzzling user experience. Was it really > not possible to design this extension in a way that would allow > bringing new type variables into scope locally but not allow them to > unify with other type variables from outer scopes? > > To be more concrete, what I would like to see is a design where `k` is > allowed because the type `a` (bound within a pattern) does not need to > unify with anything but `k2` is not allowed because `a` is forbidden > to unify with `b`. ... No: any tyvar might unify with any other. You can't ban tyvars from unifying. Unification would be useless if you can't unify globally. That's why all tyvars are (implicitly) universally quantified. (With the exception of existentially-quantified tyvars as you quote, which is another can of worms and we don't want to go there.) You can use as many distinct tyvars as you like, but if type inference resolves them to the same type, it must use the same tyvar in the inferred signature. > I believe this design might lead to much less puzzling behaviour. > Would it be possible (within a new extension, of course) or have I > overlooked something? There's the `GADTs` or `TypeFamilies` extensions that introduce `~` as a constraint-level equality on types. I suppose we might use that, but (thinking creatively) any of these would be a legitimate resulting signature; how should GHC choose amongst them? add :: (Num a, a ~ b) => a -> b -> a add :: (Num b, a ~ b) => a -> b -> b add :: (Num a, Num b, a ~ b) => a -> b -> a The point is: the return type for `add` aka `(+)` must be the same as the first argument type must be the same as the second argument type must be the same as the `Num` constraint applies to. Any of those three signatures I've given (and there could be several more in the same vein) obfuscates what's going on. Actually, thinking a bit more: we want to infer a 'Principal type' (see wikipedia). Precisely because there's no good reason to choose amongst those I gave, none of them can be Principal. AntC

3 2

Library for serial communications?
by Christian Gosch 15 Aug '20

15 Aug '20

Hi Haskellers, I was wondering if there is a "canonical" choice of library for using serial interfaces from within Haskell. I found a few in Hackage, but all of them seem to not have seen updates in a few years. Any hint is much appreciated. Christian

1 0

3rd Call for Papers: REBLS 20: Reactive and Event-Based Languages and Systems
by Ivan Perez 14 Aug '20

14 Aug '20

Dear all, Apologies if you see this multiple times. Gentle reminder that the REBLS workshop will take place online. The deadline has been extended till next week. Cheers, Ivan CALL FOR PAPERS 7th Workshop on Reactive and Event-based Languages and Systems (REBLS 2020) co-located with the SPLASH Conference *** BOTH EVENTS WILL NOW TAKE PLACE ONLINE *** Sun 15 - Fri 20 November 2020 Website: https://2020.splashcon.org/home/rebls-2020 IMPORTANT DATES Submission Deadline: 21 Aug 2020 (extended) Author Notification: 18 Sep 2020 Camera Ready Deadline: 9 Oct 2020 INTRODUCTION Reactive programming and event-based programming are two closely related programming styles that are becoming more important with the ever increasing requirement for applications to run on the web or on mobile devices, and the advent of advanced High-Performance Computing (HPC) technology. A number of publications on middleware and language design -- so-called reactive and event-based languages and systems (REBLS) -- have already seen the light, but the field still raises several questions. For example, the interaction with mainstream language concepts is poorly understood, implementation technology is still lacking, and modularity mechanisms remain largely unexplored. Moreover, large applications are still to be developed, and, consequently, patterns and tools for developing large reactive applications are still in their infancy. This workshop will gather researchers in reactive and event-based languages and systems. The goal of the workshop is to exchange new technical research results and to better define the field by developing taxonomies and discussing overviews of the existing work. We welcome all submissions on reactive programming, functional reactive programming, and event- and aspect- oriented systems, including but not limited to: * Language design, implementation, runtime systems, program analysis, software metrics, patterns and benchmarks. * Formal models for reactive and event-based programming. * Study of the paradigm: interaction of reactive and event-based programming with existing language features such as object-oriented programming, pure functional programming, mutable state, concurrency. * Modularity and abstraction mechanisms in large systems. * Advanced event systems, event quantification, event composition, aspect-oriented programming for reactive applications. * Functional Reactive Programming (FRP), self-adjusting computation and incremental computing. * Synchronous languages, modeling real-time systems, safety-critical reactive and embedded systems. * Applications, case studies that show the efficacy of reactive programming. * Empirical studies that motivate further research in the field. * Patterns and best-practices. * Related fields, such as complex event processing, reactive data structures, view maintenance, constraint-based languages, and their integration with reactive programming. * Implementation technology, language runtimes, virtual machine support, compilers. * IDEs, Tools. The format of the workshop is that of a mini-conference. Participants can present their work in slots of 30 mins with Q&A included. Because of the declarative nature of reactive programs, it is often hard to understand their semantics just by looking at the code. We therefore also encourage authors to use their slots for presenting their work based on live demos. SUBMISSIONS REBLS encourages submissions of two types of papers: * Full papers: papers that describe complete research results. These papers will be published in the ACM digital library. * In-progress papers: papers that have the potential of triggering an interesting discussion at the workshop or present new ideas that require further systematic investigation. These papers will not be published in the ACM digital library. Format: * Submissions should use the ACM SIGPLAN Conference acmart Format with the two-column, sigplan Subformat, 10 point font, using Biolinum as sans-serif font and Libertine as serif font. All submissions should be in PDF format. If you use LaTeX or Word, please use the ACM SIGPLAN acmart Templates. The page http://www.sigplan.org/Resources/Author/#acmart-format contains instructions for authors, and a package that includes an example file acmart-sigplan.tex. * Authors are required to explicitly specify the type of paper in the submission (i.e., full paper, in-progress paper). * Full papers can be *up to* 12 pages in length, excluding references. In-progress papers can be *up to* 6 pages, excluding references. Papers do not need to make use of all pages, but they will be summarily rejected if they exceed the page limits. Instructions for the Authors: * Papers should be submitted through: https://rebls20.hotcrp.com/ * For fairness reasons, all submitted papers should conform to the formatting instructions. Submissions that violate these instructions will be summarily rejected. * Program Committee members are allowed to submit papers, but their papers will be held to a higher standard. * Papers must describe unpublished work that is not currently submitted for publication elsewhere as described by SIGPLAN’s Republication Policy (http://www.sigplan.org/Resources/Policies/Republication) Submitters should also be aware of ACM’s Policy and Procedures on Plagiarism. * All submissions are expected to comply with the ACM Policies for Authorship detailed at https://www.acm.org/publications/authors/information-for-authors. PROGRAM COMMITTEE Ivan Perez (PC Chair; NIA) Alan Jeffrey, Mozilla Research. Christiaan Baaij, QBayLogic. César Sánchez, IMDEA Software. Daniel Winograd-Cort, Target Corp. Edward Amsden, Black River Software, LLC. Guerric Chupin, University of Nottingham. Heinrich Apfelmus. Jonathan Thaler, University of Applied Sciences Vorarlberg. Louis Mandel, IBM Research. Manuel Bärenz, sonnen eServices GmbH. Marc Pouzet, Université Pierre et Marie Curie. Mark Santolucito, University of Yale. Neil Sculthorpe, University of Nottingham Trent. Noemi Rodriguez, Pontifícia Universidade Católica do Rio de Janeiro Oleksandra Bulgakova, Sukhomlynsky Mykolaiv National University Patrick Bahr, University of Copenhagen Takuo Watanabe, Tokyo Institute of Technology Tetsuo Kamina, Oita University Tom Van Cutsem, Nokia Bell Labs Yoshiki Ohshima, HARC / Y Combinator Research STEERING COMMITTEE Guido Salvaneschi, TU Darmstadt, Germany Wolfgang De Meuter, Vrije Universiteit Brussel, Belgium Patrick Eugster, Universita della Svizzera Italiana, Switzerland Francisco Sant'Anna, Rio de Janeiro State University, Brazil Lukasz Ziarek, SUNY Buffalo, United States For any questions, please use the form on the website or contact the Chair at ivan.perezdominguez(a)nasa.gov

1 0

[ANN] base64-bytestring-1.2.0.0
by Emily Pillmore 14 Aug '20

14 Aug '20

Hi everyone! I’m pleased to announce base64-bytestring-1.2.0.0. In this release, we cleared out the backlog of outstanding feature requests, correctness, and security fixes to present a new stable release. This constituted a major version bump due to the fact that the fixes changed the semantics of the decode function for some inputs, making the decoding process more correct than it was previously. To illustrate one of the changes to correctness, here’s a quick quiz: ``` What are the correct results of Base64-decoding the strings "ZK==“, "Zm9vYE==“, or "Zm9vYmD=" ? ``` The answer is: the decoding should fail. Why? Even though the above strings may look like externally valid Base64 strings, they are technically impossible to construct such string via Base64-encoding from any binary data in the first place. Previously (and historically in every version up until this release), they would pass decoding, but fail to roundtrip: ``` П> decode "ZK==" Right "d" П> encode "d" "ZA==" П> decode "Zm9vYE==" Right "foo`" П> encode "foo`" "Zm9vYA==" П> decode "Zm9vYmD=" Right "foob`" П> encode "foob`" "Zm9vYmA=" ``` This was the result of leaking bits when decoding the final quanta of the bytestring. I caught this, and provided a fix. Now here’s an interesting point: there are very few libraries out there that actually address this problem! In fact, there was only one other library out there that I was able to find that was fully correct-per-RFC-spec, which was the Java Amazon SDK. So I guess we can be proud of Haskell in that sense now? I’ve implemented the same in my `base64` library on hackage using the same bitmasking verification techniques, so that one is up to date as well. Anyway, cheers and happy hacking, Emily

1 0