June 2021 - Haskell-Cafe

Could optimize attoparsec if GHC would collapse `runParser (Parser parser)` to `parser`
by Tyson Whitehead 11 Jun '21

11 Jun '21

Hi. I'm hoping someone with some knowledge about GHC optimizations can weigh in and help out here. The attoparsec library has a `<|>` combinator for choice. Since attoparsec does arbitrary backtracking, you would expect that `recursiveLhs <|> rhs` would stack up a bunch of `rhs` alternatives to the depth of the recursion. Looking at the definitions though, would make you believe that so long as the `rhs` is constant as it usually is (e.g., `pure []` if you are collecting a list), inlining should result in it not stacking up a bunch of the `rhs` alternatives (intuitively the most recent one will always succeed so there is no reason to hold on to more than one). Unfortunately, it doesn't seem to work. The full details can be found in this bug report https://github.com/haskell/attoparsec/issues/186 but I believe it comes down to the fact that GHC is not collapsing a packing and immediate unpacking of the parser datatype ``` runParser (Parser parser) -> parser ``` which is resulting in the fact that the `rhs` always succeeds (i.e., doesn't use the failure continuation) not being exposed. I am hoping someone knowledgeable in these matters could weigh in. Thanks! -Tyson PS: The parser datatype is a wrapper on CPS style lambda ``` newtype Parser i a = Parser { runParser :: forall r. State i -> Pos -> More -> Failure i (State i) r -> Success i (State i) a r -> IResult i r } ``` where Failure and Success are type synonyms for the continuations ``` type Failure i t r = t -> Pos -> More -> [String] -> String -> IResult i r type Success i t a r = t -> Pos -> More -> a -> IResult i r ```

2 1

A matrix.org client library proposal
by Tristan Cacqueray 11 Jun '21

11 Jun '21

Dear Café, I'd like to publish a rather simple `matrix-client` package on hackage based on this implementation: https://github.com/softwarefactory-project/matrix-client-haskell Please let me know if you are interested or if you have a similar implementation we could collaborate on. Kind Regards, -Tristan

2 2

Hiring two Haskell devs at Standard Chartered bank
by José Pedro Magalhães 09 Jun '21

09 Jun '21

Hello, I'm hiring two Haskell devs for my team at Standard Chartered bank, in London, Singapore, or Hong Kong. My team sits in front office and has about 20 Haskell devs (well, technically Mu, our in-house variant). We work in close collaboration with trading, sales, and structuring to build diverse software, from desktop GUI applications to server-side financial analytics reports and services. The current roles are at a relatively junior level -- 2 to 5 years industrial experience expected, or a relevant PhD. Feel free to reach out to me directly if you're interested and have any questions, but applications should go via the links below. Singapore: https://scb.taleo.net/careersection/ex/jobdetail.ftl?job=2100014272 Hong Kong: https://scb.taleo.net/careersection/ex/jobdetail.ftl?job=2100014571 London: https://scb.taleo.net/careersection/ex/jobdetail.ftl?job=2100012204 Standard Chartered supports (practically fully) remote working, but only from the country of payroll. We will cover visa and relocation costs for successful applicants. Cheers, Pedro

1 0

Using stack outside the project box
by Galaxy Being 08 Jun '21

08 Jun '21

As a beginner, I was told to use stack. And I seemed to get something Haskell installed initially on my Ubuntu 21.04. But stack seems to be geared toward projects and compiling executables with ghc, and not a global ghci REPL-based way. I'm using Emacs org mode "Babel" which allows for a very nice "literate" programming in tandem with a running REPL in many REPL-friendly languages, e.g., here are code blocks in an org-mode file #+begin_src haskell :results silent :exports code data Peano = Zero | Succ Peano deriving (Show) #+end_src #+begin_src haskell :results silent :exports code myThree = Succ (Succ (Succ Zero)) #+end_src #+begin_src haskell :results verbatim :exports both myThree #+end_src #+RESULTS: : Succ (Succ (Succ Zero)) I simply hit Evaluate (Ctr-C Ctr-C) and the evaluation is handled by a running ghci REPL started up in another Emacs buffer. Supposedly, a haskell-mode and a specific Babel ob-haskell package are working together to enable this. And so it works okay, once quirks (must enclose multi-lined code in :{..:} and every REPL session seems to need a :set +m as well). I'm really quite happy with this way of doing things and have resisted the whole monolithic 1) create project in a directory, 2) put code into .hs file, 3) compile with ghc. But what I'm constantly having problems with is getting additional packages beyond the Prelude basics. My org files are in various directories, but I want (like most languages offer) to simply interact with that language on a global level wherever I am, whatever files and directories and Haskell code I'm working on. Sometimes doing an import works; often enough not. Then I have to do something with stack -- hopefully globally . . . and there the confusion and inconsistencies begin. Lately I can't seem to get Safe installed. And all docs about editing some yaml stuff get me lost in the weeds quickly. What yaml where for my "global" situation? If you simply say to me, Don't try to work outside of the project--hs files--compile to executable framework I'll say okay, then have to decide whether I want to stay within the org-mode world or leave Haskell for an org-mode friendlier language. And no, lhs and jupyter are primitive compared to org-mode literate programming. Both are a step backwards. Any help on working outside the project box with stack, e.g., how to install and use packages (and even how to update/upgrade ghc and ghci would be a start!). - ⨽ Lawrence Bottorff Grand Marais, MN, USA borgauf(a)gmail.com

6 14

[ANN] hindley-milner-type-check-0.1.1.0 - type-checker for extended lambda-calculus
by Anton Kholomiov 08 Jun '21

08 Jun '21

I am happy to announce the first release of hindley-milner-type-check. It is generic type checker for lambda-calculus augmented with let-expressions, case-expressions pattern-matching and polymorphism. Library can report source code locations and returns the list of all errors if any. The library is generic in terms of source code locations, names for variables, literals of the language. You can find tutorials and examples in the github repo. Links: Hackage: https://hackage.haskell.org/package/hindley-milner-type-check Github: https://github.com/anton-k/hindley-milner-type-check Happy type-checking! Cheers, Anton

1 0

Re: [Haskell-cafe] [Haskell] [ANNOUNCE] GHC 8.10.5 released
by Zubin Duggal 06 Jun '21

06 Jun '21

The correct link to the release notes is: https://downloads.haskell.org/ghc/8.10.5/docs/html/users_guide/8.10.5-notes… (Note the missing tilde) Apolgies, Zubin

1 0

[Haskell] [ANNOUNCE] GHC 8.10.5 released
by Zubin Duggal 06 Jun '21

06 Jun '21

The GHC team is very pleased to announce the availability of GHC 8.10.5. Source and binary distributions are available at the [usual place](https://downloads.haskell.org/ghc/8.10.5/). This release adds native ARM/Darwin support, as well as bringing performance improvements and fixing numerous bugs of varying severity present in the 8.10 series: - First-class support for Apple M1 hardware using GHC's LLVM ARM backend - Fix a bug resulting in segmentation faults where code may be unloaded prematurely when using the parallel garbage collector (#19417) along with other bugs in the GC and linker (#19147, #19287) - Improve code layout fixing certain performance regressions (#18053) and other code generation bug fixes (#19645) - Bug fixes for signal handling when using the pthread itimer implementation. - Improvements to the specializer and simplifier reducing code size and and memory usage (#17151, #18923,#18140, #10421, #18282, #13253). - Fix a bug where typechecker plugins could be run with an inconsistent typechecker environment (#19191). - Fix a simplifier bug which lead to an exponential blow up and excessive memory usage in certain cases A complete list of bug fixes and improvements can be found in the release notes: [release notes](https://downloads.haskell.org/~ghc/8.10.5/docs/html/users_guide/8.10… As always, feel free to report any issues you encounter via [gitlab.haskell.org](https://gitlab.haskell.org/ghc/ghc/-/issues/new).

1 0

printf using values more than once
by Olaf Klinke 04 Jun '21

04 Jun '21

Dear Café, since the topic recently was rendering text, I'd like to ask a related design question. I want a version of printf that - is more type-safe because unused or surplus arguments cause compile-time errors, - the formatting instructions can use arguments out of order and more than once, - is polymorphic in the text type being built: Suppose I want to build a Pandoc Block but the holes are of type Inline. The format string must therefore be able to promote the Block type's constructors to constructors with holes. The closest match I know of is HoleyMonoid [1] but it only provides printf-like holes, whereas I need named positional arguments like arg1, arg2 etc. that can be repeated. Document templating libraries provide these, but all templating libraries I looked at are type-unsafe. In order to fulfill the second requirement, one could use the free monad over a Reader functor, e.g. Free ((->) (forall a. Show a => a)) String with some custom instances. Here one can use the nesting levels of the free monad to encode the argument position. But it is just as type-unsafe as printf. Funneling return type constructors through this works sort of, but it's awkward. One can achieve type saftey with type classes like printf does: class Eventually r a where eventually :: r -> a instance Eventually r r where eventually = id instance (Eventually r a) => Eventually r (b -> a) where eventually r = const (eventually r) This class can be used to inject constant Text into any nesting of (Text -> ... -> Text -> Text) and argument position is indeed function argument position. But using this system often leads to type ambiguity errors. Also, it is so type-safe that it is impossible to write a function taking a natural number and returning the hole of the corresponding position: Such a function would be dependently-typed. My current best implementation uses a combination of Eventually and HoleyMonoid, but I'm not entirely satisfied. Olaf [1] https://hackage.haskell.org/package/HoleyMonoid

3 3

[ANN] ttc-1.0.0.0 - Textual Type Classes
by Travis Cardwell 04 Jun '21

04 Jun '21

I am happy to announce the 1.0 release of TTC (Textual Type Classes). The library provides the following functionality: * The Textual type class is used to convert between common textual data types. It can be used to write functions that accept or return values of any of these textual data types. * The Render type class is used to render a value as text. Avoid bugs by only using Show for debugging/development purposes. * The Parse type class is used to parse a value from text. Unlike Read, it has support for error messages. * Validate constants at compile-time using Parse instances. Links: * GitHub: https://github.com/ExtremaIS/ttc-haskell * Hackage: https://hackage.haskell.org/package/ttc * Guided Tour: https://www.extrema.is/articles/ttc-textual-type-classes Best regards, Travis

4 10

Call for Tutorial, Panel, and Discussion Proposals: ICFP 2021
by Sam Tobin-Hochstadt 02 Jun '21

02 Jun '21

CALL FOR TUTORIAL, PANEL, AND DISCUSSION PROPOSALS ICFP 2020 25th ACM SIGPLAN International Conference on Functional Programming August 22 - 27, 2021 Virtual https://icfp21.sigplan.org/ The 25th ACM SIGPLAN International Conference on Functional Programming will be held virtually on August 22-27, 2021. 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". Just like last year, following the success of the #ShutDownPL event @ ICFP, 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 22 or August 26-27. ---------------------------------------------------------------------- Submission details Deadline for submission: June 28th, 2020 Notification of acceptance: July 5th, 2020 Prospective organizers of tutorials are invited to submit a completed tutorial proposal form in plain text format to the ICFP 2021 workshop co-chairs (Leonidas Lampropoulos and Zoe Paraskevopoulou), via email to icfp-workshops-2021(a)googlegroups.com by June 28th, 2021. Please note that this is a firm deadline. Organizers will be notified if their event proposal is accepted by July 5th, 2021. The proposal form is available at: http://www.icfpconference.org/icfp2021-files/icfp21-panel-form.txt http://www.icfpconference.org/icfp2021-files/icfp21-tutorials-form.txt ---------------------------------------------------------------------- Selection committee The proposals will be evaluated by a committee comprising the following members of the ICFP 2021 organizing committee. Tutorials Co-Chair: Zoe Paraskevopoulou (Northeastern) Tutorials Co-Chair: Leonidas Lampropoulos (University of Maryland) General Chair: Sukyoung Ryu (KAIST) Program Chair: Ron Garcia (University of British Columbia) ---------------------------------------------------------------------- Further information Any queries should be addressed to the tutorial co-chairs ( Leonidas Lampropoulos and Zoe Paraskevopoulou), via email to icfp-workshops-2021(a)googlegroups.com

1 0