- Haskell-Cafe - Haskell.org

FMBC 2020 - Call for Participation
by Bruno Bernardo 07 Jul '20

07 Jul '20

[ Please distribute, apologies for multiple postings. ] ======================================================================== 2nd Workshop on Formal Methods for Blockchains (FMBC) 2020 - Call for Participation https://fmbc.gitlab.io/2020 July 20 and 21, 2020, Online, 6AM-8AM PDT Co-located with the 32nd International Conference on Computer-Aided Verification (CAV 2020) http://i-cav.org/2020/ --------------------------------------------------------- The FMBC workshop is a forum to identify theoretical and practical approaches of formal methods for Blockchain technology. Topics include, but are not limited to: * Formal models of Blockchain applications or concepts * Formal methods for consensus protocols * Formal methods for Blockchain-specific cryptographic primitives or protocols * Design and implementation of Smart Contract languages * Verification of Smart Contracts The list of lightning talks and conditionally accecpted papers is available on the FMBC 2020 website: https://fmbc.gitlab.io/2020/program.html There will be one keynote by Grigore Rosu, Professor at University of Illinois at Urbana-Champaign, USA and Founder of Runtime Verification. Registration Registration to FMBC 2020 is free but required. It is done through the CAV 2020 registration form: http://i-cav.org/2020/attending/ Please register before *July 10, 2020*.

1 0

ekg-core/RTS : bogus GC stats when running on Google Cloud Run
by Marco Zocca 04 Jul '20

04 Jul '20

Hi all, I have two services deployed on Google cloud infrastructure; Service 1 runs on Compute Engine and Service 2 on Cloud Run and I'd like to log their memory usage via the `ekg-core` library (https://hackage.haskell.org/package/ekg-core-0.1.1.7/docs/System-Metrics.ht…) (which is just a thin wrapper around GHC.Stats ). The logging bracket is basically this : mems <- newStore registerGcMetrics mems void $ concurrently io (loop mems) where loop ms = do m <- sampleAll ms ... (lookup the gauges from m and log their values) threadDelay dt loop ms I'm very puzzled by this: both rts.gc.current_bytes_used and rts.gc.max_bytes_used gauges return constant 0 in the case of Service 2 (the Cloud Run one), even though I'm using the same sampling/logging functionality and build options for both services. This is about where my knowledge ends; could this behaviour be due to the Google Cloud Run hypervisor ("gRun") implementing certain syscalls in a non-standard way (gRun syscall guide : https://gvisor.dev/docs/user_guide/compatibility/linux/amd64/) ? Thank you for any pointers to guides/manuals/computer wisdom. Details : Both are built with these options : -optl-pthread -optc-Os -threaded -rtsopts -with-rtsopts=-N -with-rtsopts=-T the only difference is that Service 2 has an additional flag -with-rtsopts=-M2G since Cloud Run services must work with 2 GB of memory at most. The container OS in both cases is Debian 10.4 ("Buster").

1 1

Is there a handy refl or refl generator for converting GADT types?
by chris done 02 Jul '20

02 Jul '20

Hi all, I have stages in my compiler that convert e.g. Global Renamed -> Global Generated, etc. where certain constructors are available in certain stages. data GlobalRef s where FromIntegerGlobal :: GlobalRef s FromDecimalGlobal :: GlobalRef s InstanceGlobal :: !InstanceName -> GlobalRef Resolved E.g. after type class resolution is done, the InstanceGlobal constructor is available. But instances can't appear in the AST at other stages. In three stages, I've had to copy/paste this code: + refl = + case name of + FromIntegerGlobal -> FromIntegerGlobal + FromDecimalGlobal -> FromDecimalGlobal Because if I just put `name` then GHC will complain that the types are different, which is correct. But a straight-forward pattern match gives GHC the proof that they can be converted. Is there a handy way already implemented that could derive either this code or this proof for me? Cheers, Chris

3 3

ICFP 2020: Second Call for Student Volunteers
by Victor Lanvin 29 Jun '20

29 Jun '20

Please don't hesitate to share this information with your students, classmates or colleagues! ICFP'20 SECOND CALL FOR STUDENT VOLUNTEERS =========================================== 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. In order to smoothly run the conference, associated workshops, and tutorials, we need student volunteers to help out on the practical aspect of the organization. All the events associated with ICFP'20 will take place **virtually** from Sun 23 - Fri 28 August 2020. Even though the event will be virtual, we will more than ever need the help of student volunteers to make sure everything runs smoothly. In return, as an ICFP 2020 Student Volunteer, you will interact closely with researchers, academics and practitioners from various disciplines and meet other students from around the world. While the exact structure of the conference is still being worked on, job assignments for student volunteers will include but will not be restriced to: 1- Assisting with technical sessions, workshops, tutorials and panels. 2- Helping to get speakers prepped and ready for broadcast. 3- Managing the various slack channels and social activities. To be considered as a Student Volunteer for ICFP, please fill in the following application form. https://forms.gle/YPsgEb4qiqnuHteB7 The permanent link to this form can be found on the official conference website. https://icfp20.sigplan.org/track/icfp-2020-student-volunteering The deadline for the second round of applications is July 19th, 2020 AoE. The notification will be on July 21st. Positive notifications given in the first round are firm and the second round is only for spots not filled by the first round. If your application was not accepted in the first round, it will automatically be included in the 2nd round.

1 0

PEP622
by Olaf Klinke 29 Jun '20

29 Jun '20

An excerpt from PEP622 [1]: > Let us start from some anecdotal evidence: isinstance() is one of the > most called functions in large scale Python code-bases (by static > call count). In particular, when analyzing some multi-million line > production code base, it was discovered that isinstance() is the > second most called builtin function (after len()). Even taking into > account builtin classes, it is still in the top ten. Most of such > calls are followed by specific attribute access. > > There are two possible conclusions that can be drawn from this > information: > > * Handling of heterogeneous data (i.e. situations where a variable > can take values of multiple types) is common in real world code. > * Python doesn't have expressive ways of destructuring object data > (i.e. separating the content of an object into multiple variables). > I just want to say a big thank you to the Haskell creators for giving us a tool to efficiently write real world code (as it is called above). [1] https://www.python.org/dev/peps/pep-0622/#rationale-and-goals

4 5

Munich Virtual Haskell Meeting, 2020-06-30 @ 19:30
by Leah Neukirchen 28 Jun '20

28 Jun '20

Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Tuesday, June 30 at 19:30. **Due to meetup limitations 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 Tuesday. 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

Second Call for Papers: Reactive and Event-Based Languages and Systems (REBLS 2020)
by Ivan Perez 26 Jun '20

26 Jun '20

SECOND 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 Camera Ready 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

[HIW'20] Second Call for Talks
by Ben Gamari 24 Jun '20

24 Jun '20

Hello everyone, Haskell Implementors Workshop is calling for talk proposals. Co-located with ICFP, HiW is an ideal place to describe a Haskell library, a Haskell extension, compiler, works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. The deadline for submissions is July 2nd 2020. Call for Talks ============== The 12th Haskell Implementors’ Workshop is to be held alongside ICFP 2020 this year. 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 2020. 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, optimization 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-hiw20.hotcrp.com/ until July 2nd (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. Logistics --------- Due to the on-going COVID-19 situation, ICFP (and, consequently, HIW) will be held remotely this year. However, the organizers are still working hard to provide for a great workshop experience. While we are sad that this year will lack the robust hallway track that is often the highlight of HIW, we believe that this remote workshop presents a unique opportunity to include more of the Haskell community in our discussion and explore new modes of communicating with our colleagues. We hope that you will join us in making this HIW as vibrant as any other. Program Committee ----------------- - Andrey Mokhov (Newcastle University) - Ben Gamari (Well-Typed LLP) - Christian Baaij (QBayLogic) - George Karachalias (Tweag I/O) - Klara Marntirosian (KU Leuven) - Matthew Pickering (Univeristy of Bristol) - Ryan G.L. Scott (Indiana University Bloomington) Best wishes, ~ Ben

1 1

[ANN] Enpuzzled - iOS/Android Haskell game
by Miriam 18 Jun '20

18 Jun '20

Hi everyone! After years of work, thousands of commits, and over 100 uploads to iTunes and Android, we are very happy to finally announce Enpuzzled, a Haskell game for iOS and Android. Enpuzzled is a brain teaser that anyone can enjoy quietly, so there is no timer and no rush: it's just you against the board. The game is suitable for all audiences and requires no permissions to run, as part of our recent movement 'Safe2Play'. iTunes: https://apps.apple.com/us/app/enpuzzled/id1460083994 Google Play: https://play.google.com/store/apps/details?id=uk.co.keera.games.enpuzzled Web page: https://enpuzzled.haskell.games Official announcement: https://keera.co.uk/2020/06/18/enpuzzled-released-for-android-and-ios/ Issue tracker: https://github.com/keera-studios/enpuzzled Support/questions: support(a)keera.co.uk Safe2Play: https://keera.co.uk/2020/06/17/safe2play-caring-for-privacy-in-an-interconn… This is our second self-published mobile Haskell game, and one more small step in a long way towards making Haskell a real possibility for game programming. You can find some technical details in the official announcement. We would like to publicly thank all beta testers, who patiently tried version after version, and all the people who supported the development in different ways. If you'd like to support the development of more Haskell games, please consider buying Enpuzzled and/or spreading the word. We currently have three more games at different stages of development. You can follow the development on our website and on social networks, where we will also post calls for early testers. Have fun, and happy Haskelling! Miriam, Keera Studios

1 0

Call for Tutorial Proposals: ICFP 2020
by Sam Tobin-Hochstadt 17 Jun '20

17 Jun '20

CALL FOR TUTORIAL, PANEL, AND DISCUSSION PROPOSALS ICFP 2020 25th ACM SIGPLAN International Conference on Functional Programming August 23 - 28, 2020 Virtual https://icfp20.sigplan.org/ The 25th ACM SIGPLAN International Conference on Functional Programming will be held virtually on August 23-28, 2020. ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. Proposals are invited for tutorials, lasting approximately 3 hours each, to be presented during ICFP and its co-located workshops and other events. These tutorials are the successor to the CUFP tutorials from previous years, but we also welcome tutorials whose primary audience is researchers rather than practitioners. Tutorials may focus either on a concrete technology or on a theoretical or mathematical tool. Ideally, tutorials will have a concrete result, such as "Learn to do X with Y" rather than "Learn language Y". This year, following the success of the #ShutDownPL event, we are also inviting proposals for panels and discussions on topics of broader interest to the PL community. Tutorials, panels, and discussions may occur before or after ICFP, co-located with the associated workshops, on August 23 or August 27-28. ---------------------------------------------------------------------- Submission details Deadline for submission: July 17th, 2020 Notification of acceptance: July 22nd, 2020 Prospective organizers of tutorials are invited to submit a completed tutorial proposal form in plain text format to the ICFP 2020 workshop co-chairs (Jennifer Hackett and Leonidas Lampropoulos), via email to icfp-workshops-2020(a)googlegroups.com by July 17th, 2020. Please note that this is a firm deadline. Organizers will be notified if their event proposal is accepted by July 22nd, 2020. The proposal form is available at: http://www.icfpconference.org/icfp2020-files/icfp20-panel-form.txt http://www.icfpconference.org/icfp2020-files/icfp20-tutorials-form.txt ---------------------------------------------------------------------- Selection committee The proposals will be evaluated by a committee comprising the following members of the ICFP 2020 organizing committee. Tutorials Co-Chair: Jennifer Hackett (University of Nottingham) Tutorials Co-Chair: Leonidas Lampropoulos (University of Maryland) General Chair: Stephanie Weirich (University of Pennsylvania) Program Chair: Adam Chlipala (MIT) ---------------------------------------------------------------------- Further information Any queries should be addressed to the tutorial co-chairs (Jennifer Hackett and Leonidas Lampropoulos), via email to icfp-workshops-2020(a)googlegroups.com

1 0

FFI ccall struct return by value on the stack?
by ☂Josh Chia (謝任中) 16 Jun '20

16 Jun '20

Suppose I have the following C code: typedef struct Foo { char* p1; /* Some data on the heap. */ size_t s1; /* Size of data. */ char* p2; /* More data on the heap. */ size_t s2; } Foo; /* Allocates and writes two pieces of data on the heap and returns them in a Foo. */ Foo makeFoo(size_t x); Based on my limited understanding of Haskell FFI according to the Haskell 2010 Language Report ( https://www.haskell.org/onlinereport/haskell2010/haskellch8.html) it is not possible to have a ccall for makeFoo() because Foo is not a marshallable foreign result type. Is my understanding correct? However, I believe I can have a ccall if I change makeFoo() to either of the following: Foo* makeFoo(size_t x); void makeFoo(Foo* out, size_t x); The first involves the C code allocating a Foo and returning a pointer to it (so now there's one more pointer for the C code to deallocate later in another function). The second involves the C code writing a Foo value to a piece of memory allocated in Haskell (possibly using Foreign.Marshall.Alloc.alloca). Both signatures work because Foo* is marshallable but are clumsier to use than the original signature. Is there just no way to return a struct by value on the stack? Is there a cleaner way than the above two? Josh

5 4

transcoding - Haskell?!
by Gregory Guthrie 14 Jun '20

14 Jun '20

I think it would choke on Haskell code! Haskell has so many language extensions and pragmas, and people use many local extensions with monads to basically create DIY DSL's - that the code becomes very dense and context specific. Facebook's TransCoder AI Converts Code From One Programming Language Into Another VentureBeat Kyle Wiggers June 9, 2020 Facebook says its TransCoder can convert code from one high-level programming language into another. The system, which Facebook researchers describe as "a neural transcompiler," uses an unsupervised learning approach to translate between languages like C++, Java, and Python. The researchers trained TransCoder on a public GitHub corpus featuring more than 2.8 million open source repositories. To evaluate its capabilities, the researchers extracted 852 parallel functions in C++, Java, and Python from the online GeeksforGeeks platform and developed a new computational accuracy metric that tests whether hypothesis functions generate the same outputs as a reference when given the same inputs. Wrote the researchers, "TransCoder can easily be generalized to any programming language, does not require any expert knowledge, and outperforms commercial solutions by a large margin." Dr. Gregory Guthrie Maharishi International University ----------------------------------------------------------------

5 10

Norvig AI book translations...
by Gregory Guthrie 13 Jun '20

13 Jun '20

I've often thought that a book and approach like the MIT AI book by Norvig ("Artificial Intelligence: A Modern Approach" - http://aima.cs.berkeley.edu/) Would be a great way to showcase Haskell and its expressive clarity. It was thus interesting to find this article " Python for Lisp Programmers" (https://norvig.com/python-lisp.html) and https://github.com/aimacode, were the book has been translated into many other languages - but not Haskell (yet?). Haskell is such a great way to teach many programming concepts and applications in a very clean manner, and some of the books used to demonstrate and showcase other languages would be quite nice to have more common course books with Haskell! In a more playful flavor; "Impractical Python Projects" - again all things that map nicely into some simple Haskell examples. ( https://nostarch.com/impracticalpythonprojects ) "Python is a programming language, but it is also fun to play with. This book recognises that." LYAH & RWH are really great - but some books with more application oriented approaches can be good starters and inroads for introductions to Haskell. Dr. Gregory Guthrie Maharishi International University ----------------------------------------------------------------

3 3

Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 202, Issue 14
by Michal J Gajda 13 Jun '20

13 Jun '20

After careful examination of the paper, I inferred that it mostly implemented simple loop translation, and worked only as long as the problem was small and easy to refine by direct translation token by token. It also had problems with preserving semantics of these simple loops. So while I am certain that Facebook AI tries to address important problems, the solution seems very far from practical application to large code bases and even attempts to translate the same language from one library to another. -- Best regards Michal On Sat, Jun 13, 2020 at 2:03 PM <haskell-cafe-request(a)haskell.org> wrote: > Send Haskell-Cafe mailing list submissions to > haskell-cafe(a)haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > or, via email, send a message with subject or body 'help' to > haskell-cafe-request(a)haskell.org > > You can reach the person managing the list at > haskell-cafe-owner(a)haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Haskell-Cafe digest..." > Today's Topics: > > 1. transcoding - Haskell?! (Gregory Guthrie) > 2. Re: transcoding - Haskell?! (Branimir Maksimovic) > 3. Re: transcoding - Haskell?! (MigMit) > 4. Re: transcoding - Haskell?! (Branimir Maksimovic) > 5. Re: transcoding - Haskell?! (Henning Thielemann) > > > > ---------- Forwarded message ---------- > From: Gregory Guthrie <guthrie(a)miu.edu> > To: "haskell-cafe(a)haskell.org" <haskell-cafe(a)haskell.org> > Cc: > Bcc: > Date: Fri, 12 Jun 2020 17:33:47 +0000 > Subject: [Haskell-cafe] transcoding - Haskell?! > > I think it would choke on Haskell code! > > Haskell has so many language extensions and pragmas, and people use many > local extensions with monads to basically create DIY DSL’s – that the code > becomes very dense and context specific. > > > > *Facebook's TransCoder AI Converts Code From One Programming Language Into > Another* > *VentureBeat* > > * Kyle Wiggers June 9, 2020* > > Facebook says its TransCoder can convert code from one high-level > programming language into another. The system, which Facebook researchers > describe as “a neural transcompiler,” uses an unsupervised learning > approach to translate between languages like C++, Java, and Python. The > researchers trained TransCoder on a public GitHub corpus featuring more > than 2.8 million open source repositories. To evaluate its capabilities, > the researchers extracted 852 parallel functions in C++, Java, and Python > from the online GeeksforGeeks platform and developed a new computational > accuracy metric that tests whether hypothesis functions generate the same > outputs as a reference when given the same inputs. Wrote the researchers, > “TransCoder can easily be generalized to any programming language, does not > require any expert knowledge, and outperforms commercial solutions by a > large margin.” > > > > > > > > Dr. Gregory Guthrie > > Maharishi International University > > ---------------------------------------------------------------- > > > > > > ---------- Forwarded message ---------- > From: Branimir Maksimovic <branimir.maksimovic(a)gmail.com> > To: haskell-cafe(a)haskell.org > Cc: > Bcc: > Date: Fri, 12 Jun 2020 19:44:01 +0200 > Subject: Re: [Haskell-cafe] transcoding - Haskell?! > > It would choke on assembler as well. Digital computer hard AI is > impossible, because there is no > > algorithm for making algorithms. Mathematicaly impossible... > > Greets, Branimir. > > > On 6/12/20 7:33 PM, Gregory Guthrie wrote: > > I think it would choke on Haskell code! > > Haskell has so many language extensions and pragmas, and people use many > local extensions with monads to basically create DIY DSL’s – that the code > becomes very dense and context specific. > > > > *Facebook's TransCoder AI Converts Code From One Programming Language Into > Another* > *VentureBeat* > > * Kyle Wiggers June 9, 2020* > > Facebook says its TransCoder can convert code from one high-level > programming language into another. The system, which Facebook researchers > describe as “a neural transcompiler,” uses an unsupervised learning > approach to translate between languages like C++, Java, and Python. The > researchers trained TransCoder on a public GitHub corpus featuring more > than 2.8 million open source repositories. To evaluate its capabilities, > the researchers extracted 852 parallel functions in C++, Java, and Python > from the online GeeksforGeeks platform and developed a new computational > accuracy metric that tests whether hypothesis functions generate the same > outputs as a reference when given the same inputs. Wrote the researchers, > “TransCoder can easily be generalized to any programming language, does not > require any expert knowledge, and outperforms commercial solutions by a > large margin.” > > > > > > > > Dr. Gregory Guthrie > > Maharishi International University > > ---------------------------------------------------------------- > > > > _______________________________________________ > 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. > > > > > ---------- Forwarded message ---------- > From: MigMit <migmit(a)gmail.com> > To: Branimir Maksimovic <branimir.maksimovic(a)gmail.com> > Cc: haskell-cafe <haskell-cafe(a)haskell.org> > Bcc: > Date: Fri, 12 Jun 2020 20:14:18 +0200 > Subject: Re: [Haskell-cafe] transcoding - Haskell?! > I wonder if this would be true: > https://www.theolognion.com/circular-ts-js-ts-js-transpiling-yields-impress… > > > On 12 Jun 2020, at 19:44, Branimir Maksimovic < > branimir.maksimovic(a)gmail.com> wrote: > > > > It would choke on assembler as well. Digital computer hard AI is > impossible, because there is no > > > > algorithm for making algorithms. Mathematicaly impossible... > > > > Greets, Branimir. > > > > > > > > On 6/12/20 7:33 PM, Gregory Guthrie wrote: > >> I think it would choke on Haskell code! > >> Haskell has so many language extensions and pragmas, and people use > many local extensions with monads to basically create DIY DSL’s – that the > code becomes very dense and context specific. > >> > >> Facebook's TransCoder AI Converts Code From One Programming Language > Into Another > >> VentureBeat > >> Kyle Wiggers > >> June 9, 2020 > >> > >> Facebook says its TransCoder can convert code from one high-level > programming language into another. The system, which Facebook researchers > describe as “a neural transcompiler,” uses an unsupervised learning > approach to translate between languages like C++, Java, and Python. The > researchers trained TransCoder on a public GitHub corpus featuring more > than 2.8 million open source repositories. To evaluate its capabilities, > the researchers extracted 852 parallel functions in C++, Java, and Python > from the online GeeksforGeeks platform and developed a new computational > accuracy metric that tests whether hypothesis functions generate the same > outputs as a reference when given the same inputs. Wrote the researchers, > “TransCoder can easily be generalized to any programming language, does not > require any expert knowledge, and outperforms commercial solutions by a > large margin.” > >> > >> > >> > >> > >> Dr. Gregory Guthrie > >> Maharishi International University > >> ---------------------------------------------------------------- > >> > >> > >> > >> _______________________________________________ > >> 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. > >> > > _______________________________________________ > > 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. > > > > > > ---------- Forwarded message ---------- > From: Branimir Maksimovic <branimir.maksimovic(a)gmail.com> > To: MigMit <migmit(a)gmail.com> > Cc: haskell-cafe <haskell-cafe(a)haskell.org> > Bcc: > Date: Fri, 12 Jun 2020 20:25:58 +0200 > Subject: Re: [Haskell-cafe] transcoding - Haskell?! > As long as there is math behind that it could work. There is no > algorithm for creative thinking. Same way that if you put it on rng 1000 > monkeys will sooner or later create Shakespeare :P > > Greets, Branimir. > > On 6/12/20 8:14 PM, MigMit wrote: > > I wonder if this would be true: > https://www.theolognion.com/circular-ts-js-ts-js-transpiling-yields-impress… > > > >> On 12 Jun 2020, at 19:44, Branimir Maksimovic < > branimir.maksimovic(a)gmail.com> wrote: > >> > >> It would choke on assembler as well. Digital computer hard AI is > impossible, because there is no > >> > >> algorithm for making algorithms. Mathematicaly impossible... > >> > >> Greets, Branimir. > >> > >> > >> > >> On 6/12/20 7:33 PM, Gregory Guthrie wrote: > >>> I think it would choke on Haskell code! > >>> Haskell has so many language extensions and pragmas, and people use > many local extensions with monads to basically create DIY DSL’s – that the > code becomes very dense and context specific. > >>> > >>> Facebook's TransCoder AI Converts Code From One Programming Language > Into Another > >>> VentureBeat > >>> Kyle Wiggers > >>> June 9, 2020 > >>> > >>> Facebook says its TransCoder can convert code from one high-level > programming language into another. The system, which Facebook researchers > describe as “a neural transcompiler,” uses an unsupervised learning > approach to translate between languages like C++, Java, and Python. The > researchers trained TransCoder on a public GitHub corpus featuring more > than 2.8 million open source repositories. To evaluate its capabilities, > the researchers extracted 852 parallel functions in C++, Java, and Python > from the online GeeksforGeeks platform and developed a new computational > accuracy metric that tests whether hypothesis functions generate the same > outputs as a reference when given the same inputs. Wrote the researchers, > “TransCoder can easily be generalized to any programming language, does not > require any expert knowledge, and outperforms commercial solutions by a > large margin.” > >>> > >>> > >>> > >>> > >>> Dr. Gregory Guthrie > >>> Maharishi International University > >>> ---------------------------------------------------------------- > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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. > >>> > >> _______________________________________________ > >> 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. > > > > > ---------- Forwarded message ---------- > From: Henning Thielemann <lemming(a)henning-thielemann.de> > To: Gregory Guthrie <guthrie(a)miu.edu> > Cc: haskell-cafe(a)haskell.org > Bcc: > Date: Fri, 12 Jun 2020 21:51:30 +0200 (CEST) > Subject: Re: [Haskell-cafe] transcoding - Haskell?! > > On Fri, 12 Jun 2020, Gregory Guthrie wrote: > > > I think it would choke on Haskell code! > > > > Haskell has so many language extensions and pragmas, and people use many > > local extensions with monads to basically create DIY DSL’s – that the > > code becomes very dense and context specific. > > It could have its use to convert legacy code in legacy languages to shiny > new Haskell code. :-)_______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -- Pozdrawiam Michał

1 0

Re: [Haskell-cafe] Future of lucid
by chris done 11 Jun '20

11 Jun '20

Hi Gabriel, I enabled the issue tracker earlier today for those reasons. Unfortunately, GitHub doesn't distinguish between "mailing list where chat can occur" and "tasks the devs plan to put time and energy into", it's all dumped into one pot. I consider this a shortcoming of GitHub. It actually distorts the meaning of "to maintain" from "keeping the software correct and working" to "responding to and acknowledging any and all commentary by anyone at any time for any duration, teaching fellow developers about how to use Git, GitHub, among other mentorship tasks" the temporary or prolonged neglect of which is deemed to be not putting on a good show, or in your own words, "not maintaining it". The more I reflect on it, the more I see why many project maintainers burn out on GitHub. I will continue using lucid and patching it to move with the times as GHC's type system moves along and HTML 5 elements/attributes are added, and merge pull requests related to these stated goals, for the foreseeable future, but I plan to do no more than that. If that's not good enough for Dhall, then there are plenty of other options.[1] Cheers, Chris [1]: https://www.reddit.com/r/haskell/comments/h05uwn/experience_report_choosing… On Wed, Jun 10, 2020, at 4:26 PM, Gabriel Gonzalez wrote: > Would it be possible to leave the issue tracker on but just disable your own email notifications for the repository if you do not plan to maintain it? The two main reasons I suggest this are: > > * We would like a way to be able to petition Oleg for changes (or whoever is the maintainer at the time) > * We would like to know if other people share the same problem we do (or vice versa, educate other users of problems we are having and potential workarounds) > >> On Jun 10, 2020, at 6:23 AM, chris done <haskell-cafe(a)chrisdone.com> wrote: >> >> Hi Simon, >> >> I am still maintaining and actively using the package. Architecture-wise, nothing substantial has changed in the 6 years since its release. Just small additions. This package pretty much maintains itself. PRs come and go. >> >> In fact, any kind of overhauls or user-facing design changes at this stage would cause disruption and I would encourage that to be achieved in a separate package with a new name. In review, I'm very happy with Lucid's design and plan to maintain it long-term into the future for as long as HTML is relevant. >> >> However, I am providing no Q&A or "tech support". Having an issue tracker would say otherwise. >> >> Oleg is also a maintainer. >> >> Cheers, >> >> Chris >> >> On Tue, Jun 9, 2020, at 5:27 AM, Simon Jakobi wrote: >>> Hi! >>> >>> I recently noticed that the issue tracker for the lucid package at >>> >>> https://github.com/chrisdone/lucid >>> >>> has been disabled. Does this have any implications for the future >>> maintenance of the package? Is anyone still committed to maintaining >>> the package? >>> >>> (I've CC'd Oleg who made the most recent commit to the repo.) >>> >>> The context for my question is that we'd like to use lucid for the >>> documentation generator that is being developed as a part of >>> this year's GSoC. >>> >>> Thanks! >>> Simon

5 7

Re: [Haskell-cafe] Looking for a paper [Dijkstra-Dot]
by Anthony Clayden 11 Jun '20

11 Jun '20

(Golly, this went meta rather quickly.) >> Am 08.06.20 um 16:07 schrieb amindfv at gmail.com <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>: >>* Haskell's reputation as a welcoming community is on shakier ground *>>* than it was a few years ago, and phrases like "despite your endless *>>* ranting" work against the collegial atmosphere we're proud of.* *Thank you Tom for reminding us these messages are visible to public/posterity.* *I woke up this thread because I was worried what posterity would make of last year's discussion -- which seemed to accept the 'thought-dialogue' uncritically; certainly no indication it was intended merely as a bit of humour. (I remain unconvinced that it was.) * > Ben Franksen wrote: > To put this in perspective, here are a few citations from what I have > called "endless ranting": Let's start near the beginning of the ewd.pdf, please (capitalisation and shrieks in the original) "Haskeller: WHOA! Hold it! You are misappropriating our religion!" It was Ben who described some of my language as "ranting". How would you describe Haskeller's? I'm sure we're all aware of Why Functional Programming Matters, without going so far as making a religion of it nor thinking other paradigms don't matter. The imperative paradigm is not "antiquated" (contra what Haskeller says): Turing machines and Lambda calculus hit the world in publications in the same year. And despite Ben's finely-tuned sense of humour, you seem not so finely-tuned to the Use-mention distinction en.wikipedia.org/wiki/Use-mention_distinction. I was pointing to (i.e. mentioning) the language in that pdf as not being representative of the Haskell community I know; I was not myself using such emotionally-loaded language. I'm happy to defend my observations as matters of factual error or misrepresentation; I've presented that evidence up-thread, but briefly: >>* ... misapplying ... in a rather badly-informed way.* *Fact: EWD1300 is considering mathematical notation, not programming languages. As regards using semicolon for function composition, at no point does EWD1300 consider the clash with semicolon in ALGOL-derived languages.* *Fact: Haskeller's responses top of page 2 re operator sections are incorrect, see Haskell Report.* *Fact: Haskeller's answer re `length $ []` is wrong: try it in GHC.* >>* ... it doesn't seem to know Haskellers very well; nor Dijkstra's *>>* well-known support for Haskell in education.* *Fact: See above re over-emotional opening remarks; that "Jumping", "Beaming", "Irritated", "Exasperated", "Warily" emotionality is not how Haskellers behave in my experience.* *Fact re Haskell in Education: Dijkstra's 'To the Members of the Budget Council', in his UTexas archive.* >* ... can't even spell his first name right... * *Fact: docos on that the-magus site give "Edsgar"; it's not difficult to spell someone's name right.* >* ... it's a couple of dudes shooting the breeze.* *Fact: Ben said in an earlier message, of the authors of the pdf "obviously exaggerated ... artist's freedom ... rhetoric a bit over the top ...". In comparison 'shooting the breeze' from me seems quite mild; not "ranting".* >* ...To put it bluntly: the authors are blundering.* >* ... a bogus problem; direct consequence of the authors not *>* understanding EWD1300. * *That's the conclusion I reached after analysing their mistakes. I stand by it; see the facts I pointed out in that earlier message.* > Do you regard this as "welcoming" language? If not, where was your > concerned reply when they hit the list? (Presumably that's a q to Tom.) > IMO the occasional ranting doesn't hurt anybody as long as it is > addressed not to people but to technical shortcomings. However, the > above citations are clearly ad-hominem attacks. I disagree they're attacks; I'm pointing out technical shortcomings and mis-representations. If it's ad-anybody, the people are the faux-Haskeller and faux-EWD. > Or is your point that I directly addressed the author of the above > lines, rather than attacking some third party? I had already emailed the-magus making these same points. And of course the site doesn't accept (publicly-visible) comments. I doubt I'll get a reply, since the site seems to have died several years ago. Then where do I address the authors? I thought it appropriate I reawaken the thread here from last year. AntC

2 1

Re: [Haskell-cafe] Looking for a paper [Dijkstra-Dot]
by Olaf Klinke 10 Jun '20

10 Jun '20

Now I can't tell whether you're teasing to keep this thread alive. If it is humour, it is lost on me. > Report section 6.4.1 Numeric Literals. "An integer literal represents > the application of the function `fromInteger` to the appropriate > value > of type `Integer`." > > OK. How do we write in Haskell that "appropriate value"? > To me that part of the report is obviously about compile-time code generation. The sentence itself is not recursive, it is "literal" versus "value". The two concepts live in different domains. Why do you think its meaning may be recursive? I imagine that when the compiler sees the literal 7, it de-sugars to (fromInteger (mkInteger ...)) where the inner expression is code from GHC.Integer that does not invoke fromInteger again. When the entire expression is to be of type Integer, then the fromInteger dictionary lookup replaces that by id. So the entire expression can be optimized to be whatever core expression generates the Integer seven, most likely S# 7#. Olaf

1 0

Future of lucid
by Simon Jakobi 10 Jun '20

10 Jun '20

Hi! I recently noticed that the issue tracker for the lucid package at https://github.com/chrisdone/lucid has been disabled. Does this have any implications for the future maintenance of the package? Is anyone still committed to maintaining the package? (I've CC'd Oleg who made the most recent commit to the repo.) The context for my question is that we'd like to use lucid for the Dhall documentation generator that is being developed as a part of this year's GSoC. Thanks! Simon

2 4

Re: [Haskell-cafe] Looking for a paper [Dijkstra-Dot]
by Anthony Clayden 10 Jun '20

10 Jun '20

> Richard O'Keefe wrote: > ... More seriously, in "f x", there is an explicit > operator already. It's "f". The space is needed for lexical > reasons only. If you say no, functions are not operators -- > though in Haskell infix operators are functions -- but > application is the operator, so you should write "f @ x <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>" (usual > FP notation) or "f.x" (Dijkstra), then although it isn't > technically true, I've always felt that there is an infinite > regress lurking in the background: > if x + y means (+) x y > which really stands for (+)@x @ <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe> y > then shouldn't that in turn stand for (@)((@)(+)x)y > and what should _that_ stand for? Heh, heh there's another corner where Haskell semantics appears to give an infinite regress; and we have to suppose there's some internal magic that can't be expressed in the surface language: Report section 6.4.1 Numeric Literals. "An integer literal represents the application of the function `fromInteger` to the appropriate value of type `Integer`." OK. How do we write in Haskell that "appropriate value"? We could write `7 :: Integer` but that's shorthand for `(fromInteger #7#) :: Integer`, in which I've used `#7#` to denote the "appropriate value" doo-hickey. There's no way in Haskell to write a literal that's type `Integer`, except by invoking `fromInteger`. `(fromInteger (7 :: Integer)) :: Integer` ? Both the explicit and implicit `fromInteger` in there are no-ops. AntC

1 0

Library maintainers: Include your library in CodeWorld web-based Haskell environment
by Chris Smith 10 Jun '20

10 Jun '20

Hello, I'm the maintainer of CodeWorld. In addition to the K-12 education uses, CodeWorld provides a web-based programming environment at http://code.world/haskell to write short snippets of Haskell and share it easily with others. I am trying to ensure that as many interesting Haskell libraries as possible are available on the platform. If you are interested in ensuring that a library is included, whether you're the maintainer or just am interested user, please take a look at the package list at https://github.com/google/codeworld/blob/master/codeworld-available-pkgs/co… Packages that fit here are: 1. No I/O, except for stdin/out/err. Since CodeWorld runs code in a web browser, there is no filesystem, for example. 2. Do not rely on native libraries, or have dependencies that do. This all depends on the library building with GHCJS. 3. Do not require use of Template Haskell by clients. It's okay if your package needs template Haskell to build, but people using your library via CodeWorld cannot yet use TH themselves. If you have a library you'd like to see included that's not in that list, please let me know, either with just an email or with a pull request at the GitHub link above. Thanks, Chris

3 6

Generating PDF from HTML with Pandoc
by Geraldus 09 Jun '20

09 Jun '20

Hi dear Cafe! I'm trying to achieve trivial task to generate PDF from HTML template using Pandoc. So far I've tried `wkhtmltopdf` and `pdflatex` creators, both with no luck. I want to put few words about `pdflatex` and `xelatex` creators first, for someone who will struggle with same task in future, it's quite hard to find code examples on the web. Initially I wasn't able to render document with `pdflatex` creator. I would like to mention that `pdflatex` required a lot of LaTeX stuff to be installed, especially font packages. Also I've spent several hours to make rendering happen because I haven't specified template in `WriterOptions`. `pdflatex` do not capable to handle Cyrillic Unicode characters, and finally I figured out I have to use `xelatex` creator. Also I've found and used default template: > pandoc <- readHtml def (toStrict $ renderHtml html) > tpl' <- getDefaultTemplate "latex" > makePDF "xelatex" [] writeLaTeX (def {writerTemplate = Just tpl'}) pandoc But in this case I got white space instead of Cyrillic chars in resulting PDF and a bunch of warnings about missing chars in default font in console. I assume the font itself is specified in template. I've looked into default template and it's huge. I guess I can prepare more simple template for my own needs but it will take a lot of time to get familiar with LaTeX document syntax. I've tried `wkhtmltopdf`, which seems to be lightweight and easy solution. It seemed to work well except encoding issues: resulting PDF contains Cyrillic which rendered incorrectly. I've tried to pass `["encoding utf-8"]` as arguments in `makePDF` call, but this results in runtime error: > --margin-bottom specified in incorrect location Googling around this issue led me to glue that when I pass encoding argument to `wkhtmltopdf` it breaks expected arguments order in command which Pandoc generates. This is likely could be easily fixed, but Pandoc have a lot of opened issues on Github and also it requires some digging into `wkhtmltopdf` command line arguments syntax. I've looked into Pandoc sources and it seems possible to provide simple patch, but I need a guidance. According to `wkhtmltopdf` it distinguish global args, page args, cover args, table of contents args. `encoding` argument is page level argument, but Pandoc put extra args specified in `makePDF` after default page arguments (`pdfargs` in following code sample): > let args = mathArgs ++ concatMap toArgs > [("page-size", getField "papersize" meta') > ,("title", getField "title" meta') > ,("margin-bottom", Just $ fromMaybe "1.2in" > (getField "margin-bottom" meta')) > ,("margin-top", Just $ fromMaybe "1.25in" > (getField "margin-top" meta')) > ,("margin-right", Just $ fromMaybe "1.25in" > (getField "margin-right" meta')) > ,("margin-left", Just $ fromMaybe "1.25in" > (getField "margin-left" meta')) > ,("footer-html", getField "footer-html" meta') > ,("header-html", getField "header-html" meta') > ] ++ pdfargs Likely this breaks everything. The quickest and dirtiest workaround I see is to check each argument, and if it is a page level argument put it for each page object. Another solution may be to specify encoding for Pandoc document some other way, but I can't guess how to do that yet. Maybe someone have already faced similar task and knows easier way to render HTML to PDF with Haskell. I will very grateful for any help, advice or other glues how to achieve my goal. Arthur.

4 4

Re: [Haskell-cafe] Looking for a paper [Dijkstra-Dot]
by Anthony Clayden 09 Jun '20

09 Jun '20

> Richard O'Keefe wrote: > This is one of the notational issues where I venture to disagree > with the Master. It's on a par with arguing that a number like > 1234 would be easier to read as 1`2`3`4 where the semantics of > x`y is x*10+y. Thanks Richard, and more to the point/dot: If dot means function application then `3.14` must be `3` applied to `14`. Or perhaps the Master expects Floats to be written European-style with commas? Good luck with that in Haskell. Let's also use Euro-style space as thousands separator! Or perhaps Dijkstra as more mathematician doesn't dirty his hands with Floats. Meta: all the above is tongue-in-cheek. AntC

1 0

Re: [Haskell-cafe] Looking for a paper [Dijkstra-Dot]
by Anthony Clayden 08 Jun '20

08 Jun '20

>> On 6/5/20 7:05 AM, Anthony Clayden wrote: ... >>* Also it doesn't seem to know Haskellers very well; nor Dijkstra's *>>* well-known support for Haskell in education. *>> >>* There's other bits and pieces of 'Publications' on that the-magus site; *>>* including spoofs of Dijkstra which can't even spell his first name *>>* right. I rather suspect the ewd.pdf is a spoof that didn't turn out very *>>* funny. So altogether it's a couple of dudes shooting the breeze. * > These all seem pretty irrelevant to the point being made, which I think > has merit. (See my prev post about its lack of merit.) No Haskeller I've ever come across would accuse Dijkstra of "stick[ing] to the antiquated imperative paradigm". Dijkstra advocated teaching Haskell as an antidote to imperativism. EWD1300 is advocating for his own 'notational conventions', chiefly for writing math and formalising proofs. I don't see anything very specific to programming languages; certainly nothing specific to any paradigm. The pdf (words imputed to 'Haskeller') doesn't understand 'first-class': The term dates back to Strachey 1967; it's to do with semantics of names; what in a FP context we'd call 'referential transparency'. It has nothing to do with syntax. Column 2 of page 1 is bogus. Even if 'Haskeller' didn't know that CompSci archaeology, they'd certainly know the ($) operator. Whether or not it's the most important operator, there _is_ an operator and it is first-class. 'Haskeller' gets several answers wrong at the top of p2; finally gets to $ and gets that wrong too: EWD's question re `length $ [] = 0` is not a way to define `length`. Any Haskell beginner could stick that into an actual Haskell compiler and see why. Towards the bottom of p2 EWD admits "I do not know your Haskell very well ...". I'd say this faux-Haskeller knows Haskell less well than faux-EWD. Just before that admission is another piece of bogus notation for operator sections of `x * y`. None of that appears in EWD1300. > This is all just a language design curiosity to me, though, > and I'm not looking to start a new religious war until some of the > present ones are resolved. Well, don't look for pointers to language design from the couple of jokers portrayed in that pdf. I find it actually insulting to the good sense the real Dijkstra always showed; and insulting to Haskellers -- what's with all this gratuitous imputing of emotion? What's with just getting Haskell wrong? It's easy to check those claims; it's easy to get the (alleged) 'thought' peer-reviewed from the Haskell community. AntC

6 7

Reminder: ZuriHac is happening (remotely) this weekend be great fun!
by Jasper Van der Jeugt 08 Jun '20

08 Jun '20

Hi everybody! This is a reminder that not only will ZuriHac be happening this year, but because it will be remote, the number of attendees has virtually no upper limit. We're quite excited (and a little bit nervous) to see how a remote event will play out. We will for sure lose a little bit of the magic feeling of hacking on projects together, however we hope that getting together online will still be a great experience. Another benefit is that people can join from all over the world, and that the event will generate a lot fewer CO2 emissions this year, so we can all feel good about ourselves! A brief summary of what will be there - Talks by Alexis King, Rob Rix, Gabriel Gonzalez, Philip Wadler and Simon Meier & Ognjen Marić will be live-streamed on our Youtube channel: <https://www.youtube.com/channel/UC2zfPMH_srjxUN5EYrfIhCw>. - Well-Typed will teach two advanced sessions, one about Datatype-Generic Programming and one about InfoSec and Haskell. - Julie Moronuki will teach a beginner track. - There is a GHC track with talks by Richard Eisenberg, Divesh Otwani, Facundo Dominguez and Nicolas Frisby. - Of course, lots of Haskell hacking and socialing! You can find all information & register on our website: <https://zfoh.ch/zurihac2020> Warm regards Jasper Van der Jeugt

1 0

First call for draft papers for IFL 2020 (Implementation and Application of Functional Languages)
by Jurriaan Hage 08 Jun '20

08 Jun '20

Hello, Please, find below the final call for draft papers 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 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. 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 specialisation - run-time code generation - partial evaluation - (abstract) interpretation - meta-programming - 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 ### Post-symposium peer-review Following IFL tradition, IFL 2020 will use a post-symposium review process to produce the formal proceedings. Before the symposium authors submit draft papers. These draft papers will be screened by the program chair to make sure that they are within the scope of IFL. The draft papers will be made available to all participants at the symposium. Each draft paper is presented by one of the authors at the symposium. After the symposium every presenter is invited to submit a full paper, incorporating feedback from discussions at the symposium. Work submitted to IFL may not be simultaneously submitted to other venues; submissions must adhere to ACM SIGPLAN's republication policy. 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 for the formal proceedings. We plan to publish these proceedings in the International Conference Proceedings Series of the ACM Digital Library, as in previous years. ### Important dates Submission deadline of draft papers: 17 August 2020 Notification of acceptance for presentation: 19 August 2020 Registration deadline: 31 August 2020 IFL Symposium: 2-4 September 2020 Submission of papers for proceedings: 7 December 2020 Notification of acceptance: 3 February 2021 Camera-ready version: 15 March 2021 ### 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 ### Peter Landin Prize The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honoured 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. ### Organisation IFL 2020 Chair: Olaf Chitil, University of Kent, UK IFL Publicity chair: Jurriaan Hage, Utrecht University, The Netherlands ### Virtual symposium Because of the Covid-19 pandemic, this year IFL 2020 will be an online event, consisting of paper presentations, discussions and virtual social gatherings. Registered participants can take part from anywhere in the world. ### Acknowledgments This call-for-papers is an adaptation and evolution of content from previous instances of IFL. We are grateful to prior organisers for their work, which is reused here.

1 0

Re: [Haskell-cafe] Looking for a paper [Dijkstra-Dot]
by Anthony Clayden 08 Jun '20

08 Jun '20

> Ben Franksen wrote: >>* Well, don't look for pointers to language design from the couple of* >>* jokers portrayed in that pdf.* >> >>* I find it actually insulting to the good sense the real Dijkstra* >>* always showed; and insulting to Haskellers ...* > I really don't get why you're so upset about this harmless opinionated > piece that, in a humorous and obviously exaggerated way, It's not apparent to me this is humour, not even intended as humour. Notoriously, it's very difficult to get across sarcasm/irony on the interwebs. The tongue-in-cheek is not apparent to one of the authors, who has actually implemented these ideas blog.languager.org/2014/09/pugofer.html and it seems inflicted them on undergraduates. Including "8. layout is the only way to denote nesting ...". While they were at it, why not introduce sugar for function definition: > length . [] = 0 would be easy to desugar as an equation defining `length`. It's not apparent from the original thread May 2019 this is all a big hoot. If it's humour, who's the butt of the joke? A caricature of a Haskell newbie who doesn't understand Haskell, and can only regurgitate FP ideals as cheap dogma, played like a trout until "Exasperated". This is cruel sport, not Socratic method. Not humorous. > applies some of Dijkstra's ideas about programming language syntax ... It's not apparent to me that EWD1300 is about programming languages; the piece addresses "polite mathematics", name-checks Whitehead, Leibniz, Tarski -- who are not well-known for their work on programming languages. > Putting these words into Dijkstra's mouth is just an artist's freedom, If it's intended as art, the least they could do is put their name to it. > Despite your endless ranting the authors quite obviously do understand > EWD1300. That's not apparent to me either. > I also don't see how this has anything to do with Dijkstra promoting > Haskell for teaching. I'm not expecting the real Dijkstra would be uncritical of Haskell. I do expect that since Dijkstra saw Haskell's value for teaching, he would respect the (always difficult) design/syntax choices in the language. It's the faux-EWD's snide tripping-up of Haskeller that is uncharacteristic of Dijkstra. Also criticising Haskell's use of semicolon, which comes from ALGOL, as the real Dijkstra would be well aware. Also criticising allowing multiple constructs to express the same algorithm/semantics -- ALGOL also has plenty of that, and by design. And cheap shots about Haskell not supporting "assignments, pointers, gotos ..." -- we all know Dijkstra considers them harmful. AntC

1 0

Re: [Haskell-cafe] Generalization of types during inference
by Olaf Klinke 08 Jun '20

08 Jun '20

> f 0 x = 0 > f 1 x = f 0 () > f n x = f (n-1) 'a' That's very interesting, I learned something new about GHC today. I used to believe that my Haskell compiler always type checks declarations on its own, and after that unifies its result with the type declaration that I provide. Polymorphic recursion yields a case where the compiler's inference procedure is evidently not independent of my provided type declaration. Can the above be abused to compile programs containing false type declarations? (It seems the answer is no, but maybe I lack the fantasy.) Thanks, Olaf

3 2

Re: [Haskell-cafe] Looking for a paper [Dijkstra-Dot]
by Anthony Clayden 08 Jun '20

08 Jun '20

Hi Michael, I apologise if I'm being dumb, but that ewd.pdf is not a 'publication' and is not by Dijkstra, right? It's taking some of the ideas from Dijkstra's EWD1300, but misapplying them to Haskell in a rather badly-informed way. After all, Haskell already has a 'Application Operator' spelled ($), which is perfectly first-class and with which you can do the equational reasoning (with lambdas) that the doco is talking about. Also it doesn't seem to know Haskellers very well; nor Dijkstra's well-known support for Haskell in education. There's other bits and pieces of 'Publications' on that the-magus site; including spoofs of Dijkstra which can't even spell his first name right. I rather suspect the ewd.pdf is a spoof that didn't turn out very funny. So altogether it's a couple of dudes shooting the breeze. AntC > On 4/9/19 11:09 AM, Michael Orlitzky wrote: > *>> On 4/9/19 10:41 AM, jaro.reinders at gmail.com <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe> wrote: *>>* I found it: https://www.cs.utexas.edu/~EWD/transcriptions/EWD13xx/EWD1300.html <https://www.cs.utexas.edu/~EWD/transcriptions/EWD13xx/EWD1300.html> *>>> >> * Thank you, this is obviously also relevant, but it's not the one I'm * >> * remembering. The notation is the same, though, so this explains what I'm * >> * looking for (and is also an interesting read). * > After the Dijkstra hint, I was able to track it down: > http://www.the-magus.in/Publications/ewd.pdf

3 2

ANN: hledger 1.18
by Simon Michael 07 Jun '20

07 Jun '20

I'm pleased to announce hledger 1.18. hledger is a robust, cross-platform, plain text accounting tool, with command-line, terminal and web UIs. It is a modern and largely compatible reimplementation of Ledger CLI with many improvements. You can use it to track time, money, investments, cryptocurrencies, inventory and more. See: http://hledger.org http://plaintextaccounting.org HIGHLIGHTS: Fixed JSON output; market prices inferred from transactions; more Ledger file compatibility; more flexible journal entries from CSV; misc. fixes and improvements. See all changes at https://hledger.org/release-notes . Thanks to release contributors Stephen Morgan, Dmitry Astapov, Henning Thielemann, Andriy Mykhaylyk, Pavan Rikhi, and Vladimir Sorokin. GETTING STARTED: Many install methods are described at http://hledger.org/download. Here are three ways to build from source: stack update; stack install --resolver=lts hledger-lib-1.18 hledger-1.18 hledger-ui-1.18 hledger-web-1.18 --silent or: cabal v2-update; cabal v2-install hledger-1.18 hledger-web-1.18 hledger-ui-1.18 or: curl -sO https://raw.githubusercontent.com/simonmichael/hledger/master/hledger-insta… less hledger-install.sh bash hledger-install.sh While building, peruse https://hledger.org/start For help, see http://hledger.org#help-feedback and join us on Freenode (#hledger, http://irc.hledger.org) or via Matrix (#freenode_#hledger:matrix.org, http://riot.hledger.org) New and old users, contributors, sponsors, and all feedback are most welcome! Best, -Simon

1 0

Generalization of types during inference
by chris done 07 Jun '20

07 Jun '20

I'm writing a type checker with type classes and for some reason thought that the below program should be inferred and generalized automatically. I wasn't sure whether or not GHC would actually accept this or not, so I had to test. For both Hugs and GHC, a recursive definition's type is not generalized by the inferer. You need a type signature. See below. I checked with Hugs just in case there was a generalization limit in GHC due to its more exotic capabilities (like how let generalization is disabled by type families). I wonder: is it in general impossible or super hard to infer the most general type for all cases like this without a type signature? Or is it just considered a rare case that we don't care about? Perhaps it has subtler downsides? It any case, I'm happy to just copy GHC and Hugs as it makes my life easier to just require an explicit signature in this case. Cheers -- ERROR "Q.hs":4 - Type error in application -- *** Expression : f (n - 1) 'a' -- *** Term : 'a' -- *** Type : Char -- *** Does not match : () -- • Couldn't match expected type ‘()’ with actual type ‘Char’ -- • In the second argument of ‘f’, namely ‘'a'’ -- In the expression: f (n - 1) 'a' -- f :: Int -> a -> Int f 0 x = 0 f 1 x = f 0 () f n x = f (n-1) 'a'

2 2

Re: [Haskell-cafe] Looking for a paper [Dijkstra-Dot]
by Anthony Clayden 07 Jun '20

07 Jun '20

>> On 6/5/20 7:05 AM, Anthony Clayden wrote: >>* Hi Michael, I apologise if I'm being dumb, but that ewd.pdf is not a* >>* 'publication' and is not by Dijkstra, right?* > Sure. >> *It's taking some of the ideas from Dijkstra's EWD1300, but misapplying* >>* them to Haskell in a rather badly-informed way.* > I wouldn't say so, for reasons explained below. An undated pdf without even the authors names, but using a respected author's name seems dodgy to me. It's not "with E.W.Dijkstra" at all, indeed I'd say it's "against" him. I think what they impute to EWD is wrong in fact and wrong in attitude, for reasons explained below. >>* After all, Haskell already has a 'Application Operator' spelled ($),* >>* which is perfectly first-class and with which you can do the equational* >>* reasoning (with lambdas) that the doco is talking about.* > The thread that I was recalling (Language complexity & beginners) can be found here, > > https://mail.haskell.org/pipermail/haskell-cafe/2016-February.txt > and it started as a discussion about the use of ($) for function > application. Namely, what should its type be? Its type is :: (a -> b) -> a -> b; that's in the Haskell Report and what you get at the GHCi prompt :t ($) -- at GHC 6.5 with no extensions on. Also while we're at it Data.Function.& :: a -> (a -> b) -> b -- reverse application, which'll do for the paper Ben suggested. > Whatever you answer is going to be wrong. That's a fine type for the purposes of the 'thought-dialogue' -- which is not a language specification. If GHC's type under the hood is polykinded/higher-ordered/typeRep'd/etc yes that'll confuse beginners, but won't upset the 'thought'. > The root of that problem is that ($) is itself a > function, and you can't insist on using a function to apply function > application without risk of severe injury. So the only way to even use > ($) is via the true function application syntax, namely whitespace. So that's what the authors of EWD.pdf do at the end of the piece, so that they derive (.) by eta-reduction. It's bogus. Also bogus their is putting '.' between the lambda and the bound variable. WTF is that? You don't 'apply' lambda to a variable; it's not a function; it's a binding mechanism. Some syntaxes for lambda calculus put a dot _after_ the bound variable, where Haskell uses ->. To put it bluntly: the authors are blundering. > But whitespace as function application syntax has its own problems. EWD1300 has only a short section on 'Invisible operators'. Dijkstra doesn't like them. To expand his examples, in: > π + x sin(y) The invisible space (juxtaposition) between x and sin means multiplication; the invisible non-spaces within "sin" are not juxtaposition, they're merely a multi-letter name; the invisible non-space between "sin" and parens is function application. (To be precise in C-family languages, it's the pair of parens: rand() is niladic function rand applied to no arguments.) Practical programming languages are limited to ASCII, so can't have UTF-8 chars in names, so we'd have to spell π as "pi" -- which includes another invisible non-space. Then EWD1300 wants to put alternating operators with names, thusly: > pi + x * sin.y > So we want something like ($), but we want it to be *syntax*, Yes. EWD1300's syntax is that (presumably) what's lexed as a (sequence-of) symbol alternates with what's lexed as a name/sequence-of letter. And there's precedence/associativity; and parens' only purpose is to override. EWD1300 does not claim that what's between "pi" and + or between + and x is function application. EWD1300 does not consider operator sections or partial application of operators; only partial application of functions. There's brief mention of 'lambda-abstraction' (partial application), but no working of actual lambda expressions. EWD1300 is not talking about Haskell's peculiar syntax at all. Including not talking about lambda syntax. And I'm sure he'd complain about the iffy use of parens in operator sections -- they're not there merely to override precedence; (5) === 5; (pi) === pi; (+) =/= + > and it should take the place of " " rather than supplement it. > That's the argument those guys (and the paper Ben suggested) are trying to make. EWD1300 does not suggest there's function application between an operator and its operands -- although one could argue that's just as much juxtaposition. Suggesting that for any other operator than ($) would be OK and thereby deals with Haskell's operator sections. But suggesting it for ($) leads to infinite regress. Dijkstra (the real one) was smart enough to see that. The pdf poses a bogus problem; direct consequence of the authors not understanding EWD1300. AntC

1 0

Sliding windows for streaming
by David Feuer 07 Jun '20

07 Jun '20

I'm looking for a bit of help with a library design choice. The streaming package currently offers a slidingWindow function converting a stream into a stream of fixed-size windows of that stream[1]: slidingWindow :: Monad m => Int -- Window size -> Stream (Of a) m b -> Stream (Of (Seq a)) m b This is based directly on a similar function in conduit. Using a rough translation into the world of lists, we have slidingWindow 3 "abcdef" = ["abc","bcd","cde","def"] The awkward case where the stream is shorter than the window is handled by potentially producing a short sequence at the end: slidingWindow 3 "ab" = ["ab"] slidingWindow 3 "" = [""] I recently merged a pull request that adds variations on sliding window maxima and minima using what's apparently a "folklore" algorithm. For example slidingWindowMax 3 "abcbab" = "abcccb" This is basically like slidingWindowMax k = map maximum . slidingWindow k except that an empty stream doesn't yield anything, to avoid undefined values. The big advantage of these specialized functions is that rather than having to take a maximum over a sequence of length `k` at each step, they only do a constant (amortized) amount of work at each step. Nice! But not very general. Suppose we want to take a moving average of some sort, like an arithmetic mean, geometric mean, harmonic mean, or median? That thought leads quite naturally to a data structure: a queue holding elements of some arbitrary *semigroup* that efficiently keeps track of the sum of all the elements in the queue[2]. While the choice of *data structure* is moderately obvious, the choice of *sliding window function* is less so. The tricky bit is, again, what happens when the stream is too short for the window. If you work in the Sum semigroup and divide the results by the window size to get a moving average, then a too-short stream will give a (single) result that's completely wrong! Oof. What would be the most useful way to deal with this? The streams in `streaming` give us the option of producing a distinguished "return" value that comes after all the yields. Would it make sense to *return* the incomplete sum, and the number of elements that went into it, instead of *yielding* it into the result stream? That seems flexible, but maybe a tad annoying. What do y'all think? [1] https://hackage.haskell.org/package/streaming-0.2.3.0/docs/Streaming-Prelud… [2] See the AnnotatedQueue in https://github.com/haskell-streaming/streaming/pull/99/files which basically modifies Okasaki's implicit queues using some of the basic ideas that appear in Hinze-Paterson 2–3 trees.

3 4

Building Asterius locally
by Hilco Wijbenga 06 Jun '20

06 Jun '20

Hi all, Has anyone tried building Asterius (https://asterius.netlify.app/building.html)? I'm stuck because GHC/GCC can't find binaryen-c.h which is available in /usr/include/binaryen. If I add a symbolic link in /usr/include to binaryen-c.h then this one is found but the next one isn't. Obviously, I don't want to link to every binaryen header file like that. binaryen > /tmp/stack-b6b7026e470b48c5/binaryen-0.0.1.1/cbits/wrappers.c:1:10: error: binaryen > fatal error: binaryen-c.h: No such file or directory binaryen > 1 | #include <binaryen-c.h> binaryen > | ^~~~~~~~~~~~~~ binaryen > | binaryen > 1 | #include <binaryen-c.h> binaryen > | ^ binaryen > compilation terminated. binaryen > `gcc' failed in phase `C Compiler'. (Exit code: 1) I've tried adding include-dirs: /usr/include/binaryen in various places (in package.yaml) but that did not make any difference. In short, how do I make sure /usr/include/binaryen is part of the search path for C header files? Cheers, Hilco

1 0

ICFP 2020: First Call for Students Volunteers
by Victor Lanvin 06 Jun '20

06 Jun '20

Please don't hesitate to share this information with your students, classmates or colleagues! ICFP'20 FIRST CALL FOR STUDENT VOLUNTEERS ========================================= 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. In order to smoothly run the conference, associated workshops, and tutorials, we need student volunteers to help out on the practical aspect of the organization. All the events associated with ICFP'20 will take place **virtually** from Sun 23 - Fri 28 August 2020. Even though the event will be virtual, we will more than ever need the help of student volunteers to make sure everything runs smoothly. In return, as an ICFP 2020 student volunteer, you will get more visibility and be able to interact closely with researchers, academics and practitioners from various disciplines and discuss with other students from around the world. While the exact structure of the conference is still being discussed, job assignments for student volunteers will probably include: 1- Assisting with technical sessions, workshops, tutorials, Q&A sessions, and panels. 2- Helping to get authors' videos prepped and ready for broadcast. 3- Managing the various slack channels and social activities. To be considered as a Student Volunteer for ICFP, please fill in the following application form. https://forms.gle/TRN9LxWWkfR3sHtN6 The permanent link to this form can be found on the official conference website. https://icfp20.sigplan.org/track/icfp-2020-student-volunteering There are two rounds of calls with the following deadlines: * deadline for first round: June 21st, 2020 AoE (notification: June 23rd) * deadline for second round: July 19th, 2020 AoE (notification: July 21th) **Please note that the first deadline is in two weeks only!** Positive notifications given in the first round are firm and the second round is only for spots not filled by the first round. If your application is not accepted in the first round, it will automatically be included in the 2nd round.

1 0

Re: [Haskell-cafe] GHC trying to load dynamic library when it really shouldn't
by Will Song 04 Jun '20

04 Jun '20

Is the shared library of the dependency that has it statically linked in not enough? At this point I am also unsure how ghc is able to determine which library to dynamically load. > On Jun 4, 2020, at 2:03 PM, Brandon Allbery <allbery.b(a)gmail.com> wrote: > > ghci loads dynamically for the same reason TH does: you would > otherwise need a ghc linked against your static library. (You could > try -fobject-code and/or an explicit -l option for the library with > ghci.) > > On 6/4/20, Will Song via Haskell-Cafe <haskell-cafe(a)haskell.org <mailto:haskell-cafe@haskell.org>> wrote: >> The 2nd module to compile uses TemplateHaskell and that's where stack build >> will fail. However, trying to load Echidna.Mutator into ghci will also fail >> for the same reason, but it compiles just fine. The import list is pasted >> below. >> >> {-# LANGUAGE FlexibleContexts #-} >> >> module Echidna.Mutator where >> >> import Control.Monad.Random.Strict (fromList, MonadRandom, getRandomR) >> import Data.Maybe (maybe) >> >> import qualified Data.ListLike as LL >> >>> On Jun 4, 2020, at 1:51 PM, Jinwoo Lee <jinwoo68(a)gmail.com> wrote: >>> >>> Does your code use TemplateHaskell? In that case, the compiler will try to >>> load the library for the compile-time computation. >>> >>> >>> On Wed, Jun 3, 2020 at 12:17 PM Will Song via Haskell-Cafe >>> <haskell-cafe(a)haskell.org <mailto:haskell-cafe@haskell.org> <mailto:haskell-cafe@haskell.org <mailto:haskell-cafe@haskell.org>>> wrote: >>> Hey all, I am experiencing some weird build issues with respect to GHC. I >>> would like to mention that what I am doing is somewhat non-standard but >>> theoretically I think it should work. >>> >>> I am developing a Haskell program which depends on a library, hevm, with >>> several external library dependencies, libsecp256k1 and libff. Since these >>> libraries are a bit of a pain to install by default in the macOS >>> ecosystem, having no brew packages, my plan is to statically link these >>> libraries into the release builds. To start off this task, I have simply >>> moved the dynamic libraries for secp256k1 to another location, e.g. # mv >>> /usr/local/lib/libsecp256k1.dylib{,.bak}. Rebuilding the dependency hevm >>> appears to work as expected. It compiles fine, and otool reports the >>> following. >>> >>> % otool -L .stack-work/install/x86_64-osx/lts-14.14/8.6.5/bin/hevm >>> .stack-work/install/x86_64-osx/lts-14.14/8.6.5/bin/hevm: >>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current >>> version 1281.0.0) >>> libff.dylib (compatibility version 0.0.0, current version 0.0.0) >>> /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current >>> version 800.7.0) >>> /usr/lib/libz.1.dylib (compatibility version 1.0.0, current >>> version 1.2.11) >>> /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, >>> current version 5.4.0) >>> /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current >>> version 7.0.0) >>> /usr/lib/libcharset.1.dylib (compatibility version 2.0.0, current >>> version 2.0.0) >>> >>> We can check libHShevm... as well and it does not depend on the secp256k1 >>> dylib anymore. >>> >>> However, moving back onto my program, the build fails. >>> >>> % stack build >>> Building all executables for `echidna' once. After a successful build of >>> all of them, only specified executables will be rebuilt. >>> echidna-1.5.0: configure (lib + exe) >>> Configuring echidna-1.5.0... >>> Warning: 'ghc-options: -threaded' has no effect for libraries. It should >>> only >>> be used for executables. >>> echidna-1.5.0: build (lib + exe) >>> Preprocessing library for echidna-1.5.0.. >>> Building library for echidna-1.5.0.. >>> [ 1 of 24] Compiling Echidna.Mutator ( lib/Echidna/Mutator.hs, >>> .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/Echidna/Mutator.o ) >>> [ 2 of 24] Compiling Echidna.Orphans.JSON ( lib/Echidna/Orphans/JSON.hs, >>> .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/Echidna/Orphans/JSON.o ) >>> <command line>: can't load .so/.DLL for: libsecp256k1.dylib >>> (dlopen(libsecp256k1.dylib, 5): image not found) >>> >>> -- While building package echidna-1.5.0 using: >>> >>> /Users/incertia/.stack/setup-exe-cache/x86_64-osx/Cabal-simple_mPHDZzAJ_2.4.0.1_ghc-8.6.5 >>> --builddir=.stack-work/dist/x86_64-osx/Cabal-2.4.0.1 build lib:echidna >>> exe:echidna-test --ghc-options " -ddump-hi -ddump-to-file >>> -fdiagnostics-color=always" >>> Process exited with code: ExitFailure 1 >>> >>> Would anyone happen to know why this failure is occurring? We have no C >>> sources that would create unresolved references to this library, all the >>> code is Haskell. My understanding is that ghc should end up using the >>> static variant now that there is no dynamic library but clearly this >>> intuition is misguided. >>> _______________________________________________ >>> 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> >>> <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. >> >> > > > -- > brandon s allbery kf8nh > allbery.b(a)gmail.com <mailto:allbery.b@gmail.com>

1 0

GHC trying to load dynamic library when it really shouldn't
by Will Song 04 Jun '20

04 Jun '20

Hey all, I am experiencing some weird build issues with respect to GHC. I would like to mention that what I am doing is somewhat non-standard but theoretically I think it should work. I am developing a Haskell program which depends on a library, hevm, with several external library dependencies, libsecp256k1 and libff. Since these libraries are a bit of a pain to install by default in the macOS ecosystem, having no brew packages, my plan is to statically link these libraries into the release builds. To start off this task, I have simply moved the dynamic libraries for secp256k1 to another location, e.g. # mv /usr/local/lib/libsecp256k1.dylib{,.bak}. Rebuilding the dependency hevm appears to work as expected. It compiles fine, and otool reports the following. % otool -L .stack-work/install/x86_64-osx/lts-14.14/8.6.5/bin/hevm .stack-work/install/x86_64-osx/lts-14.14/8.6.5/bin/hevm: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.0.0) libff.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 800.7.0) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11) /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0) /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/lib/libcharset.1.dylib (compatibility version 2.0.0, current version 2.0.0) We can check libHShevm... as well and it does not depend on the secp256k1 dylib anymore. However, moving back onto my program, the build fails. % stack build Building all executables for `echidna' once. After a successful build of all of them, only specified executables will be rebuilt. echidna-1.5.0: configure (lib + exe) Configuring echidna-1.5.0... Warning: 'ghc-options: -threaded' has no effect for libraries. It should only be used for executables. echidna-1.5.0: build (lib + exe) Preprocessing library for echidna-1.5.0.. Building library for echidna-1.5.0.. [ 1 of 24] Compiling Echidna.Mutator ( lib/Echidna/Mutator.hs, .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/Echidna/Mutator.o ) [ 2 of 24] Compiling Echidna.Orphans.JSON ( lib/Echidna/Orphans/JSON.hs, .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/Echidna/Orphans/JSON.o ) <command line>: can't load .so/.DLL for: libsecp256k1.dylib (dlopen(libsecp256k1.dylib, 5): image not found) -- While building package echidna-1.5.0 using: /Users/incertia/.stack/setup-exe-cache/x86_64-osx/Cabal-simple_mPHDZzAJ_2.4.0.1_ghc-8.6.5 --builddir=.stack-work/dist/x86_64-osx/Cabal-2.4.0.1 build lib:echidna exe:echidna-test --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always" Process exited with code: ExitFailure 1 Would anyone happen to know why this failure is occurring? We have no C sources that would create unresolved references to this library, all the code is Haskell. My understanding is that ghc should end up using the static variant now that there is no dynamic library but clearly this intuition is misguided.

2 2

Popularity?!
by Gregory Guthrie 03 Jun '20

03 Jun '20

Ah; finally in a toip-10 list! Not for love, but for money..?! The Stack Overflow 2020 Developer Survey's top 10 "top paying" languages: 1. Perl, $76,000 2. Scala, $76,000 3. Go, $74,000 4. Rust, $74,000 5. Ruby, $71,000 6. Bash/Shell/PowerShell, $65,000 7. Objective-C, $64,000 8. Haskell, $60,000 9. Julia, $59,000 10. Python, $59,000 Dr. Gregory Guthrie Maharishi International University ----------------------------------------------------------------

7 7

How to compose operations in streaming
by ☂Josh Chia (謝任中) 03 Jun '20

03 Jun '20

I have a question about the streaming package. Let's say I have str :: Stream (Of String) IO () I want to putStrLn each element and then print the length of str, so I could do this: import Streaming import qualified Streaming.Prelude as SP doit :: Stream (Of String) IO () -> IO () doit str = do SP.mapM_ putStrLn str SP.length_ str >>= print However, will this result in doing 2 passes over str so that the memory requirement is not constant? If so, is there a simple way to combine the two actions so that only pass is needed? I could probably use a counter in a StateT but that's not really simple. More generally, are there techniques for combining folds like how one would with the foldl package?

2 3

Call for Submissions: ICFP Student Research Competition
by Sam Tobin-Hochstadt 02 Jun '20

02 Jun '20

ICFP 2020 Student Research Competition Call for Submissions ICFP invites students to participate in the Student Research Competition, which will be held virtually alongside the main conference, in order to present their research and receive feedback from prominent members of the programming language research community. As usual, the SRC consists of three rounds: * Extended abstract * Poster session at ICFP 2020 * ICFP presentation To make the virtual competition fruitful, we will make sure that every student will have an "invited audience" during the poster session. We are also planning to organize a social event for the students. Please visit the SRC website for updates. ### Important Dates Submissions due: 26 Jun 2020 (Friday) https://icfp20src.hotcrp.com Notification: 10 July 2020 (Friday) Conference: 23 August (Sunday) - 28 August (Friday) ### Submission Details Each submission (referred to as "abstract" below) should include the student author’s name and e-mail address; institutional affiliation; research advisor’s name; ACM student member number; category (undergraduate or graduate); research title; and an extended abstract addressing the following: * Problem and Motivation: Clearly state the problem being addressed and explain the reasons for seeking a solution to this problem. * Background and Related Work: Describe the specialized (but pertinent) background necessary to appreciate the work in the context of ICFP areas of interest. Include references to the literature where appropriate, and briefly explain where your work departs from that done by others. * Approach and Uniqueness: Describe your approach in addressing the problem and clearly state how your approach is novel. * Results and Contributions: Clearly show how the results of your work contribute to programming language design and implementation in particular and to computer science in general; explain the significance of those results. * Submissions must be original research that is not already published at ICFP or another conference or journal. One of the goals of the SRC is to give students feedback on ongoing, unpublished work. Furthermore, the abstract must be authored solely by the student. If the work is collaborative with others and*or part of a larger group project, the abstract should make clear what the student’s role was and should focus on that portion of the work. * Formatting: Submissions must be in PDF format, printable in black and white on US Letter sized paper, and interpretable by common PDF tools. All submissions must adhere to the "ACM Small" template that is available (in both LaTeX and Word formats) from https://www.acm.org/publications/authors/submissions. For authors using LaTeX, a lighter-weight package, including only the essential files, is available from http://sigplan.org/Resources/Author/#acmart-format. The submission must not exceed 3 pages in PDF format. Reference lists do not count towards the 3-page limit. Further information is available at the ICFP SRC website: https://icfp20.sigplan.org/track/icfp-2020-Student-Research-Competition Program Committee: Chair: Youyou Cong (Tokyo Institute of Technology) Stephen Chang (University of Massachusetts Boston) Jesper Cockx (Delft University of Technology) Hsiang-Shang Ko (Institute of Information Science, Academia Sinica) Cyrus Omar (University of Michigan)

1 0

Postdoc position at University of Bristol in functional programming
by Meng Wang 01 Jun '20

01 Jun '20

Dear Haskellers, The programming languages group at Bristol has an open postdoc position in the area of functional programming. Haskell programmers are particularly welcome! Best regards, Meng Meng Wang, PhD (Oxon) Senior Lecturer in Programming Languages International Director, SCEEM School We are looking for an enthusiastic, self-motivated individual to contribute to an EPSRC-funded project, which aims to design programming languages that guarantee strong properties, and the application of them. The post holder will be based in the programming languages group at the University of Bristol Computer Science Department, which consists of three academics, two PDRAs, and a number of PhD students. You will also be working with a network of partners from Oxford, Edinburgh, Kent, Tohoku Japan, Chalmers Sweden, and industrial partner DFINITY Foundations providing expertise on WebAssembly. The University of Bristol is a world-leading university (consistently ranked top 50 in the world by QS) with an exceptionally strong Faculty of Engineering (which the Department of Computer Science is part of). Bristol is a mid-sized city and is widely considered as one of the best places to live in the country. You should have a PhD in programming languages, or a closely related field. This post is available immediately and is offered on a full-time based for an initial term of three years. Appointment at a higher salary point than grade I is possible based on relevant experience. Informal enquiries should be addressed to Dr. Meng Wang (meng.wang(a)bristol.ac.uk<mailto:meng.wang@bristol.ac.uk>) For more details about this position, please see: http://www.bristol.ac.uk/jobs/find/details.html?nPostingID=68914&nPostingTa… Deadline: 28 Jun 2020

1 0

Why does Haskell have both `Maybe a` and `Either a ()`?
by Wiebe-Marten Wijnja 30 May '20

30 May '20

Greetings, everyone! Recently I was involved in a discussion on the new ML-style language 'gleam'. Gleam has for quite a while now only had an `Either a b` type, with all functions that in Haskell one would use a `Maybe a` for, working on an `Either a ()` instead. In the discussion(https://github.com/gleam-lang/gleam/issues/591), the language designers were asking the community whether it would make sense to add `Maybe` to the language as well, or keep using only `Either a ()`. My question: Is the difference between `Maybe a` and `Either a ()` only semantic and are they functionally equivalent, or are there differences in functionality as well? Have a nice day, ~Marten / Qqwy

8 7

ANN: Data.Monoid.First and Data.Monoid.Last are here to stay
by Simon Jakobi 29 May '20

29 May '20

Hi! I'm happy to report that the planned deprecation of Data.Monoid.{First,Last} [0] has finally been scrapped [1]. The original motivation for removing these newtypes of Maybe was to resolve the name conflict with Data.Semigroup.{First,Last} [2]. Unfortunately, while implementing the deprecation, I ended up discovering a whole host of problems with the suggested migration to (Maybe Data.Semigroup.First) and (Maybe Data.Semigroup.Last), which I have attempted to summarize in my email to the libraries mailing list [3]. I would like to thank everyone who contributed to the discussion of the matter, the CLC, and also everyone who pushed me to finally get the matter resolved. :) Cheers! Simon [0] http://hackage.haskell.org/package/base-4.14.0.0/docs/Data-Monoid.html#t:Fi… [1] https://gitlab.haskell.org/ghc/ghc/-/commit/f44d7ae08442ae6227db37cacc97fe0… [2] https://mail.haskell.org/pipermail/libraries/2018-April/028712.html [3] https://mail.haskell.org/pipermail/libraries/2020-April/030357.html

1 0

[Open Kattis Problem] How can I speed up my A* algorithm and/or binomial heaps?
by Dominik Bollmann 24 May '20

24 May '20

Hi Haskell-Cafe, I've been trying to solve the Problem "10 Kinds Of People" at https://open.kattis.com/problems/10kindsofpeople. My idea was to use the A* algorithm to check whether the destination can be reached from the source. To model the A* algorithm's priority queue, I also wrote a naive implementation of a binomial heap. I've attached the code snippet below. Unfortunately, my solution doesn't pass all of Open Kattis' test cases. In particular, it times out on the 22nd test case. Therefore I'm wondering how to speed up my solution. Did I make any obvious, silly mistakes? According to my time-profiling it seems that most of the time is spent in the binomial heap's deleteMin function. Maybe I should therefore not model the Heap as a list of trees, but rather as a vector of trees? Any hints on how to make the below snippet run faster is highly appreciated! :-) Thanks! Dominik ============================================= import Control.Monad import Data.Function import Data.Foldable (foldl') import Data.List (minimumBy, delete) import Data.Maybe import qualified Data.Set as S import qualified Data.Vector as V data Tree a = Node Int a [Tree a] deriving (Eq, Show) type Heap a = [Tree a] rank :: Tree a -> Int rank (Node k _ _) = k root :: Tree a -> a root (Node _ x _) = x children :: Tree a -> [Tree a] children (Node _ _ cs) = cs findMin :: Ord a => Heap a -> Maybe a findMin [] = Nothing findMin (t:ts) = Just . root $ foldl' selectMin t ts where selectMin e a | root e <= root a = e | otherwise = a empty :: Heap a empty = [] singleton :: Ord a => a -> Heap a singleton x = insert x empty insert :: Ord a => a -> Heap a -> Heap a insert x ts = foldr increment singleton ts where singleton = [Node 0 x []] increment t (h:hs) | rank t > rank h = t:h:hs | rank t == rank h = linkTrees t h : hs | rank t < rank h = error "insert: invalid case!" linkTrees :: Ord a => Tree a -> Tree a -> Tree a linkTrees t1 t2@(Node r x ts) | root t1 < root t2 = linkTrees t2 t1 | otherwise = Node (r+1) x (t1:ts) fromList :: Ord a => [a] -> Heap a fromList = foldr insert empty union :: Ord a => Heap a -> Heap a -> Heap a union h1 h2 = reverse $ reverse h1 `add` reverse h2 where add (t1:t2:t1s) t2s -- take care of the carry bit | rank t1 == rank t2 = add (linkTrees t1 t2 : t1s) t2s add [] t2s = t2s add t1s [] = t1s add (t1:t1s) (t2:t2s) | rank t1 == rank t2 = add (linkTrees t1 t2 : t1s) t2s | rank t1 < rank t2 = t1 : add t1s (t2:t2s) | rank t1 > rank t2 = t2 : add (t1:t1s) t2s deleteMin :: Ord a => Heap a -> Heap a deleteMin h = delete minTree h `union` children minTree where minTree = minimumBy (compare `on` root) h uncons :: Ord a => Heap a -> Maybe (a, Heap a) uncons h = do min <- findMin h pure (min, deleteMin h) data Entry p a = Entry { priority :: p, payload :: a } deriving Show instance Eq p => Eq (Entry p a) where (Entry p1 _) == (Entry p2 _) = p1 == p2 instance Ord p => Ord (Entry p a) where (Entry p1 _) <= (Entry p2 _) = p1 <= p2 data Point = Point { y :: !Int, x :: !Int } deriving (Eq, Ord, Show) data PeopleKind = Binary | Decimal deriving Eq newtype Map = Map { getMap :: (V.Vector (V.Vector PeopleKind)) } deriving Show instance Show PeopleKind where show Binary = "binary" show Decimal = "decimal" readMap :: Int -> Int -> IO Map readMap r c = do rows <- forM [1..r] $ \_ -> do row <- map readCell <$> getLine pure (V.fromListN c row) pure $ Map (V.fromList rows) where readCell :: Char -> PeopleKind readCell c = case c of '0' -> Binary '1' -> Decimal _ -> error "Map invalid!" readFromTo :: IO (Point, Point) readFromTo = do [fy, fx, ty, tx] <- map read . words <$> getLine pure (Point (fy-1) (fx-1), Point (ty-1) (tx-1)) reachable :: PeopleKind -> Map -> Point -> Point -> Bool reachable kind grid from to = go S.empty (singleton entry0) where entry0 = Entry (0 + estimate from to, 0) from go explored frontier = case uncons frontier of Nothing -> False Just (Entry (_, cost) point, frontier') | point == to -> True | point `S.member` explored -> go explored frontier' | otherwise -> let successors = map (mkEntry cost) $ neighbors kind grid point in go (S.insert point explored) (frontier' `union` fromList successors) mkEntry c s = Entry (c+1 + estimate s to, c+1) s estimate :: Point -> Point -> Double estimate (Point y1 x1) (Point y2 x2) = sqrt . fromIntegral $ (y2 - y1)^2 + (x2 - x1)^2 neighbors :: PeopleKind -> Map -> Point -> [Point] neighbors k (Map m) (Point y x) = catMaybes [left, right, top, bottom] where left = kindOk y (x-1) right = kindOk y (x+1) top = kindOk (y-1) x bottom = kindOk (y+1) x kindOk y x = do kind <- m V.!? y >>= (V.!? x) guard (kind == k) pure (Point y x) main :: IO () main = do [rows, cols] <- map read . words <$> getLine grid <- readMap rows cols queries <- read <$> getLine forM_ [1..queries] $ \_ -> do (from, to) <- readFromTo let kind = kindAt grid from if reachable kind grid from to then print kind else putStrLn "neither" where kindAt (Map m) (Point y x) = m V.! y V.! x

2 2

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