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.

Related Content you might be interested in

Current Title:

Small book image
Learn Type-Driven Development
Yawar Amin | Kamon Ayeva
Dec, 2018 | 180 pages
Small book image
ReasonML Quick Start Guide
Bruno Joseph Dmello | Raphael Rafatpanah
Feb, 2019 | 180 pages
Table of Contents (12 chapters)
Preface
Preface
Who this book is for
What this book covers
To get the most out of this book
Get in touch
Free Chapter
1
Starting Type-Driven Development
Starting Type-Driven Development
Analyzing code for hidden errors
Adding types
ReasonML
Summary
2
Programming with Types and Values
Programming with Types and Values
Workflow
Types and values
Static and dynamic environments
Errors
Summary
3
Packaging Types and Values Together
Packaging Types and Values Together
File modules
Syntactic modules
Module signatures
Module errors
Type abstraction
Summary
4
Grouping Values Together in Types
Grouping Values Together in Types
Record types
Tuple types
Object types
JavaScript object types
Summary
5
Putting Alternative Values in Types
Putting Alternative Values in Types
Variant types
The power of switch
Polymorphic variant types
Generalized algebraic data types
Designing for correctness with types
Summary
6
Making Types That Can Slot into Any Other Type
Making Types That Can Slot into Any Other Type
Type inference and generic types
The list – modeling more than one
The option – modeling either none or one
Mutable parameterized types – ref and array
Forcing a difference with phantom types
Summary
7
Making Types That Represent Operations
Making Types That Represent Operations
Function types and other useful properties
Multiple arguments and currying
Summary
8
Reusing Code with Many Different Types
Reusing Code with Many Different Types
Polymorphism in Reason
Generic code with functors
Summary
9
Extending Types with New Behavior
Extending Types with New Behavior
Subtyping using polymorphic variants
Code reuse with OOP-style inheritance
Summary
10
Bringing It All Together
Bringing It All Together
Starting with a variant type (version 1)
Using more pattern matching (version 2)
Switching to polymorphic variant types (version 3)
Using records (version 4)
Using modules for code structure (version 5)
An alternative code structure (version 6)
An improvement – using lists as output (version 7)
Another improvement – using mutable records (version 8)
Unit testing our code (final version)
Summary
11
Other Books You May Enjoy
Other Books You May Enjoy
Leave a review - let other readers know what you think

Module signatures

Module signatures, also known as interfaces, are an explicit place to put type annotations. But they actually serve several purposes:

  • Export a module's public API
  • Document the types of a module's public API
  • Provide a place to put module documentation
  • Hide non-public elements of a module
  • Hide implementation details of types

Keeping in mind the points mentioned earlier, when would you not want to use a signature for your module? It's not set in stone, but my rule of thumb is to not use a signature when my API is experimental and still evolving (in semantic versioning terms, less than version 1.0.0.), or when the module is purely an application module and is not meant to be published as a library for others to consume (although the line between these is somewhat grainy).

Signatures come in two forms–interface files and syntactic signatures...

Previous Section
End of Section 4
Next Section