This document introduces the concept of typed filesystems where every file has a specified type that is enforced. It discusses how immutable files under revision control could have an initial value and series of type-checked changes. Writing files would trigger a type check, with type-preserving writes committed immediately and other writes left "dirty" until later compatible changes. This allows flexibility in defining types while still enforcing them to avoid issues caused by files with inconsistent or unexpected data. Synergies with viewing files as sequences and a type-directed shell are also discussed.

1. Suffusehttps://github.com/suffuse/
paulp@improving.org

2. Virtual files
— Innumerable motivations
— Today focuses on a single one
— Typed Filesystems

3. Definitions
— Data: blob of bytes Array[Byte]
— Value: Data of a Type, Array[Byte] constrained
— Type: set of all possible Values and meanings

4. Types
— A Type specifies all possible values
— A Type System enforces Type membership
— There are no "dynamic" or "runtime" types
— Memory inspection is not typing

5. Type Specification
— minimal: Data => Boolean
— atomic: Data => T
— composite: (V1,...,Vn) => T
— differential: T => Change[T] => T

6. A complex system that works is
invariably found to have
evolved from a simple system
that worked.
-– John Gall

7. Change orientation
— Change is far more common than creation
— ...obscured by constructor-oriented languages
— (A, A => B) offers insight which (A, B) cannot

8. What's in a change
— (3:00:00, 75mph) and (3:00:01, 0mph)
— Individually fine, deadly in combination
— Constraining the set of possible values is not enough
— We constrain the set of possible derivations
— Sharpen constructors, only produce initial values

9. Typed Files
— Pre-suffuse, every file on the system is "Data"
— At best there may be a type hint, but never
enforcement
— Files can't be called typed until data always conforms
— Sounds good, but how?

10. Immutable files
— An initial file and a series of changes?
— We have something for that already
— Typed files all to be under revision control
— Changes typechecked, differentially if available

11. What's the type of a file?
— Might be declared: user given, suffuse enforced
— Might be inferred: file extension, "file" program
— The file metadata exposes all type information
— Enforce type-preserving writes where appropriate
— Log/warn where enforcement is too strong

12. Files/programs analogy
— Programs have "compile time" and "run time"
— For a file, compile time is when you change it
— Run time is when you need it
— We move enforcement to "compile time"

13. How does it work?
— Every write triggers a type check
— A type-preserving write immediately committed
— Other writes sit in the index "dirty"
— A later write may turn a bad write good
— Dirtiness in the filesystem is "uncompilable code"

14. Multiple universes
— Currently we have only the "dirty" universe
— Developers most likely stay there
— Production code lives in "clean" universe
— Every file can be trusted to be of its type
— Every file loaded with reliable metadata

15. Flexibility
— Our generality offers huge flexibility
— Types unimaginable in a proglang easy here
— Any Data => Boolean is a valid type

16. Typed source code
— We can define typed source different ways
— For this example it is
— "parsed and bound" (thus, ASTs and symbols)

17. class A[S](sym: S) { ---> class A[S](sym: S) {
def f[T](sym: T): String = { ---> def f[T](bippy: T): String = {
var q = "" + sym ---> var q = "" + bippy
q = q + sym ---> q = q + sym
q ---> q
} ---> }
} ---> }

18. Synergies
— All files are seqs (at worst, of bytes)
— More commonly, UTF-8 lines
— More usefully, a known type (e.g. csv, pwent, ...)
— Typed seqs mean typed pipelines!

19. Type-directed shell
— Typed files are decomposable other than line by line
— The decomposed types feed back into the shell
— cat file.csv | filter _.N<tab> = bob
— Many tools to upgrade: bash, find, grep

20. "Implicit Conversions"
— Assume typed files and typed executables
— What happens to mp3info *.aac?
— Define translations between convertible types
— As in scala, implicit machinery can bridge gap
— (As in scala, "magic" carries a cost)