Friday, September 10, 2021
The talk is about architecture, UI and UX of https://hackage.haskell.org/package/tasty-bench, which is a new benchmark framework with an API mimicking `criterion` and `gauge`. Despite its young age, `tasty-bench` has been adopted by such packages as `bytestring`, `text`, `random`, `vector` and `pandoc`. A prominent feature is built-in comparison against previous runs and between benchmarks. Tight integration with `tasty` framework allows to create automatic performance regression test suite. `Test.Tasty.Bench` is just a single source file and does not incur any non-boot dependencies except `tasty`, so compilation is up to 16x faster than `criterion` and up to 8x faster than `gauge`.
The great thing about Clash is that it is just Haskell. In this talk, we explore *why* this is great, by showing a simple hardware circuit developed using high-level Haskell abstractions:
* Separation of model and presentation * `State` with lenses for composable model updates * Type-directed and type-level programming
The result is idiomatic Haskell code that can be viewed in multiple ways:
* We can compile it as software Haskell, yielding an interactive simulation, i.e. a playable Pong game.
* We can compile it as hardware Haskell, yielding an FPGA configuration that can be hooked up to two pushbuttons and a VGA screen.
Pipelining is a latency hiding technique commonly used in various systems including network applications or processor architecture. I will present a new approach to protocol pipelining in our typed-protocols package. Typed-protocols is an implementation of binary session types in terms of an initial deep encoding. For performance reasons we provide pipelining, which however depends on concurrency and though an elegant solution it restricts the way some application has to be written. I will present how to design pipelining in a typed correct way without these limitations, at an expense of advanced type level programming. The talk will be illustrated by two simple ping-pong protocols. I will also present a proof that client and server applications, whether using pipelining or not, build with the framework are always dual to each other (hence communicate without deadlocks), and if they terminate they terminate at a common terminal state.
Why use Haskell to create real life web apps?
To answer that question I’ll talk about - Haskell is great but not magic, just an ordinary programming language (and that is a good thing) - My productivity is more important than the language I use - What is Knowledge-as-code and why is that the reason why chose Haskell? - Business advantages of using Haskell
The tech sector has extremely low rates of labor organization, but that is slowly starting to change. From Google, to the Tech Times Guild, to Kickstarter, to Mapbox, tech sector organizing is increasingly feasible. This talk will explain why we should care, why we should support this, and how it matters not just to the quality of our lives and working conditions, but the quality and reliability, and ultimately trustworthiness of the systems we produce and maintain.
Alpha-equivalence and capture-avoiding substitution are two fundamental operations in the implementation of the lambda calculus. But, what is the best way to implement these operations in Haskell? I wish I knew.
In this talk, which is part tutorial and part work-in-progress, I'll present what I have learned from gathering many, many implementations of these operations into the same repository and comparing their execution using a small benchmark suite.
One observation to make is that that most of these implementations of capture-avoiding substitution require multiple traversals of the AST, which can lead to a significant slowdown on larger examples. However, by reifying, delaying, and fusing these traversals, we can dramatically improve performance. Not only that, but I will also show how this optimization can be invisibly incorporated into binding libraries that automatically provide capture-avoiding substitution "for free".
Link to benchmark repository: https://github.com/sweirich/lambda-n-ways
Competitive programming is an exciting mind sport where competitors race to solve difficult programming tasks as quickly as possible, either individually or as part of a team. It requires sharp problem-solving skills, broad knowledge of algorithms and data structures, and (often) developing a good library of reusable code components ahead of time. Most serious competitive programmers use C++, but this is an arena where Haskell can shine: Haskell's strong type system helps prevent stupid mistakes made in the heat of the moment, and its capability for abstraction allows us to develop versatile libraries and solve problems using a minimum of boilerplate. In this talk, I will livecode a solution to a representative challenge, showing off techniques and libraries along the way.
I will also highlight some areas needing work. In some cases, in order to fit within the time limit imposed by the creators of a problem, it is necessary to write code that runs within a small constant multiple of the time taken by a C++ solution. This is possible but difficult; the name of the game is to create libraries of algorithms and data structures that are highly optimized internally but present a flexible and idiomatic interface suitable for use in a contest.
I hope that Haskellers of all skill levels will be able to take away something new, and that some will be convinced to take up a new hobby, or contribute some code!
Functional programming is full of “folk tricks” that seem inscrutable to novices. Many of them can be traced back to John Reynolds, who showed us how to use continuation-passing style and defunctionalization to transform a recursive interpreter for a language into an abstract machine for programs in that language. The same techniques explain zippers and accumulating parameters. Buried within all those applications there is usually a hidden appeal to the algebraic property of associativity. In this talk, I will entice associativity out of the shadows and into the limelight.
This talk is a deep-dive on the Alternative typeclass from `Control.Applicative`, which provides a monoid over applicative functors, we love monoids, and we love applicatives, what do we get when we combine the two?
We'll start off by exploring the typeclass and its laws by showing off some helpful examples, and develop some intuition at the same time. Next we'll look at a few examples of several unique instances of Alternative: lists, parsers, routing, MaybeT, STM and more!
Scattered throughout we'll learn some fun and unexpected uses of combinators and how they interact in ways that are unexpected but are still useful. Did you know that parser combinators double as useful concurrency primitives!?
Choosing fingerings for violin music is a hard problem, both for humans and computers. Though there is a great deal of pedagogical literature by famed teachers and performers on the subject, most violinists wind up developing the skill of picking a fingering only through years of study and trial and error. Besides being a hard problem, choosing fingerings is one with no agreed upon optimal solution. What distinguishes a good fingering from a bad one is highly individualized to a specific musician's tastes.
[OpenStrings](https://open-strings.com) is an expert-system style inference engine written in Haskell for fingerings with configurable rules to account for the individual preferences of the user. Evaluation by expert violinists of the generated fingerings has concluded that the results are competitive with human generated fingerings. The app makes use of many Haskell techniques, from TemplateHaskell routing with Yesod to dark lens magic for processing MusicXML.