With the introduction of Kotlin as a supported language, as well as the Arrow functional programming framework, building a functional web application with Spring has never been easier. More importantly, the conversion path from an Object Oriented Spring app to a Functional Programming Spring app can be accomplished with little risk and much reward.

Spring is the most widely used JVM web framework. For many years, the paradigm it has adopted has been object-oriented, stateful and imperative. This talk will show how to take such a codebase and refactor it into a functional programming style. It will show the benefits of this approach with regards to clarity, stability, safety and testability.

Elm is a functional language for the web that compiles to Javascript. As you would expect with any zero-dot version, the language is still settling done, and with

almost a year since the previous release there are a lot of changes, and many breaking ones. But one of the clear benefits of functional programming is ease of refactoring, so

Elm19 promises that most of the changes can be automatically applied to your program.

The notable new features in Elm19 are

• support for single-page apps and other explicit web content patterns
• even better (!) friendly compiler messages that guide rather than chide
• faster compilation, and smaller object sizes
• removal of some features like custom infix operators that are deemed more harmful than helpful

This talk will concentrate on how to be immediately productive with single-page apps in Elm, and digress briefly in how to migrate to Elm19 if you have not yet done so.

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.

With the proliferation of blockchain designs, we see a proliferation of proposals for languages and systems to script the rules governing transactions on these blockchains, generally known as smart contract languages. Despite the name, these languages are usually fairly conventional programming languages used to impose constraints on the transactions permitted to transfer assets and manipulate data stored on the blockchain.

Given the high financial stakes and widely publicised exploits on first generation (Bitcoin) and second generation (Ethereum) blockchains, the third-generation Cardano blockchain places a strong emphasis on functional programming and formal methods. This includes a new approach to contract languages based on state-of-the art research in programming languages and the increased safety provided by functional programming. The benefits of functional programming go even further: instead of having to invent yet another custom language, we simply use Haskell for the job, we design a functional blockchain architecture, and we seamlessly combine on-chain and off-chain computations.

In this talk, I will outline how IOHK’s Plutus team combines programming language theory, functional programming in Haskell, and theorem-proving in Agda to develop a radically new approach to blockchain contract development. This work has resulted in the Plutus Platform, which uses meta-programming in Haskell for distributed contract applications operating on the Cardano blockchain.

PREPARATION - A clone or copy of this repository https://github.com/qfpl/state-machine-testing-course/ and completion of the initial setup steps contained therein.

Types are great, but in most languages we use, they can't cover everything.
Testing tries to fill that gap. Property-based testing generates bizarre
examples and finds minimal reproductions that break your tests - a significant
improvement over writing test cases by hand. But what if you have a thorny
stateful system to test?

State Machine Testing extends property-based testing to randomly test stateful
systems. The actions performed against the system are modeled as commands, and
the usual property-based test machinery, generates test cases, and shrinks
failing tests to their minimal counter-examples.

In this workshop we will build on the earlier talk and begin building up a state-machine test suite for a small imperative system.

Types are great, but in most languages we use, they can't cover everything.
Testing tries to fill that gap. Property-based testing generates bizarre
examples and finds minimal reproductions that break your tests - a significant
improvement over writing test cases by hand. But what if you have a thorny
stateful system to test?

State Machine Testing extends property-based testing to randomly test stateful
systems. The actions performed against the system are modeled as commands, and
the usual property-based test machinery, generates test cases, and shrinks
failing tests to their minimal counter-examples.

In this talk we will provide a quick refresher (or crash-course) of
property-based testing, and then give an overview of 'property-based state
machine testing' and how it works. We'll then start a workshop where we begin
building up a state-machine test suite for a small imperative system.

The conventional wisdom in functional programming communities is that lambda calculus was "discovered". Extending the logic of the statement to its extreme, we might propose that an alien would recognize lambda calculus as a computational model. But would we be able to recognize an alien lambda calculus?

This talk is part gedankenexperiment, part speculative fiction, part practical advice on compiler design. We begin by imagining ourselves to be creatures in a universe which is very different from the one we're in, except the notion of consciousness and intelligence are preserved from our current universe. From there, we shall explore the physics and alternate philosophies that would yield an alien lambda calculus.

Of course, being from an alien conception, there are some questions that must be answered - in the name of practicality, is there perhaps even a weak notion of a functor from the alien lambda calculus to that of the one we know today? Is there anything from the alien lambda calculus that we may yield and put into practice? And what is this pesky business with state? Isn't the point of functional programming to hide states from the programmer by abstracting over them? Or was it to make clear the states? And what of names? Isn't lambda purely anonymous?

Apache Spark is one of the most popular data processing frameworks in the world, and is widely used in the enterprise. Its popularity is due in no small part to its adoption of the functional paradigm: it demonstrates the advantages of purity, higher-order functions and laziness to simplify the processing of large datasets. Haskell excels at all of those things; so it is only natural to think that Haskell would be a good fit for distributed data processing. Tweag.io's Sparkle and Soostone's Hadron are a few examples in the Haskell ecosystem.

'distributed-dataset'[1] is a framework written in Haskell designed to efficiently process large amount of data. With the StaticPointers extension of GHC Haskell, we are able to distribute a computation across different machines; and using the technique described by Matei et al[2] that led to Apache Spark, we can express and execute large scale data transforms using a pretty DSL.

In this talk, I am going to give a brief introduction to the library, and then move on to explaining the key implementation ideas and the advantages that Haskell offers to distributed data processing.

[1]: https://github.com/utdemir/distributed-dataset

[2]: "Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster Computing" by Matei Zaharia, et al.

Rust is a multi paradigm language with performance and safety as primary goals. Rust is strongly influenced by functional programming languages like ML, so it is possible to follow a functional coding style. In this talk I will explore the features of Rust that makes it a good choice for functional programming as well as its drawbacks. Following areas will be covered:

* Algebraic Data Types

* Pattern matching

* Brief overview on Ownership and Lifetimes in Rust

* Higher order functions and combinators

* An extended example that makes use of the above as well as slightly advanced topics.

In addition to the above the strengths and weakness of Rust as a functional programming language will be compared.

The Yoneda lemma is not the first thing to learn in category theory, but sooner or later it appears in studying the field. Unfortunately, there is quite a gap between the intuitive idea, "tell me your friends, and I will know who you are" , and its precise formulation. This talk aims to bridge this gap by introducing algebraic results in the middle, namely Cayley's theorem for groups and its generalization to semigroups. These are elementary enough, but at the same time they exhibit the conceptual step of representability, and the idea of studying all different things in a familiar form.

In conjunction with YOW! Lambda Jam, Compose::Melbourne will be running an all-day Hang Out And Hack session, on Monday May 13 - the same day as Lambda Jam Introductory Workshops. Bring your laptop if you have one, learn and work on Functional Programming. We'll run "office hours" (people can request help on particular topics, or offer to help others); lightning talks; and generally we'll hang out and hack together.

This is a free event, open to the whole Functional Programming community, beginners or experts, whether or not you are attending the main Lambda Jam conference on 14th & 15th.

Unlike the paid Workshops, the free Hang Out And Hack will not be catered so attendees will need to make their own arrangements for food; there are a number of places within the venue and surrounds, or feel free to BYO.

Please register for your free Hang out and Hack ticket, so we can get an idea of numbers and plan activities appropriately.

A quine is a program that outputs its own source code, but can you create a 2 quine, a pair of programs that output each other with an A->B->A->B cycle? What about between different languages? Can you gzip your own source code? Is there a structured way to do this with theory? All these questions will be somewhat answered, in ways that will make your head hurt... math-a-magical demos and over 9000 layers of meta-ness await!

Everything you ever wanted to know about starting a functional programming conference from scratch and some things you didn't. We'll cover the great times, the stressful times and all of the behind-the-scenes. Learn how we brought people together, how we chose talks and how we managed to create a community atmosphere enjoyed by both beginners and sages alike.

This workshop needs some pre-setup as I'll only have 5 thumbdrives with vms on them. It's around 3GiB to download with virtualbox/docker and about 700MiB with nix: https://github.com/qfpl/reflex-realworld-workshop/blob/master/SETUP.md.

Reflex-dom is a remarkably awesome way to write frontend web applications in Haskell. Reflex DOM is built from Functional Reactive Programming (FRP) primitives defined in a library called Reflex.

Writing apps in reflex-dom is a little weird at first because it's a whole brand new paradigm to structuring your programs. Just like the jump from imperative programming to FP, jumping into FRP is a tricky process of rewiring your brain to fit the new model of thinking. It can be very difficult to appreciate the power and architectures that you can from this transition while you are still learning the basics, which naturally makes it difficult to be motivated to put in the work.

In this workshop we will implement parts of the "real world demo", a demo blogging application designed as a way to test frontend frameworks with things like backend calls and frontend routing. There will be a lot of skeleton and example code already written and be very directed, so it's -- as with the talk -- it is going to be more getting a high level feel than learning all of the fundamentals. It is the hope that the fast paced guided intro will allow you to do the rest of the learning at your own pace later.

Reflex-dom is a remarkably awesome way to write frontend web applications in Haskell. Reflex DOM is built from Functional Reactive Programming (FRP) primitives defined in a library called Reflex.

Writing apps in reflex-dom is a little weird at first because it's a whole brand new paradigm to structuring your programs. Just like the jump from imperative programming to FP, jumping into FRP is a tricky process of rewiring your brain to fit the new model of thinking. It can be very difficult to appreciate the power and architectures that you can from this transition while you are still learning the basics, which naturally makes it difficult to be motivated to put in the work.

This talk intends to help break this deadlock by talking about some high level reflex architecture that should be very familiar to anyone who has built a Redux or Elm app before. We'll explore the mtl style constraints that reflex offers for state management and the awesome things that this means for your programs and ability to reason about the type signatures of your widgets. You won't come away from this talk an expert and ready to write a greenfield reflex app, but you should get an appreciation of the power reflex has to offer and a motivation to learn more!

In this talk I'm going to share key design decisions behind Haskell logging library called co-log.

This library combines multiple algebraic concepts in order to provide convenient and composable solution for the logging problem:

• Semigroup and Monoid
• Contravariant/Divisible/Decidable
• Comonads

I'm also going to show how we use this library in commercial Haskell projects.

Living in a statically typed world is great, but sometimes a part of your problem really does need to be modelled as something a bit more dynamic. Maybe something in your domain really should be modelled as a heterogenous collection. Maybe you just have a bunch of things you want to group together and work with via a common typeclass, but their types are all different. Maybe you're interfacing with a system that doesn't care about types. You might just want to feel the wind through your hair like when you were working with dynamically typed languages.

The dependent-map library (and friends) has you covered for all of these things. It gives you a heterogenous collection with great usability, where you use GADTs as the keys and have the "Functor Functor" pattern wrapped up in the mix for good measure.

This talk will start by looking at GADTs and the "Functor Functor" pattern to make sure everyone is on the same page, before spending some time getting to know the the details of DSum, DMap and friends. After that we'll spend some time looking at some of the additional things you can do using related libraries from the ecosystem, and then we'll spend the rest of the time looking at examples and applications.

Functions in the lambda calculus rightly take single values as their arguments, and return single values as their results. Functions in machine code rightly take multiple values as their arguments (preferably in registers), and return multiple values (preferably in registers) as their results. For a compiler writer, dealing with this mismatch is a right headache. Arity information, which describes how many arguments each source level function "actually" takes wafts through ones codebase like an unpleasant odour, and after particular compiler stages subverts ones once loved source-level type signatures into unfortunate lies.

Salt is a new compiler intermediate language that embraces uncurriedness as a first class condition, and whose type signatures speak the truth about arity. Functions are functions still, but their types are honest about the fact that no one really evaluates lambda expressions using capture avoiding substitution. The GHC core language tried to tell a similar story using unboxed tuples, but it didn't quite work. The C language stayed out in the sun for too long wondering what a void returning lambda abstraction really returned, and when we all came back to find it, the only thing left was Salt.

Language extensions are everywhere in the modern Haskell world. As beginners we are often told by instructors or the compiler itself to enable particular extensions to allow for some syntactic sugar or enable a common feature. If we continue to use Haskell, we likely come to depend on even more language extensions, until it is common place for the first 10 lines of each file to be language pragmas. Many of us, myself included, are probably guilty of enabling extensions without fully understanding what they do, or understanding what tradeoffs and risks they might present. This talk hopes to improve the situation by shedding some light on commonly used extensions.

We'll start with what language extensions are and why they exist. Next we'll consider the different ways they may be enabled. From there, we'll look at some of the simpler extensions that provide syntactic sugar and not much else --- for example, LambdaCase and TupleSections. At this point we'll start to ramp up and look at some heavier weight extensions (e.g. ScopedTypeVariables and GeneralizedNewtypeDeriving), their use cases, and their tradeoffs. Finally, we'll take a more detailed look at some language extensions related to type classes. Specifically; FlexibleInstances, FlexibleContexts, MultiParamTypeClasses, and FunctionalDependencies will be covered.

There are over 100 language extensions supported by GHC 8.6, so it is not my intention to cover all or even most of them. Instead, I hope to explain and demystify some common language extensions and point out that they are not without risks.

SETUP - Instructions for attendees to obtain the required libraries prior to the session are available from the workshop's GitHub page:

https://github.com/lancelet/space-workshop

There are also notes for the workshop, available from the same page.

In celebration of the 50th Anniversary year of the Apollo 11 moon landing, we present a spaceflight-themed exploration of numerical methods in Haskell!

This workshop focuses on both the joys and pain-points of intentionally using Haskell's abstraction capabilities for numerical work. We consider what approaches are available to make the time-domain simulation of dynamical systems safer. To do this, we solve practical problems by combining vector-spaces, units, linear, and several other libraries. The results are not always ergonomic (warning: may contain some horrible type errors), but we feel they help to demonstrate what is currently possible and motivate further development. Unlike many more theoretical presentations of this topic, our focus in this workshop is very much on solving real problems, selected from the published spaceflight literature.

Participants will use abstractions from the vector-spaces library, applied to numerical integration of ordinary differential equations (ODEs) and simple optimization algorithms. They will see how algorithms written using these abstractions are more generic, even allowing types with statically-checked units to be used with them.

On the spaceflight side, participants will implement some basic spacecraft manoeuvres, and we include some pre-baked simulations that interact with participants' code. Among the scenarios examined is a simulation of the lunar ascent phase of the Apollo missions, including a faithful transcription into Haskell of the actual guidance algorithm used during the lunar ascent (our Haskell version has statically-checked units!).

We encourage all forms of participation; from people who want to follow the prescribed set of problems, to those who may want to re-implement our examples in other languages, or just deep-dive into the spaceflight theory. All the problems have fallback solutions that can be examined or called directly.

We use types in programming, often without realizing how deeply rooted they are in the foundations of mathematics. There is a constant flow of ideas from type theory to programming (and back). We are familiar with algebraic data types; inductive types, like lists or trees; we've heard of dependent types and, in the future, we might encounter identity types and possibly get familiar with elements of homotopy type theory. I can't possibly talk about all of this, but I'll try to give you a little taste.

SETUP - You should have a basic understanding of Haskell (what data types, functions and type classes are) and have a working GHC installation. Clone and build these exercises

The default tool that many programmers immediately reach for when they wish to parse data (but don't want to deal with tools like Lex and Yacc) is regular expressions.

Of course, whenever you mention regular expressions, someone will bring up Jamie Zawinski. And now you have two problems.

However, regular expressions have many problems:

• They aren't composable
• They're typically represented as Strings rather than code making them harder to debug
• Often only interpreted at runtime leading to runtime failures (no static type checking!)
• They can't be used to parse HTML

The preferred approach in functional programming languages (also available in non-functional languages as well!) is parser combinators, which provide a way of writing your parser in code, thus being able to use all your existing tooling to do so.

In this workshop we will build up our own Parser Combinator library from scratch (and hopefully make sense of the dreaded M-word whilst we're at it!) and improve upon it, to see that there is nothing mystical about parsing in data.

Dependently typed programming languages have a more powerful type system, allowing types to impose arbitrarily complex constraints on the relationships between function inputs and outputs.

In this workshop, we will explore some theory of dependently typed programming, and then learn to use Idris, a dependently typed language, on a toy problem (proving that certain moves in the game Minesweeper are safe). We will then briefly look at an HTTP server written in Idris to learn how dependent types can be used to improve type safety in real world systems.

Trees That Grow *(Najd, Shayan and Peyton-Jones, Simon, 2016)* is proposed as a solution to a problem that regularly affects authors of deep and detailed algebraic structures. A data structure denoting a syntax tree for a programming language is typically very intricate and a small alteration deep in the tree can affect all siblings and parents of that tree. For example, adding a minor language feature to a syntax tree can have flow-on effects for the remainder of the tree. Classy lenses & prisms are a very powerful tool to overcome this common issue, which we will look at in this talk, but we will primarily look at another more recent proposal in Trees That Grow (TTG) to contrast and explore.

Although this general problem is canonically explained in terms of a programming language syntax tree (such as lambda calculus), we will also look at another application in aviation where TTG has been used to implement a flexible data structure tree in aviation documentation. The outcome of the talk is to provoke a discussion about this common programming problem, and the methods and trade-offs by which it might be overcome. TTG is also proposed as a solution to extending the Haskell programming language in the Glasgow Haskell Compiler (GHC).

Overall, the audience will get a good feel for the details of the problem that we are dealing with, then we explore some of the methods by which we can mitigate the problem, with an emphasis on gaining an understanding for Trees That Grow.

The term zipper is a colloquial used to describe n-hole (most often, 1-hole) contexts. That is, a data structure that has a _hole_ or _pointer_ focused on a specific element with the ability to efficiently traverse to its neighbouring elements, providing an elegant solution for the need to efficiently traverse and _modify_ immutable data structures.

In this workshop, we will look at examples of zippers for canonical data structures such as lists and other products and sums. We will then define comonads and see the relationship between zippers and comonads.

This workshop will be a brief talk on zippers, partial derivatives and comonads, followed by solve some code exercises to get an intuition for zippers.

Participants will need to bring a suitable laptop with Glasgow Haskell Compiler (GHC) installed.

Finally, for a fun and interesting observation, we will look at the algebraic structure of products and sums, then compute the derivative of these structures. Turns out, a derivative of a data structure is its zipper ("McBride, Conor, et al (2005). ∂ for Data: Differentiating Data Structures").

The Australian Security Exchange (ASX)'s CHESS[1] replacement[2] will be one of the most institutionally significant deployments of pure FP in the world. The CHESS settlement and registry system tracks the ownership of $1.5 trillion of the Australian economy on a daily basis. Its replacement is being developed by Digital Asset in DAML[3], and is due for completion in 2021.

Running on a distributed ledger technology (DLT), DAML is a smart contract language inspired by Haskell. It shares much of Haskell's pure core; however, it removes the infamous IO type, and instead provides a dedicated and restricted ledger-interaction type. This type, and the underlying ledger model it encapsulates, captures DAML's first-class control of authorisation and privacy.

This presentation introduces the DLT architecture style. It will explain the strengths and weaknesses of DLT, especially when modelling contractual workflows. It will demonstrate the use of DAML language to implement multi-party workflows that include authorisation and privacy requirements on the DLT platform developed by Digital Asset.

An attendee will come away with an understanding of how DLT is a distinct architectural style, a taste of DAML as a programming language, and an insight into the platform and language behind the highest profile functional programming project in Australia.

[1] CHESS: Clearing House Electronic Subregister System (https://www.asx.com.au/research/chess_brochure.pdf)

[2] https://www.asx.com.au/services/chess-replacement.htm

[3] Digital Asset Modelling Language (https://daml.com)

Elixir is an extremely accessible functional programming language that is rapidly gaining popularity for good reason. With it's well curated, batteries-included tool chain, excellent documentation and it's sheer simplicity, not to mention its incredible 30+ year Erlang heritage.

The goal of this workshop is to get you a basic familiarity with Elixir and the tools you'll need to be effective working in the language. It will be aimed at programmers who don't know Elixir, and don't necessarily know any functional programming.

The workshop is organised around a set of exercises that should take you through the basics of the language. Once you've got to grips with the language and tools you'll be ready to build a real time game server. In this workshop you'll learn everything you need to start building amazing, production ready Elixir applications

Many real-world lots-of-business-value-providing systems use a relational database. (Even more of them should!) Often, that database is used as a dumb data store – nothing more, logically, than an ACID-compliant coordinator of multiple flat files (tables). We send it basic queries – sometimes even joining multiple tables in one query! – inserts, updates and deletes. But nothing that might strain its little brain. Often, this is a mistake: a modern relational database is the most sophisticated data-munging tool in our toolkit!

We should consider doing more work in the database itself. But that's not easy to code well. How can we make our more complex SQL code easier to reason about, more reliable, and more testable? How can we make the overall system simpler?

These are questions that in not-the-database contexts, we solve with functional programming techniques. Without expecting SQL to out-lambda Haskell, are there techniques that we can borrow from functional programming and apply to improving our SQL?

What do programming, quantum physics, chemistry, neuroscience, systems biology, natural language parsing, causality, network theory, game theory, dynamical systems and database theory have in common?

As functional programmers, we know how useful category theory can be for our work - or perhaps how abstruse and distant it can seem. What is less well known is that applying category theory to the real world is an exciting field of study that has really taken off in just the last few years. It turns out that we share something big with other fields and industries - we want to make big things out of little things without everything going to hell! The key is compositionality, the central idea of category theory.

This talk will introduce the emerging field of applied category theory, with the aims of:

• Giving attendees a broad overview of cutting-edge applications of category theory
• Building an understanding of a small number of the most important core concepts
• Getting attendees excited, inspired to learn more, and equipped to apply some basic concepts to their work

The Brick terminal UI library provides a rich library of widgets for building console applications in Haskell. These include a list widget, which uses a packed vector type under the hood: a major problem when working with lists that are very large or expensive to compute.

In this case study I will review, step by step, how I generalised Brick's list widget to admit different underlying container types and achieved lazy loading of list items. The presentation will address several topics including:

• The advantages of more general (polymorphic) code, including parametricity
• Ensuring adequate test coverage before refactoring or generalising
• Maintaining backwards compatibility
• Assessing and documenting asymptotic performance
• Using Brick list widget in a real-world application (purebred MUA) for lazy loading where I/O is involved
• How to evaluate a lazy structure in the background (and why you might want to)
• Can we really achieve infinite scroll, or is my presentation title just clickbait?

Code examples will abound, and live demonstrations will both justify the work that was done, and show the pleasing results. The presentation uses Haskell exclusively but principles and advice for generalising code apply to many languages.

Relational databases provide a challenge for functional programmers: they're inherently mutable, but they're still the best choice for many applications due to their guarantees and performance. Fortunately, functional languages like Elixir - and the frameworks built around them - are re-inventing the way we do SQL, and the results are all positive. Join us and learn about Ecto, Elixir's answer to functional-relational data access. If you're sick of leaky abstractions, you'll love how it exposes the database for what it is. If you're building for the web, you'll love how its incorporation into the Phoenix web framework is modernizing web development. If you've had a bad experience with database abstractions in the past, you won't want to use anything else. Just don't call it an ORM.

PARTICIPANT PREPARATION:

Clone the repository at

https://github.com/plfa/plfa.github.io/

This is the textbook for the course.

Install Agda, the Agda standard library, and configure the plfa library. This can be done by following the instructions under the heading

Getting Started with PLFA

at

https://plfa.github.io/GettingStarted/

Outline:

This course is an introduction to formal methods in Agda, covering datatypes, recursion, structural induction, indexed datatypes, dependent functions, and induction over evidence; with focus on formal definitions of naturals, addition, and inequality, and their properties.

The textbook is freely available online:

• Programming Language Foundations in Agda
  plfa.inf.ed.ac.uk
  github.com/plfa/plfa.github.io/

The book has been used for teaching by me at:

• University of Edinburgh (Sep-Dec 2018)
• Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio) (Mar-Jul 2019)
• University of Padova (Jun 2019)

and by others at

• University of Vermont
• Google Seattle.

The book is described in a paper (of the same title) at the XXI
Brazilian Symposium on Formal Methods, 28--30 Nov 2018, which is
available here:

http://homepages.inf.ed.ac.uk/wadler/topics/agda.html#sbmf

The paper won the SBMF 2018 Best Paper Award, 1st Place.

The most profound connection between logic and computation is a pun. The doctrine of Propositions as Types asserts that propositions correspond to types, proofs to programs, and simplification of proofs to evaluation of programs. The proof of a conjunction is a pair, the proof of a disjunction is a case expression, and the proof of an implication is a lambda expression. Proof by induction is just programming by recursion.

Dependently-typed programming languages, such as Agda, exploit this pun. To prove properties of programming languages in Agda, all we need do is program a description of those languages Agda. Finding an abstruse mathematical proof becomes as simple and as fun as hacking a program. This talk introduces *Programming Language Foundations in Agda*, a new textbook that is also an executable Agda script---and also explains the role Agda is playing in IOHK's new cryptocurrency.

This talk looks at how functional programming has been used in tertiary education, and how it could be used in the future.
In 1985, Abelson and Sussman's course Structure and Interpretation of Computer Programs made enduring contributions to the art of educating programmers. How to Design Programs later refined some of these ideas, with a new emphasis on decomposing problems and designing solutions. I argue further improvements could be made. In particular, by using a typed functional programming language like Haskell.

This talk will suggest approaches and recommend resources that could be used in the modern education of undergraduate programmers. Such recommendations are also applicable to industry programmers looking to learn functional programming or organisations looking to develop internal training material.