notes.txt

antidoc: it is possible to turn around code docs and reference the code from the doc instead of including the
doc in the code
explain: what problems does it try to solve

// --

type notation of a list, and a function:

{
	type:        "list"
	min:         3
	items:       ["a"]
	types:       ["a"]
	constraints: {
		a: [{
			type: "union"
			types: ["a", "b"]
			contraints: {
				a: {
					type: "int"
					min:  ints.min
					max:  -1
				}
				b: {
					type: "int"
					min:  1
					max:  ints.max
				}
			}
		}, {
			type: "string"
		}]
	}
}

{
	type:       "function"
	params:     ["f", "b", "l"]
	returns:    "b"
	types:      ["a", "b", "f", "l"]
	contraints: {
		f: [{
			type:    "function"
			params:  ["a", "b"]
			returns: "b"
		}]
		l: [{
			type:  "list"
			items: ["a"]
		}]
	}
}

type myList [(int::-1 | int:1) ^ string, 3:]
type fold fn(fn (a, b) b, b, [a]) b

// --

why no user defined types:
- the type system considered by the compiler is complex
- a type notation as part of the language would make it hard to implement changes and improvements
- some of the type constraints would require injected code making the reasoning about complexity harder
why user defined types are required:
- module level contracts
questions to answer:
- can automatically generated types be better than manually defined ones
- can applications have enough benefit from automatically generated types
notes:
- the first question holds too much subjectivity
- the second question can be easier to support with metrics
possibilities enabled by the right type notation:
- alternative mathematical type systems, dimensions, currencies
notes:
- the current type system used by the compiler doesn't support above features
simple hack:
- abort: if code branch is reachable and contains abort, the compiler fails

// --

tooling feature: collect metrics

// --

effect scoping: effect outside of its scope