scheme

Types and classes are the same
schemas are adhoc types orthogonal to data.

The idea is to push the optionality of fields to specific use cases:

Fields can be made required in function declarations via with keyword or nested schemas:

age of car with year = car.year
age of car{year} = car.year

Now the function age is applicable to all classes and sub-classes of car provided they have a year property!

The scheme of the type can be adhoc and deep within function declarations:
arrival time of package{destination{address{zip or street}}} = calculate distance to zip … To avoid redundancy, the type scheme leafs act as local symbols, so in the above example 'zip' is available to the block.

The untyped variant would just be arrival time of package is calculate distance to its zip Relying on deep accessor indexing

structs and named tuples

structs are instances of classes without the header in memory. Or put the other way round: classes are thin meta wrappers around structs. While the type information for struct instances is only available at compile time, the header of class instances is part of the data in memory.

Compare with NamedTuple(x: Int32, y: String) in ruby and record in C#