SQL can be enhanced by introducing composable query fragments with statically-typed interfaces. Two main pain points of SQL are testing and reusing business logic.

• Testing: Testing SQL is difficult due to the need to populate all columns in a row even if only a few are relevant to the query. Shallow queries are easy to test but deep ones are expensive. There are no good solutions like making all FKs deferred or all columns nullable.
• Business Logic: In a normalized database, a lot of business logic is implemented at read-time and falls into two categories. SQL's limited abstraction leads to options like duplicating logic across queries, denormalization, or using views. Each option has its drawbacks - duplication leads to drift, denormalization has costs like maintaining invariants and storage, and views have performance issues as the optimizer is conservative about pushing predicates.

The solution is to introduce functors in SQL. Functors take tables satisfying an interface as parameters and return a specific type. They can be used for testing by providing fake tables and for business logic by composing multiple functors. For example, functors can be used to calculate pallet payload mass and clearance state. We can also generalize functors and use them for different types of objects.

In conclusion, functors solve the pain points of SQL and allow for fast, testable, and understandable queries. It could be implemented as a compiler that parses and interprets SQL syntax and does typechecking. Appendices cover topics like generics, generalizing business logic, naming, and global variables.