Functional Modelling of Contractual Workflows in DAML
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)
Outline/Structure of the Talk
Introduction to Digital Ledger Technology as an Architectural Style (5-min)
Introduction to DAML as a Contractual Workflow Language & DAML Modeling (5-min)
DAML Coding Examples (15-min)
Questions (5-min)
Learning Outcome
- How DLT is a distinct architectural style
- A taste of DAML as a programming language
- An understanding of the nature of multi-party authorization and privacy challenges imposed by contractual workflows, and how DLT and DAML assists in solving them
Target Audience
Anyone interested in the technology behind a world-first, large-scale, Australian FP project
Prerequisites for Attendees
The introduction to the DLT Architectural Style will try not to assume any specific background.
The DAML and contractual workflow discussions will assume a basic familiarity with the concept of legal contracts and basic contract formation.
Coding examples will assume a basic familiarity with Haskell syntax and introductory concepts (Monad, Functor, Monoid).
schedule Submitted 10 months ago
People who liked this proposal, also liked:
-
keyboard_arrow_downAndrae Muys - Where were the Functors? (the software engineering practices behind FP abstractions—without mentioning category theory)
30 Mins
Talk
Beginner
There is a small set of basic abstractions every beginner functional programmer needs to learn, generally sooner rather than later. For various—if unhelpful to beginner functional programmers—reasons, these have been given names drawn from mathematics (in particular, category theory). Monad, Applicative, Monoid, Functor, the list doesn't stop. Yet despite the relative obscurity of the names, it doesn't take long for a budding functional programmer to discover that practically everything is a Functor, and almost anything she wants to do requires a Monad. If our new functional programmer has been programming for a decade or two, this suggests an obvious question:
If practically everything is a Functor, and doing almost anything requires a Monad,
where were they hiding all this time?This talk will answer that question. Starting with some basic imperative Java/C/C# code, it will:
- show how the basic software engineering practices we have been using for decades, turn up in FP as these obscurely named types
- demonstrate how, by making these concepts concrete as types, FP gets to take fuller advantage of these practices than we ever could in imperative languages
- and impart some understanding (and possibly compassion) for the FP forebears who had to choose these names, and why we ended up with the names we have.
