- Haskell-Cafe - Haskell.org

Reactive and Event-Based Languages and Systems (REBLS 2020) -- Call for Papers
by Ivan Perez 23 May '20

23 May '20

CALL FOR PAPERS 7th Workshop on Reactive and Event-based Languages and Systems (REBLS 2020) co-located with the SPLASH Conference Chicago, Illinois, USA Sun 15 - Fri 20 November 2020 Website: https://2020.splashcon.org/home/rebls-2020 IMPORTANT DATES Submission Deadline: 24 Jul 2020 Author Notification: 24 Aug 2020 Final Submission Deadline: 25 Sep 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 Rodrigues, 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 ORGANIZING 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

Munich Virtual Haskell Meeting, 2020-05-25 @ 19:30
by Leah Neukirchen 22 May '20

22 May '20

Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Monday, May 25 at 19:30. **Due to curfew in Bavaria, this meeting will take place online!** For details see here: http://muenchen.haskell.bayern/dates.html A Google Meet link to join the room will be provided on Monday. Everybody is welcome, especially the Haskellers from Bavaria that do not usually come to our Munich meetings due to travel distance! cu, -- Leah Neukirchen <leah(a)vuxu.org> https://leahneukirchen.org/

1 0

To much symbols in dll
by Kees Bleijenberg 22 May '20

22 May '20

After a lot of trying I finally got my windows dll working (used by a Qt app). But after adding the package (aeson) I get: ld.exe: Error: export ordinal too large: 97839 There are a few messages about this problem. People talk about split-dll and gen-dll. But both seems more for building ghc itself. I tried gen-dll, but couldn't get it to work. I wonder if there is a solution for this problem? Kees

1 0

how to simplify ressources access and pipes steam
by PICCA Frederic-Emmanuel 21 May '20

21 May '20

Hello, I am writing a software which do some data treatement from hdf5 files. In order to access the data which are stored in arrays, I need to open and closes ressources. This is the purpose of the withHdf5PathP function. given a file f and a UhvPath I end up with this withUhvPathP :: (MonadSafe m, Location l) => l -> UhvPath -> ((Int -> IO Geometry) -> m r) -> m r withUhvPathP f (UhvPath m o d g w) gg = withHdf5PathP f m $ \m' -> withHdf5PathP f o $ \o' -> withHdf5PathP f d $ \d'-> withHdf5PathP f g $ \g' -> withHdf5PathP f w $ \w' -> gg (\j -> do mu <- get_position m' j omega <- get_position o' j delta <- get_position d' j gamma' <- get_position g' j wavelength <- getValueWithUnit w' 0 angstrom let positions = Data.Vector.Storable.fromList [mu, omega, delta, gamma'] let source = Source wavelength pure $ Geometry Uhv source positions Nothing) then I use this like this forever $ do (Chunk fp from to) <- await withFileP (openH5 fp) $ \f -> withHdf5PathP f imgs $ \dimgs -> withUhvPathP f dif $ \getDiffractometer -> withSamplePathP f samp $ \getSample -> forM_ [from..to-1] (\j -> yield =<< liftIO (DataFrameHkl <$> pure j <*> get_image' det dimgs j <*> getDiffractometer j <*> getSample j)) so once I open the resources, I use the getDiffratometer ((Int -> IO Geometry) -> m r) function give the position on the stream and it return the value at the j position. the purpose of this is to open the ressources only once at the begining and then send the values in a Pipe via the yield function of pipes package. I hope, I was clear. 1) I find the withUhvPathP sort of ugly, and I would like to know if it could be written more elegantly, because I will need to write a lot's of these function for different types. 2) It is the right way to design a solution to my problem (open ressources and send each values into a stream). thanks for you attention. Frederic

4 5

Workshop on Logic Programming: Trends, Extensions, Applications, 28-29 May 2020
by Ekaterina Komendantskaya 19 May '20

19 May '20

We invite participants to the on-line workshop on * Trends, Extensions, Applications and Semantics of Logic Programming* Logic programming is a framework for expressing programs, propositions and relations as Horn clause theories, and for automatic inference in these theories. Horn clause theories are famous for their well-understood declarative semantics, in which models of logic programs are given inductively or coinductively. At the same time, Horn clauses give rise to efficient inference procedures, usually involving resolution. Logic programming found applications in type inference, verification, and AI. While logic programming was originally conceived for describing simple propositional facts, it was extended to account for much more complex theories. This includes first-order theories, higher-order theories, inductive and coinductive data, and stochastic/probabilistic theories. The aim of this workshop is to bring together researchers that work on extensions of logic programming and inference methods, and to foster an exchange of methods and applications that have emerged in different communities. Keynote talk: *Dale Miller*. Structural Proof-Theory and Logic Programming <https://www.coalg.org/tease-lp/2020/dale-miller-structural-proof-theory-and…> Invited tutorial: *Uli Sattler*.* Description Logics and Ontology Languages - an introduction and overview* In light of COVID-19, we organise TEASE-LP as a virtual workshop and online-only event. To achieve broad participation, we use three different mediums: Discussion Forum, Pre-recorded lightning talks, Live sessions with invited and contributed live talks. Further details can be found here: https://www.coalg.org/tease-lp/workshop-schedule/. Registration is free, but we require all participants to register at https://teaselp.flarum.cloud/ For any further queries, please contact the organisers: Henning Basold <henning(a)basold.eu> Katya Komendantskaya <ek19(a)hw.ac.uk>

1 0

tuple and pattern synonym
by Kazu Yamamoto 18 May '20

18 May '20

Hi, I have a question about PatternSynonyms. Suppose we have: data Foo = Foo Int Int I would like to define a pattern as follows: pattern P :: (Int,Int) -> Foo pattern P (x,y) = Foo x y But this results in "parse error on input ‘(’". Are there any ways to use tuple in the left side hand of patterns? This is important to maintain backward compatibility for the "network" library. If there is no way, I will define Foo as: data Foo = Foo (Int,Int) -- awkward and define P as: pattern P :: (Int,Int) -> Foo pattern P xy = Foo xy Regards, --Kazu

3 4

Re: [Haskell-cafe] Relationship between ((a -> Void) -> Void) and (forall r. (a -> r) -> r)
by Olaf Klinke 18 May '20

18 May '20

> You're misplacing your quantifiers. > > (a -> Void) -> Void) > > is not isomorphic to > > forall r. (a -> r) -> r > > but *is* isomorphic to > > (a -> (forall r. r)) -> (forall r. r) > ...which is because you could _define_ Void to be (forall r. r): {-# LANGUAGE Rank2Types #-} newtype Void = Void {absurd :: forall r. r} In practice, Void used to be implemented as data Void = Void Void before it became just data Void by means of EmptyDataDecls extension. The latter has the advantage that there is no constructor named 'Void'. In reality of course, Void does have an element, bottom, which it shares with all other types. Hence the 'absurd' function that returns the bottom in type r when given the bottom in type Void. But as you know the correspondence between types and theorems in intuitionistic logic explicitly regards only total values. Excersise: Prove that intuitionistically, it is absurd to deny the law of excluded middle: Not (Not (Either a (Not a))) There is a whole world to be discovered beneath the total values. Think about the type () as truth values and what universal quantification could be. Olaf

7 10

Re: [Haskell-cafe] Relationship between ((a -> Void) -> Void) and (forall r. (a -> r) -> r)
by Olaf Klinke 17 May '20

17 May '20

> 2. Double negation enables a translation of classical logic in > intuitionistic logic, here embedded in Haskell: > Below I'll give a variant of Li-yao's logic language in Haskell98. Again, the open set model may help to visualize CPS translation: Consider all open sets A on the real line which are fixed points of double negation. All intervals are of this kind, but poking holes in them destroys this property: ---(====)(====)--- A ===)----------(=== Not A ---(==========)--- Not (Not A) Denote the collection of open sets invariant under double negation by X. As the example above demonstrates, X is not closed under set union. But set intersection preserves membership of X. So we have a funny logic that has (&&) but no (||). The CPS trick is now to define a new (||) by means of double negation: ---(====)--------- A ---------(====)--- B ---(====)(====)--- set union of A and B ---(==========)--- A || B, double negation of set union. In fact X is the largest Boolean algebra contained in the Heyting algebra of open sets. In terms of Haskell, we define a new Either: Either' a b = ((Either a b) -> Void) -> Void Looks familiar? Indeed, in this thread we already proved Either' a (Not a). This says that Not A is the Boolean complement of A in X. Using (,) and Either' for (&&) and (||) you can realize all proofs of classical propositional logic in Haskell without GADTs. Olaf

2 1

Re: [Haskell-cafe] Decorating exceptions with backtrace information
by Carter Schonwald 14 May '20

14 May '20

On Fri, May 8, 2020 at 9:32 AM Carter Schonwald <carter.schonwald(a)gmail.com> wrote: > ben, could you please email the libraries list with this too? This seems > like a core libraries / base change rather than a ghc-the-compiler change > > On Thu, May 7, 2020 at 6:57 PM Michael Sloan <mgsloan(a)gmail.com> wrote: > >> Thanks so much for making a proposal for this, Ben!! It's great to see >> progress here. >> >> I'm also glad that there is now a proposal process. I made a fairly >> similar proposal almost exactly 5 years ago to the libraries list - >> https://mail.haskell.org/pipermail/libraries/2015-April/025471.html - >> but without the subtlety of particular backtrace representations. Skimming >> the ensuing thread may still be informative. >> >> In particular, there is one thing I would like to highlight from that old >> proposal. I think it'd be good to have a standard way to represent a chain >> of exceptions, and build this into `catch` and `finally`. Python and Java >> both have a mechanism for this, and both refer to it as a "cause" >> exception. When an exception is thrown during exception handling, the >> exception being handled is preserved as its "cause". I find this mechanism >> to be incredibly useful in Java, it has made the underlying issue much >> clearer in many cases, and in other cases at least provides helpful >> context. I have no doubt such a mechanism would have saved me many hours >> of debugging exceptions in Haskell systems I've worked on in the past. >> >> I considered commenting about that directly on the proposal, but I figure >> this is a better place to suggest expanding the scope of the change :) . >> Totally understandable if you want to keep this proposal focused on >> stacktraces, but I think it'd be good to consider this as a potential >> future improvement. >> >> -Michael >> >> On Thu, May 7, 2020 at 3:55 PM Ben Gamari <ben(a)well-typed.com> wrote: >> >>> >>> Hi everyone, >>> >>> After a nice discussion on IRC about the unfortunate state of error >>> reporting in Haskell, I felt compelled to write down some long-lingering >>> thoughts regarding backtraces on exceptions. The result is GHC proposal >>> #330 [1]. I think the approach is viable and perhaps even >>> straightforward. I have the sketch of an implementation here [2]. >>> >>> Please have a look at the proposal and leave your comments. If there is >>> consensus it is possible that we could have this done for 8.12. >>> >>> Cheers, >>> >>> - Ben >>> >>> >>> [1] https://github.com/ghc-proposals/ghc-proposals/pull/330 >>> [2] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3236 >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs(a)haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >

7 15

CFP: GPCE 2020 − 19th International Conference on Generative Programming: Concepts & Experiences
by Erwan BOUSSE 13 May '20

13 May '20

----------------------------------------------------------------------- GPCE 2020: 19th International Conference on Generative Programming: Concepts & Experiences November 16-17, 2020 Chicago, IL (USA) (a part of the SPLASH series of conferences) https://conf.researchr.org/home/gpce-2020 ----------------------------------------------------------------------- --------------------------- CALL FOR PAPERS --------------------------- The ACM SIGPLAN International Conference on Generative Programming: Concepts & Experiences is a programming languages conference focusing on techniques and tools for code generation, language implementation, and product-line development. GPCE seeks conceptual, theoretical, empirical, and technical contributions to its topics of interest, which include but are not limited to: program transformation, staging, macro systems, preprocessors, program synthesis, and code-recommendation systems, domain-specific languages, language embedding, language design, and language workbenches, feature-oriented programming, domain engineering, and feature interactions, applications and properties of code generation, language implementation, and product-line development. Authors are welcome to check with the PC chair whether their planned papers are in scope. --------------------------- IMPORTANT DATES --------------------------- - Abstract submission: July 20, 2020 (Monday), AoE - Paper submission: July 27, 2020 (Monday), AoE - Author notification: September 9, 2020 (Wednesday) - Conference: November 16-17, 2020 --------------------------- PAPER SELECTION --------------------------- The GPCE program committee will evaluate each submission according to the following selection criteria: - Novelty. Papers must present new ideas or evidence and place them appropriately within the context established by previous research in the field. - Significance. The results in the paper must have the potential to add to the state of the art or practice in significant ways. - Evidence. The paper must present evidence supporting its claims. Examples of evidence include formalizations and proofs, implemented systems, experimental results, statistical analyses, and case studies. - Clarity. The paper must present its contributions and results clearly. --------------------------- PAPER CATEGORIES --------------------------- GPCE solicits three kinds of submissions: - Full Papers reporting original and unpublished results of research that contribute to scientific knowledge in any GPCE topic listed above. Full paper submissions must not exceed 12 pages excluding bibliography. - Short Papers presenting unconventional ideas or visions about any GPCE topic listed above. Short papers do not always require complete results as in the case of a full paper. In this way, authors can introduce new ideas to the community and get early feedback. Please note that short papers are not intended to be position statements. Short papers are included in the proceedings and will be presented at the conference. Short paper submissions must not exceed 6 pages excluding bibliography. Short papers must have the text “(Short Paper)” appended to their title, though any papers of 6 or fewer pages that are not tool demonstration papers will be considered as short papers. - Tool Demonstrations presenting tools for any GPCE topic listed above. Tools must be available for use and must not be purely commercial. Submissions must provide a tool description not exceeding 6 pages excluding bibliography and a separate demonstration outline including screenshots also not exceeding 6 pages. Tool demonstrations must have the keywords “Tool Demo” or “Tool Demonstration” appended in their title. If the submission is accepted, the tool description will be published in the proceedings. The demonstration outline will only be used by the program committee for evaluating the submission. --------------------------- PAPER SUBMISSION --------------------------- All submissions must use the ACM SIGPLAN Conference Format “acmart” (http://sigplan.org/Resources/Author/#acmart-format) Please be sure to use the latest LaTeX templates and class files. the SIGPLAN sub-format, and 10 point font. Consult the sample-sigplan.tex template and use the document-class \documentclass[sigplan,anonymous,review]{acmart}. Please do not make any changes to this format! To increase fairness in reviewing, a double-blind review process has become standard across SIGPLAN conferences. GPCE will follow a very lightweight model, where author identities are revealed to reviewers after submitting their initial reviews. Hence, the purpose is not to conceal author identities at all cost, but merely to provide reviewers with an unbiased first look at a submission. Author names and institutions should be omitted from submitted papers, and references to the authors’ own related work should be in the third person. No other changes are necessary, and authors will not be penalized if reviewers are able to infer their identities in implicit ways. Papers must be submitted using HotCRP: https://gpce2020.hotcrp.com/ The official publication date is the date the proceedings are made available in the ACM Digital Library. Papers must describe work not currently submitted for publication elsewhere as described by the SIGPLAN Republication Policy (http://www.sigplan.org/Resources/Policies/Republication/) --------------------------- ORGANIZATION --------------------------- - Steering Committee Chair: Ulrik Pagh Schultz (Denmark) - General Chair: Martin Erwig (USA) - Program Chair: Jeff Gray (USA) - Publicity Chair: Erwan Bousse (France) For additional information, clarification, or answers to questions please contact the program chair at gray(a)cs.ua.edu --------------------------- PROGRAM COMMITTEE --------------------------- - Juliana Alves Pereira (Brazil) - Ira Baxter (USA) - Don Batory (USA) - Sandrine Blazy (France) - Sheng Chen (USA) - Shigeru Chiba (Japan) - Thomas Degueule (France) - Robert Glück (Denmark) - Aniruddha Gokhale (USA) - Elisa Gonzalez Boix (Belgium) - Julia Lawall (France) - Geoffrey Mainland (USA) - Marjan Mernik (Slovenia) - Bruno Oliveira (Hong Kong) - Alex Potanin (New Zealand) - Suman Roychoudhury (India) - Christoph Seidl (Denmark) - Michel Steuwer (UK) - Eli Tilevich (USA) - Naoyasu Ubayashi (Japan) - Tijs van der Storm (Netherlands) - Vadim Zaytsev (Netherlands)

1 0