- Haskell-Cafe - Haskell.org

You're invited to the New York Haskell CoHack
by Chris Smith 15 May '19

15 May '19

Fellow Haskellers, In cooperation with the New York Haskell User Group, I'm now organizing a monthly co-hacking event for Haskell programmers in New York. We are meeting on June 1st, and the first Saturday of each month after that. (However, to avoid the U.S. holiday weekend, we're meeting on June 29 instead of July 6.) More details and RSVP form at https://www.meetup.com/NY-Haskell/events/261245898/ This is an informal event where you can meet and collaborate with the rest of the Haskell community in New York. I am taking the format from the Atlanta Haskathon <https://www.meetup.com/Atlambda-Haskathon/>, where it's worked really well. We'll have time for lightning talks, and then open hacking time. To stay focused on project work, we will ask everyone to state a goal for the day, and check in on progress when we're wrapping up. Your choice of goal, though, is entirely up to you. You can use the time to collaborate on a project, get help learning Haskell or advice on using libraries or tools, help others, or just work by yourself. There will be refreshments provided courtesy of the Microsoft Reactor space.

1 0

Cabal revision online form silently converts file to Windows line endings, breaking patches
by Niklas Hambüchen 14 May '19

14 May '19

I noticed that if you use Hackage's online Cabal file editor, it changes all your \n line endings to \r\n. This breaks all patches written against upstream .cabal files. For example, if I write a patch against `cachix-0.2.0` git repo's .cabal file, I can no longer apply it to whatever revisions of it Hackage has, even if there's no real conflict. Here's a reproduction (I changed only 1 line in the editor, and it shows the whole file as changed): diff -u <(curl https://hackage.haskell.org/package/AesonBson-0.2.0/revision/0.cabal) <(curl https://hackage.haskell.org/package/AesonBson-0.2.0/revision/1.cabal) I found this especially problematic for nixpkgs, where patching packages is a common practice.

6 6

How to optimize a directory scanning?
by Magicloud Magiclouds 12 May '19

12 May '19

Hi, I have asked this in Stackoverflow without getting an answer. Wondering if people here could have some thoughts. I have a function reading the content of /proc every second. Surprisingly, its CPU usage in top is around 5%, peak at 8%. But same logic in C or Rust just takes like 1% or 2%. Wondering if this can be improved. /proc is virtual filesystem, so this is not related to HDD performance. And I noticed this difference because my CPU is too old (Core Gen2). On modern CPU, as tested by others, the difference is barely noticeable. import Control.Exception import Control.Concurrent import Control.Monad import Data.Char import Data.Maybe import System.Directory import System.FilePath import System.Posix.Files import System.Posix.Signals import System.Posix.Types import System.Posix.User import System.IO.Strict as Strict watch u limit0s limit0h = do listDirectory "/proc/" >>= mapM_ (\fp -> do isMyPid' <- maybe False id <$> wrap2Maybe (isMyPid fp u) wrap2Maybe (Strict.readFile ("/proc/" </> fp </> "stat"))) threadDelay 1000000 watch u limit0s limit0h where wrap2Maybe :: IO a -> IO (Maybe a) wrap2Maybe f = catch ((<$>) Just $! f) (\(_ :: IOException) -> return Nothing) isMyPid :: FilePath -> UserID -> IO Bool isMyPid fp me = do let areDigit = fp >= "0" && fp <= "9" isDir <- doesDirectoryExist $ "/proc/" </> fp owner <- fileOwner <$> getFileStatus ("/proc" </> fp) return $ areDigit && isDir && (owner == me) -- 竹密岂妨流水过山高哪阻野云飞

10 18

LFVM-STG Compilation
by james faure 10 May '19

10 May '19

Hello, I want to introduce the STG backend I am currently working on: https://github.com/jfaure/lfvm-stg I'd love to see how much interest there is for this, to receive any comments, and find out if I've missed anything ! The goal is to massively speed up compilation times and generate faster and clearer code, and in that respect I am already quite successful. Llvm is very well suited for encoding a (lazy) functional language, however the evaluation mechanism is very different to ghc's stg, there is notably no continuation passing nor result registers. In LFVM, all non constant let bindings are given an llvm function. I believe this approach is more natural, the llvm more accurately reflects the source code and we get proper stack traces in a debugger. Status: The project is barely a month old, and I'm working to support everything ghc's code generation supports. The STG is heavily based on the one found in ghc and, at this time and as far as I can tell, supports everything except multithreading, a gc and lazy evaluation. The current idea I think is very promising is to use an inferred pi calculus to elegantly implement all 3 missing parts at once. Pi calculus [1] (process calculus) In the STG * Multithreading occurs for arguments of functions with >1 arity * Perfect garbage collection is quite probably possible [2], where allocation creates a new pi name, and its uses are modeled by pi calculus communication * Perfect Lazy evaluation (in the sense that the wrapper and associated wrapped type overhead is coerced away after the first evaluation) is possible in the pi calculus and closely linked the gc model. I intend to make strict evaluation the default, If you want lazy (for MonadFix or infinite lists or whatever), you must request it. [1]: https://en.wikipedia.org/wiki/%CE%A0-calculus [2]: https://www.researchgate.net/publication/228514964_Resources_garbage-collec… James Faure (Discord: J4#0303)

6 7

Need help understanding Ralf Hinze's Lifting Lemma, and its connection to the Transfer Principle
by Brian Merchant 10 May '19

10 May '19

Hi all, I am a student in mathematics exploring alternative ways in which the transfer principle ( https://en.wikipedia.org/wiki/Transfer_principle ) can be proved. I've found a paper by Ralf Hinze which I think is relevant: https://www.cs.ox.ac.uk/ralf.hinze/Lifting.pdf. However, I'd benefit from being able to talk to someone who understands the notation starting section 3 and onwards, as I am very much a Haskell newbie (everything I have learned, has been in the last 4 days, as I try to decipher this paper). Would anyone be willing to have a conversation with me regarding this? Kind regards, Brian

2 1

FHPNC'19 Deadline Extension and 2nd Call for Papers
by Marco Zocca 10 May '19

10 May '19

We are happy to extend the submission deadline to the 2019 ACM SIGPLAN Functional High Performance and Numerical Computing Workshop until Saturday, May 25, 2019, 12 PM AoE ("anywhere on Earth", i.e. UTC-6). Marco Zocca and Dominic Steinitz FHPNC'19 Organizing Committee ================================= 2nd Call for Papers (Extended Abstracts and Full Papers) ACM SIGPLAN Workshop on Functional High-Performance and Numerical Computing (FHPNC), Berlin, August 18, 2019 Satellite event of the 24th ACM SIGPLAN International Conference on Functional Programming (ICFP 2019) 18 - 23 August, 2019 Homepage : https://icfp19.sigplan.org/home/FHPNC-2019#Call-for-Papers The ACM SIGPLAN International Workshop on Functional High-Performance and Numerical Computing aims to bring together researchers and practitioners exploring or employing the use of functional or declarative programming languages or techniques in scientific computing, and specifically in the domains of high-performance computing and numerical programming. The purpose of the meeting is to enable sharing of results, experiences, and novel ideas about how high-level, declarative techniques can help make high-performance, distributed/parallel, or numerically-intensive code dealing with computationally challenging problems easier to write, read, maintain, or portable to new hardware architectures. Areas of interest include, but are not limited to: * relevant compiler technologies * runtime systems (including fault tolerance mechanisms and those supporting distributed or parallel computation) * domain-specific languages (embedded or standalone) * type systems * formal methods * software libraries (e.g. for exact or interval arithmetic). ## Submission details Submissions should fall into one of two categories: * Regular research papers (up to 12 pages) * Extended abstracts (1 - 2 pages) The bibliography will not be counted against the page limits for either category. Regular research papers are expected to present novel and interesting research results, and will be included in the formal proceedings. Extended abstracts should report work in progress that the authors would like to present at the workshop; they will be evaluated primarily for relevance and interest. Extended abstracts will be distributed to workshop attendees but will not be published in the formal proceedings. We welcome submissions from PC members (with the exception of the PC Chair), but these submissions will be held to a higher standard. Submission is handled through the HotCRP site. All submissions should be in portable document format (PDF) and formatted using the ACM SIGPLAN style guidelines. Submissions written with LaTeX are required to use the ‘acmart’ format and the two-column ‘sigplan’ subformat (not to be confused with the one-column ‘acmlarge’ subformat!). Extended Abstracts must be submitted with the label ‘Extended abstract’ clearly in the title. ## Publication The proceedings of FHPNC 2019 will be published in the ACM Digital Library. ## Related links * Author Information and LaTeX templates : http://www.sigplan.org/Resources/Author/ * Attendee Code of Conduct: http://www.sigplan.org/Resources/Policies/CodeOfConduct/

1 0

Invititation to provide feedback on RISC-V ISA Formal Specs
by Rishiyur Nikhil 09 May '19

09 May '19

The RISC-V Foundation (riscv.org) has a task group to develop a Formal Spec for the RISC-V Instruction Set Architecture. The group has been pursuing several approaches: - 3 are written in Haskell - 1 is in SAIL, a DSL with dependent types, intended for ISA specs - 1 is in Kami, a DSL in Coq Most of them are complete enough to boot Linux, i.e., they are not for toy subsets of the ISA. They are expected and intended to become the "official" ISA spec for RISC-V, and to be used in anger, for compliance testing, formal verification of compilers, hardware designs, etc. We would love to get community feedback on these approaches. The following link provides an overview, and links to individual web sites (all on GitHub) for the 5 approaches, and information on how to provide feedback: https://github.com/riscv/ISA_Formal_Spec_Public_Review Thanks very much in advance! Rishiyur Nikhil, Chair, ISA Formal Spec Technical Group

1 0

Announce: Haskell Platform 8.6.5
by Gershom B 09 May '19

09 May '19

On behalf of the Haskell Platform team, I'm happy to announce the release of Haskell Platform 8.6.5 Now available at https://www.haskell.org/platform/ This includes GHC 8.6.5, cabal-install 2.4.1.0, and stack 1.9.3. It is an incremental release over 8.6.3 intended mainly to make available bugfixes for windows in subsequent revisions in the 8.6 series and otherwise leave everything the same. These windows fixes are important, and it is recommended all windows users upgrade to 8.6.5 whether through the platform installer or some other mechanism. For detail on these changes and fixes see https://www.haskell.org/ghc/blog/20190305-ghc-8.6.4-released.html https://www.haskell.org/ghc/blog/20190423-ghc-8.6.5-released.html As with the 8.6.3 release, we are only providing core builds. Further, in 8.6.3 we moved from generic linux installers to recommending users install ghc through ghcup. As discussed in the last announcement, we have now moved to recommending os x users also use ghcup rather than a dedicated binary installer. For more details, please see the 8.6.3 announcement at https://mail.haskell.org/pipermail/haskell-cafe/2018-December/130371.html Happy Haskell Hacking all, Gershom

1 0

how to debug segfaults in ghc-compiled executable?
by Johannes Waldmann 09 May '19

09 May '19

Dear Cafe, I keep getting spurious segfaults from a dynamically linked executable compiled by ghc. In dmesg: [402186.145258] pure-matchbox:w[25362]: segfault at 7f98644a5c00 ip 00000000017ab65e sp 00007f98377f9988 error 4 [402186.145262] Code: b8 0a 7e 77 01 48 83 ec 08 48 89 df 48 89 c3 31 c0 ff d3 48 83 c4 08 48 8b 1c 25 50 90 a7 01 48 89 c1 48 6b c9 18 48 83 c1 10 <48> 83 3c 0b 00 74 30 48 8b 1c 25 50 90 a7 01 48 6b c0 18 48 83 c0 How can I find out what part of the program this refers to? The error might be related to external libraries (used by hmatrix-glpk) but I don't know how to verify this. When I look at the output of `nm´ for this executable, I am not seeing any address like 00017ab65e. I do not have a concrete reproducible test case, but the bug happens statistically (say, in one out of 1000 runs). - J.

2 1

Journal of Functional Programming - Call for PhD Abstracts
by Graham Hutton 08 May '19

08 May '19

Dear all, If you or one of your students recently completed a PhD in the area of functional programming, please submit the dissertation abstract for publication in JFP: simple process, no refereeing, open access, deadline 31st May 2019. Please share! Best wishes, Graham Hutton ============================================================ CALL FOR PHD ABSTRACTS Journal of Functional Programming Deadline: 31st May 2019 http://tinyurl.com/jfp-phd-abstracts ============================================================ PREAMBLE: Many students complete PhDs in functional programming each year. As a service to the community, twice per year the Journal of Functional Programming publishes the abstracts from PhD dissertations completed during the previous year. The abstracts are made freely available on the JFP website, i.e. not behind any paywall. They do not require any transfer of copyright, merely a license from the author. A dissertation is eligible for inclusion if parts of it have or could have appeared in JFP, that is, if it is in the general area of functional programming. The abstracts are not reviewed. Please submit dissertation abstracts according to the instructions below. We welcome submissions from both the PhD student and PhD advisor/supervisor although we encourage them to coordinate. ============================================================ SUBMISSION: Please submit the following information to Graham Hutton <graham.hutton(a)nottingham.ac.uk> by 31st May 2019: o Dissertation title: (including any subtitle) o Student: (full name) o Awarding institution: (full name and country) o Date of PhD award: (month and year; depending on the institution, this may be the date of the viva, corrections being approved, graduation ceremony, or otherwise) o Advisor/supervisor: (full names) o Dissertation URL: (please provide a permanently accessible link to the dissertation if you have one, such as to an institutional repository or other public archive; links to personal web pages should be considered a last resort) o Dissertation abstract: (plain text, maximum 350 words; you may use \emph{...} for emphasis, but we prefer no other markup or formatting; if your original abstract exceeds the word limit, please submit an abridged version within the limit) Please do not submit a copy of the dissertation itself, as this is not required. JFP reserves the right to decline to publish abstracts that are not deemed appropriate. ============================================================ PHD ABSTRACT EDITOR: Graham Hutton School of Computer Science University of Nottingham Nottingham NG8 1BB United Kingdom ============================================================ This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law.

1 0