Handling errors in a principled manner is an important aspect of writing production code. Drawing on our experience of writing production systems in Haskell, we believe that for a large class of problems, using the EitherT monad transformer is a simple and effective pattern to handle errors. We suggest that often, several mechanisms for error handling appear in code bases (including exceptions and the use of free monads) and that it will be of interest to intermediate Haskellers to see a principled approach that only uses EitherT to accomplish this.

It's hard coming back down to the earth of a JVM based language after spending time with Haskell and OCaml. The type systems are enviable, and the abstractions available are incredibly powerful.

Yallop and White's paper on Lightweight Higher-Kinded Polymorphism has been an inspiration for many libraries seeking to add functional abstractions to languages that don't support them. For Kotlin, one library is [Arrow](arrow-kt.io), which provides incredibly powerful abstractions over native language capabilities like co-routines, reactive-streams and nullable types.

This code jam will demonstrate functional programming in Kotlin with the Arrow library, how the abstractions it provides can improve your code, and how this magic that provides higher-kinded types works under the hood.

It's hard coming back down to the earth of a JVM based language after spending time with Haskell and OCaml. The type systems are enviable, and the abstractions available are incredibly powerful.

Yallop and White's paper on Lightweight Higher-Kinded Polymorphism has been an inspiration for many libraries seeking to add functional abstractions to languages that don't support them. For Kotlin, one library is [Arrow](arrow-kt.io), which provides incredibly powerful abstractions over native language capabilities like co-routines, reactive-streams and nullable types.

This talk will discuss functional programming in Kotlin with the Arrow library, how the abstractions it provides can improve your code, and how this magic that provides higher-kinded types works under the hood.

Transducers -- composable algorithmic transformation decoupled from input or output sources -- are Clojure’s take on data transformation. In this talk we will look at what makes a transducer; push their composability to the limit chasing the panacea of building complex single-pass transformations out of reusable components (eg. calculating a bunch of descriptive statistics like sum, sum of squares, mean, variance, ... in a single pass without resorting to a spaghetti ball fold); explore how the fact they are decoupled from input and output traversal opens up some interesting possibilities as they can be made to work in both online and batch settings; all drawing from practical examples of using Clojure to analize “awkward-size” data.

Functional programmers are lovers of simplicity and order. Developing for the Web has become nothing like either of these. The number of tools and libraries you need to learn seems to multiply without end, and getting them to work together can be a nightmare.

What if there was a language and environment that had no external dependencies, required no complex packaging tools, runs in the web browser, and oh yes, it's purely Functional.

The Elm Architecture (consisting of the Elm functional language, and a way of applying it to web development) aims to allow fast iterative development of beautiful web apps in a functional language. Hundreds of easy-to-install libraries give you

Most elm tutorials stop at the "hello world" level and sweep the complexity of large applications under the carpet. This presentation goes beyond the bare essentials to show you how my team builds real world applications in Elm that incorporate non-elm javascript libraries while still retaining as much of possible of the simplicity, type-safety and ease of refactoring that Elm brings.

Ports are Elm's mechanism for interaction with the non-functional, loosely typed Javascript runtime. I'll show you practical ways to interact with tools such as Amazon Cognito and the Leaflet mapping engine from within your Elm application, keeping the non-functional glue code to the barest minimum.

Functional programming has become inevitable. New programming languages draw inspiration from the functional paradigm; old programming languages retrofit support for functional programming; and development teams change their coding style to adopt the best functional programming idioms. We are clearly experiencing a paradigm shift in our industry.

Due to its academic roots, functional programming sometimes seems unapproachable, with unfamiliar jargon, obscure concepts, and bewildering theories. It doesn’t have to be like that.

In this one-day series of lectures and hands-on workshops, we will translate the jargon, demystify the concepts, and put the theories into practice. There is nothing inherently difficult about functional programming. In fact, its main aim is to simplify programming and to make it more widely accessible. Functional programming is about being able to understand one function without the million lines of code it is a part of. It is about code reuse. It is about modularity and keeping code easy to change and refactor. These are all goals of good program design that every developer appreciates. Based on this common ground, we will explore functional programming together and see how it can help us to achieve these design goals. In fact, by learning the fundamentals of functional programming in Haskell, we can improve program design in mainstream languages, such as Javascript and C++, and even more so, in hybrid languages, such as Scala and Swift.

Throughout the day, we will explain the most commonly used functional programming terminology. You will learn the fundamentals of Haskell, one of the most popular functional programming languages. In the process, we will look at a lot of concrete code to understand what functional programming is all about and how to use it in your own programs. In the workshops, you will have plenty of opportunity to write code yourself, experiment, and ask questions. It’ll be fun!

Bring your laptop and your curiosity and by the end of the day, functional programming will be another tool in your toolbox, and you will be ready to enjoy the main YOW! Lambda Jam conference.

Category theory can be thought of as being "very abstract algebra". It is thought of as "too abstract" by some people, and as "abstract nonsense" by some others. In this talk I will show that while it is abstract, it is far from being nonsense. I will argue that the abstraction has a purpose and that broad applicability is one of the powerful consequences. To demonstrate this, I will show how I apply concepts of category theory to important questions of life such as prejudice, privilege, blame and responsibility. I will introduce the category theory concepts from scratch so no prior knowledge is needed. These concepts will include objects and morphisms, isomorphisms and universal properties.

There are often two barriers to entry for those who have heard that they "should" look at some category theory. One is the motivation: why is something so abstract going to be helpful? The other is technical: many introductory texts assume a large amount of mathematical knowledge in avance. My keynote talk addresses the first issue and this workshop will address the second. We will introduce some of the basic concepts of category theory without using other mathematical structures as examples. We will cover categories and functors and will also take requests.

Elixir is a functional language that's growing in popularity as a stepping stone into functional programming, thanks to its strengths in areas like concurrency, fault tolerance and scalability combined with a syntax that is simple to learn, and feels very familiar for those with experience of languages like Ruby or Python. However, it is a very different beast – a functional style, new tools, and Erlang and Elixir libraries to learn, and while many people are experimenting with it, it's not quite mainstream for apps in the wild yet.

Our Elixir journey began around two years ago, when we started breaking out parts of our monolith and rebuilding it as microservices in Elixir. It was a chance to introduce boundaries, and consider performance from the ground up for an application for which performance was starting to become a concern as the customer base was growing. This talk will tell the story of a journey into a new, functional language and discuss how we approached decisions around where to start breaking the monolith apart.

The talk will also cover some of the lessons we learned, including:
- How Elixir’s functional style made us think differently about writing code in other languages
- Moving from ExUnit to Espec and back again
- Tools such as umbrella apps that helped us to work with a group of Elixir microservices
- How we planned for performance from the beginning, and Elixir features that helped us with this such as GenServer
- Deployment strategies for the Elixir applications
- How the migration impacted different team members including front end developers

In functional programming one might hear about the abstract algebraic concept of semigroups, at least about monoids in the context of category theory. Still, semigroups may seem as esoteric mathematical objects, although they are at the very foundation of computation.

In this talk we give an elementary definition of semigroups. As a concrete example we introduce transformation semigroups, and we show that they are natural generalizations of finite automata. This in turn leads to morphic relations (the algebraic notion of emulation) and thus to a mathematical definition of computers. Abstract algebra provides a precise language to talk about computers and programming.

The bad news is that semigroup theory is a relatively young field of mathematics, and it is full of open problems. The questions are hard, therefore we need to use computers to work on those. Somewhat ironically we can say that we use computers to understand computers. In order to show how FP helps in research, we will talk about a couple of software packages written in Clojure and GAP (a hybrid OO-FP computer algebra system) for computing with semigroups.

`hpython` is a Haskell library implementing a parser, printer, and
syntax tree for Python, written to allow easy validation and refactoring of complete Python programs.

As examples, we will look at functions which:

* Replace tabs with spaces
* Fix mutable default arguments, and
* Turn tail recursion into loops

These functions can also be composed, so a user can mix and match refactor-functions,
or write their own.

The library wasn't always like this, though. We've had ups and downs, and actually ended
up throwing out the entire previous design, which was months old at that point. I'm going
to share this journey: how the project goals evolved, failures and successes, and the lessons
I learned along the way. Key points include:

* The real-world value of property testing
* The shortcomings of advanced type-level techniques and compiler-enforced correctness
* The difference between "making it difficult to do the wrong thing" vs. "making it easy to do the right thing"

Cursive is an IDE for Clojure, based on the IntelliJ framework. In contrast to the majority of Clojure development environments, Cursive uses static analysis of the source code to work its magic rather than using runtime inspection of a live system via the REPL. IntelliJ provides a sophisticated indexing infrastructure, and this in combination with static analysis allows many interesting features which are difficult or impossible to achieve with a traditional REPL-based environment. Essential code navigation tools such as Find Usages and refactorings such as Rename become possible, and using IntelliJ's code inspections can provide error marking and static analysis of code, right in the editor. This ability to see problems immediately provides an even shorter feedback loop than working in the REPL.

I'll discuss some of the challenges of developing a traditional IDE for a language as flexible as Clojure, including the implementation details of how to deal with syntax extensions from macros. I'll also talk about the various ups and downs of developing much of it in Clojure, and why some of it is also developed in Kotlin. I'll also talk about why I believe our editors should be syntax aware, not just text based.

I've been writing Haskell at Arbor Networks for about a year now, and while there are certainly a ton of benefits on the technical side, and a lot of interesting concepts, some of the most profound (and least discussed) impacts of Haskell occur on the personal and team levels.

This is a talk about what I've learned about the human side of Haskell over the passed year. It touches on

• How it makes it easier to think through problems and express yourself.
• How it facilitates clear communication within teams.
• How it allows for more agile decision making.
• How it makes good practices the easy and natural thing to do
• Some of the challenges and negative impacts it has.

It may be of interest to anyone curious about what Haskell is like as a full-time, production language at a commercial company, or to people who are interested in a viewpoint beyond or other than a technical one.

Time has a profound impact on the complexity of the systems we build.

A significant amount of this software complexity comes from either an
inability to recall previous states or the inability to understand
how a state was arrived at.

From the foundations of AI, LISP and functional programming [1], to
causality in distributed systems [2], to the more grungy practices of
immutable infrastructure, or the unreasonable effectiveness of
fact-based approaches to large scale data systems; the ability to
adequately cope with time, and the change and conflict it inevitable
creates, is a common thread to being able to build and reason about
these systems.

This talk looks at the impact of time on system design. We will walk
through examples of large-scale systems and their battles with
complexity. At the end of the talk, the audience should start to see
the common spectre of time and have an appreciation of how
understanding time is fundamental to maintaining clarity, correctness
and reliability in systems.

[1] Situations, Actions, and Causal Laws
John McCarthy
http://www.dtic.mil/dtic/tr/fulltext/u2/785031.pdf
[2] Times, Clocks and the Ordering of Events in a Distributed System
Leslie Lamport
https://amturing.acm.org/p558-lamport.pdf

Programming generative art, also known as creative coding, is often a trial-and-error process, combining creativity and logic to present something aesthetic. However, creative coding has a high barrier to entry due to the breadth of knowledge and coding skills required. This talk aims to lower that barrier for you to take home and practice creative coding.

In this talk, you will learn about algorithms and techniques for generative art using a pure functional paradigm. First, shepherding random numbers to simulate the universality of nature patterns that appear in plants, rocks, sand, and smoke. Next, using L-system formal grammar to create a seemingly infinite, but well-structured, series of graphics. Lastly, interfacing with printers to bring your drawing to life.

For you to get the most out of this talk, you should be comfortable working in a functional language of your choice. Although I will introduce some theory, background in mathematics and formal theory is not required to attend.

Have you ever been puzzled by the suggestion that

data Lens s a = Lens { get :: s -> a, set :: a -> s -> s }

might be in some sense the same as

forall f. Functor f => (a -> f a) -> s -> f s/code>

or, more to the point, how on earth someone ever went about figuring this out in the first place?
Don't know your Kan extensions from your co-ends, your pushouts from your presheaves?

Join me for a scenic adventure tour through the magical land of category theory, stopping off at all the major sights.

We'll learn the basic notions that form the conceptual backbone of category theory,
and how they all fit together.

Category theory has made deep inroads into computer science theory, but in this talk we'll be focused on computer science practice. We'll explore the advantages category theory brings to programming in terms of

• providing alternate representations for types
• classifying solutions, or
• simply providing a clarifying viewpoint and helping to organise our thinking.

In addition this should provide you with the right framework for further exploring category theory, should you so wish.

This hands-on, code-centric session teaches attendees how effectful functional programming can be used to tackle the often messy, IO-heavy problems found in industry. We will use the Scala Eff monad library to incrementally build and extend a directory scanner.

Participants without any previous background in Eff or effectful FP have a smooth on-ramp. A series of refactoring exercises incrementally transforms an imperative program into a purely functional, effectful programming, introducing the Eff API along the way:

• The Async effect to model asynchronous requests
• Using Either effects for error handling
• Using Reader effects for dependency injection
• Writer effects for logging

For those with previous Eff experience, or have done my Eff workshop at Lambdajam 2017, there are new exercises that dig deeper into Eff:

• Programming stateful systems with the State effect
• Combining effects and functional optics
• Two different approaches to side-effects: catch-all IO vs focussed effect DSLs

The Eff library is an implementation of Extensible Effects in Scala, developed by Eric Torreborre. It is inspired by Oleg Kiselyov’s Haskell paper ‘Freer Monads, More Extensible Effects’ . Like Monad Transformer stacks and the Free monad, it provides an organising principle for the construction of pure functional programs.

Materials are available at benhutchison Getting Work Done With Extensible Effect. Solutions are included for all exercises.

The usage of Free Monads is becoming more well understood, however the lesser known Free Applicative is still somewhat of a mystery to the average functional programmer. In this talk I will explain how you can combine the power of both these constructs in an intuitive and visual manner. You will learn the motivations for using Free Structures in the first place, how we can build up a complex domain, how we can introduce parallelism into our domain and a bunch of other practical tips for designing programs with these structures. This will also give you a deeper understanding of what libraries like Freestyle are doing under the hood and why it is so powerful.

In this talk, we discuss the design and implementation of "Flax", a purely functional wrapper around the Selenium web testing library. Flax is written in Scala and allows you to create web tests within an "Action" Monad. By making use of Scala's for-comprehensions, Flax tests read like a set of test instructions, but with the benefits of a functional approach.

The talk describes Flax's Action Monad in detail, showing how it is a stack of Either, Reader, Writer and Task. Each of these effects has a specific purpose in Flax's use as a tool for constructing browser-based tests.

Initially, in Flax, we wanted to just do something quick-and-dirty - FP is nice, but for a testing library, do we really need it? However, a number of design problems quickly arose. We'll talk about these issues and how we realized that the purely functional approach was the only sensible way forward.

A key problem we encountered with the functional approach was that we no longer able to use stack traces to identify where a test failed. To address this, we used the Writer Monad to track the actions performed. The actions are tracked as a tree of operations, which lets us group higher-level actions as a tree of lower-level actions. This is particularly useful for structuring browser tests, as often a specification of desired behavior can translate into a long sequence of individual steps.

Property discovery is the process of discovering properties of code via
automated testing. It has the potential to be a great tool for a practical
approach to software correctness. Unfortunately current methods remain
infeasible because of the immense search space. We contribute a new
approach to taming the complexity of a state-of-the-art generate and test
algorithm. Our approach runs this algorithm several times with carefully
chosen inputs of smaller size: signature inference. We implement this
approach in a new tool called EasySpec. The results suggest that this
approach is several orders of magnitude faster, fast enough to be practical,
and produces similar results.

Back in the 80's, one approach to compiling functional programming languages was to compile down to combinators such as SKI. John Hughes' initial work on supercombinators changed the way folks thought about compiling functional languages and caused folks to turn away from this approach by customizing the combinator set to your particular program. Then Lennart Augustsson's work on implementing supercombinators more efficiently sealed the deal. GHC's compilation technique is a descendant of this school of thought.

But what did we give up to get to where we are? Let's explore a bit of alternate history.

There has been a lot of excitement about Functional Reactive Programming (FRP).

Most of it has been about distant relatives of the original idea, which are nowhere near as powerful or as useful.

The `reflex` library -- and the companion `reflex-dom` library -- were created in order to use FRP to do front-end development using Haskell.

This workshop will give you hands-on experience with these libraries.

The workshop will show attendees a new way to manage state and time-dependent logic, with significant benefits over the standard approaches when it comes to abstraction, composition and correctness.

It will also make the case that when these ideas are applied to front-end development, they lead to something beyond what is delivered by libraries like `react` and `redux`.

My team works on Atlassian Marketplace, a project which started 10 years ago and uses Scala, Haskell and Nix. The Marketplace code uses concepts such as applicative functors, monad transformers and lenses. People joining the team mostly learned concepts as they needed to, through experimentation and asking questions.

Last year we started hosting functional programming classes for more fundamental and broad understanding. We've been using the Data61 (formerly NICTA) Functional Programming Course with a lot of success. This talk will describe how we teach FP, what we've learned about teaching FP and the challenges we face.

Automated testing is key to ensuring the ongoing health and well being of any software project, giving developers and users confidence that their software works as intended. Property based testing is a significant step forward compared to traditional unit tests, exercising code with randomly generated inputs to ensure that key properties hold. However, both of these techniques tend to be used at the level of individual functions. Many important properties of an application only appear at a higher level, and depend on the state of the application under test. The Haskell library hedgehog, a relative newcomer to the property based testing world, includes facilities for property-based state machine testing, giving developers a foundation on which to build these more complicated tests.

In this talk, Andrew will give you an introduction to state machine property testing using hedgehog.He'll start with a quick refresher on property based testing, followed by a brief introduction to state machines and the sorts of applications they can be used to model. From there, he'll take you on a guided tour of hedgehog's state machine testing facilities. Finally, Andrew will present a series of examples to show off what you can do and hopefully give you enough ideas to start applying this tool to your own projects. The application being tested will be a servant web application, and examples will include testing fundamentals such as content creation and deletion, uniqueness constraints, and authentication.

An intermediate knowledge of Haskell and familiarity with property based testing will be beneficial,but not essential. The slides and demo application will be available after the talk for people to study in detail.

Many people are familiar with Haskell stream processing libraries such as pipes or conduit. However, they can be a bit daunting to newcomers: they contain both input and output types in the same representation and they require all these new operators rather than using well-known function composition.

The streaming library by Michael Thompson takes a simpler approach to represent how to stream data through your code. It offers a more familiar API to anyone used to using lists, whilst still offering a lot of power and flexibility. It also compares very well in terms of performance: conduit's fusion framework tends to use a similar structure!

In this workshop we will have an overview of the streaming ecosystem and how it compares to pipes and conduit, and start using it to efficiently process large amounts of data.

If attending this workshop, you may wish to download the exercises (and fetch any dependencies) beforehand.

Let's Lens presents a series of exercises, in a similar format to the Data61 functional programming course material. The subject of the exercises is around the concept of lenses, initially proposed by Foster et al., to solve the view-update problem of relational databases.

The theories around lenses have been advanced significantly in recent years, resulting in a library, implemented in Haskell, called lens.

This workshop will take you through the basic definition of the lens data structure and its related structures such as traversals and prisms. Following this we implement some of the low-level lens library, then go on to discuss and solve a practical problem that uses all of these structures.

Elm, for a long time the flag bearer of Functional Reactive Programming on the web, recently switched to a simpler pure functional architecture, citing 'ease of use'. Those of us that have worked on complex reactive mobile apps can sympathise with this - using FRP injudiciously in your app can make the code difficult to understand and near impossible for new developers to pick up.

So are we able to apply some of the techniques and patterns from Elm into iOS apps? It turns out the Elm architecture is a really great fit for Swift & iOS - it allows us to:

• reserve our FRP hammer for the use cases that make the most sense
• separate out a simple, consistent, and highly testable pure functional core, and
• provide a flexible, yet easily understood & applied set of architectural building blocks.

This session will cover the basics of implementing and using an Elm-style architecture in a Swift app, will include lessons learnt in a real-world implementation, pitfalls/benefits, and implementation considerations should you adopt the approach in your own app.

Functional programming is wonderful, but what happens after we're done writing code (functionally) and we need to put it in production? The most popular solution is to write a shell script that manually performs the work of installing dependencies, configuring the target, and running our software. This approach is hopelessly imperative and lacks reproducibility, immutability, and simplicity, things we otherwise take for granted. Can we do better?

The Nix package manager and ecosystem brings the functional programming approach to bear on the the problems of installing, configuring, maintaining, and upgrading software, and allows your development and operations teams to realise the promise of functional programming to move faster, break nothing, and sleep better at night.

In this workshop I'll walk you through the process of making your first functional deployment and effectively dealing with change. I hope that after this you will be inspired to take a closer look at Nix and see what it can do for you and your team!

Git is the most widely used version control tool today, but what is actually happening when we perform a `git add` or a `git commit`? To answer this question I'm going to walk through a small implementation of Git in Haskell. Along the way we'll touch on functional data structures, content-addressable stores, and parser combinators. At the end we'll analyse an entire Git repository and talk about the practical applications and limitations of what we've built. My hope is that this knowledge will help you be less frustrated the next time you see a cryptic Git error message!

Three years ago, I quit my job to bet everything on the proposition that Haskell could excel not just for specialized, high-assurance software, but for the kinds of software that millions of engineers work on every day. I had previously built backends with Haskell, with the wonderful experience of code that works reliably, a team that doesn't step on each others' toes, and an ease of refactoring that let us keep the codebase clean without risking regressions. But now, GHCJS and FRP had finally become reliable enough to trust in the real world. It was a game changer: Haskell could now build world-class graphical user interfaces, too, and deploy them as single page web apps — in theory.

In practice, there were many obstacles along the way. However, I found that even with the need to blaze new trails from time to time, our overall pace was far faster than anything I had seen in the imperative tech stacks I'd worked with before. Strong types and pure values decreased bug counts and made code much more readable. Some former backend developers who had scrupulously avoided frontend development told me that they now enjoyed working on the frontend, too.

Since then, I've worked with the community to continue building infrastructure to expand the areas where we can use Haskell to get real work done. Enabling mobile development required bug fixes to GHC, a rearchitected approach to cross-compilation in Nixpkgs, and bindings to native APIs. To scale up to larger projects, we've improved existing tools and created new tools that make developer workflows simpler, faster, and more discoverable. And to make Haskell app development more accessible to beginners and professionals without Haskell experience, we've made more and more functionality available out of the box.

In this talk, I'll show you the tools that are available today and the challenges that lie ahead. I hope you'll come away with a broadened understanding of how Haskell can be applied in your own professional projects — and how the theory of functional programming can be a potent practical tool.

Haskell has a powerful foreign function interface (FFI) for interfacing with C libraries. Haskell is a great language for building libraries and tools, but interoperability requirements or time constraints can make the FFI a compelling option.

Binding to a non-trivial C library presents several challenges including C idioms, memory management, error handling and more. This presentation will address a selection of these concerns, using hs-notmuch, a binding to the notmuch mail indexer, as a case study. We will discuss:

• FFI basics and tools to assist binding authors
• working with "double pointer"-style constructors
• working with iterators; how to do lazy iteration
• how to use Haskell's garbage collector to manage lifecycles of external objects, and "gotchas" encountered
• using types to enforce correct use of unsafe APIs
• performance considerations (including profiling results)

The presentation will conclude with a mention of some important FFI concepts that were not covered (e.g. callbacks) and a look at how hs-notmuch is being used in the Real World.

Developers familiar with C will get the most out of this talk (because there will be limited time to explain C idioms, memory management, etc). To varying degrees, most of the concepts and techniques discussed will apply to other languages' FFIs.

Increasingly, people are popping up stating the controversial opinion that names don't matter. To most programmers this statement is obviously untrue, as naming is seen as difficult, and critical to semantic expression and communication in their code. To make matters worse, these same people demand fidelity to obscure and difficult names from mathematics, leading to charges of hypocrisy – if names don't matter, why do they care we all use any particular ones?

We'll try and tease out these seeming contradictions. We'll look at why "names don't matter" is an important idea, and why its more obvious superficial interpretation is specious.

Since their introduction, Applicative and its sidekick Alternative have become ubiquitous and beloved type classes in Haskell and similar languages such as Purescript. By contrast, their contravariant counterparts are relatively unknown. These contravariant structures are useful, and their time has come!

In this talk, we will learn about Contravariant, and its subclasses Divisible and Decidable. How do they work? How do they relate to the classes we know? Are they useful? For what? This talks aims to demystify these classes in an approachable way, by demonstrating their use with practical motivating examples.

From CSV, to JSON, to YAML, DER, and the dreaded XML, many programmers are dealing with data formats all day. In statically-typed languages like Haskell, we can get a great benefit by imposing a rigid structure of types on the data we consume from these formats. We call this process of imposing structure on data "decoding".

Decoding libraries are available in many languages and for many formats. This talk explores the design decisions behind a new Haskell library, sv, which decodes CSV and similar formats such as PSV. sv addresses what we perceived as problems with other libraries. We will discuss the benefits and drawbacks of the interesting or noteworthy choices made in sv's philosophy and design, and make recommendations as to how these lessons could be applied to other formats.

Recursion is used extensively in functional programming. It is indeed iteration through nested data structures. Therefore patterns are identified to generalise the nested structure iteration. Using these patterns can factor out the recursion mechanism from application specific logic for code simplicity. That's the purpose of recursion scheme.

This talk points out different recursion problems are having similar patterns. The recursion scheme is introduced to support these patterns. It will discuss how the common iteration mechanics is separated from the application specific logic by using the patterns, aka morphisms, provided by the recursion scheme. The fundamental pattern, catamorphism, and a few other commonly-used morphisms will be illustrated with some recursion examples.

The aim of the talk is to give audience an idea of how recursion can be implemented in simple and elegant ways by applying the various morphisms provided by the recursion schemes.