Book Image

Learn Type-Driven Development

By : Yawar Amin, Kamon Ayeva
Book Image

Learn Type-Driven Development

By: Yawar Amin, Kamon Ayeva

Overview of this book

Type-driven development is an approach that uses a static type system to achieve results including safety and efficiency. Types are used to express relationships and other assumptions directly in the code, and these assumptions are enforced by the compiler before the code is run. Learn Type-Driven Development covers how to use these type systems to check the logical consistency of your code. This book begins with the basic idea behind type-driven development. You’ll learn about values (or terms) and how they contrast with types. As you progress through the chapters, you’ll cover how to combine types and values inside modules and build structured types out of simpler ones. You’ll then understand how to express choices or alternatives directly in the type system using variants, polymorphic variants, and generalized algebraic data types. You’ll also get to grips with sum types, build sophisticated data types from generics, and explore functions that express change in the types of values. In the concluding chapters, you’ll cover advanced techniques for code reuse, such as parametric polymorphism and subtyping. By end of this book, you will have learned how to iterate through a type-driven process of solving coding problems using static types, together with dynamic behavior, to obtain more safety and speed.
Table of Contents (12 chapters)

File modules

It turns out we've already made some modules! Reason treats the .re source files as modules, so our src/Ch01/Ch01_Demo.re and src/Ch02/Ch02_Demo.re files are automatically available as modules, with the names Ch01_Demo and Ch02_Demo, respectively. In the Reason world, these are called implementation files. We will informally refer to them as file modules.

Reason names file modules purely from their file names, ignoring their directory nesting. It makes every module automatically available from every other module, regardless of where they are physically in the project. This is why we were careful to name our modules with chapter prefixes; otherwise, files from different chapters but with the same names would confuse the compiler.

Let's take advantage of Reason's automatic module resolution, by creating a new (file) module that refers to something in...