types

Author: takev

doc/language/data_model.md

@@ -16,47 +16,47 @@ Here are a couple of rules in this language:
 
 ## Templates
 
-Function and type definitions are always templates in this language.
+All function-, type- and (global) variables-definitions are templates. One or more
+definitions with different signatures with the same name form a overload-set.
+
+Each of the following functions form the `foo` overload-set:
+```
+fn foo(x: int) { return x + 42 }
+fn foo(x) { return x + 1 }
+fn foo() { return 0 }
+```
+
+Both of the following type-templates form the `bar` overload-set:
+```
+struct bar[T: type] { var x : T }
+struct bar { var x : int }
+```
+
+Both of the following global variable-templates form the `qux` overload-set.
+`qux_init()` is evaluated at compile time if possible:
+```
+var[T: type] qux : T = qux_init(T)
+var qux : int = qux_init(int)
+```
+
+An overload set is lazilly evaluated, which means they may be modified after the
+definition. This makes it possible to add members to a type after its definition
+and even by a different module or repository. After a overload set is frozen
+it can no longer be modified.
+
+### Freezing
+
+These are the main ways that a overload-set becomes frozen:
+ - Code-statements at file level will cause overload-sets that are used
+   to be frozen.
+ - After a `program` is parsed the `main()` function is compiled and
+   overload-sets that are used will be frozen.
+ - After a `library` is parsed all the exported functions and
+   global-variables are compiled and overload-sets that are used will be frozen.
+ - Recursively all type annotations used in the signatures of an overload
+   set are frozen.
 
 
-## Overload sets
-
-
-
-
-## Compilation Order
-
-The compilation order is important when we are describing how the compiler
-knows which types are visible and complete.
-
-Compilation starts after the prologue-scan which will read every source file
-in the repository and each imported repository.
-
-Each file is then compiled in random order while satisfying that all imported
-modules of a file are compiled first. In incremental/language server mode,
-files may trigger recompilation of files and their dependent files.
-
-Each file is compiled statement-by-statement, as-if they executed in a
-interpreter, for example:
- - type-template definition.
- - function-template definition.
- - global variable definition.
- - executable statements
-
-> [!NOTE]
-> All types and function declarations are templates in this language.
-
-At this time function and type declarations remain in their "modifiable" state,
-this means:
- - Other versions of type and functions can be added to the overload set.
- - It is possible to modify types by removing and adding members to types,
-   as-if types are mutable values.
-
-During the statement-by-statement compilation there may also be normal code
-statments at file scope that will be executed that for example can make these
-modifications of types. These code statements can cause types and functions
-to transition to "frozen" and "instantiated" state.
-
 
 
 ## Functions

doc/language/syntax/argument_declaration.md

@@ -2,15 +2,19 @@
 
 ## Syntax
 
-[_binding_mode_](binding_mode.md)__?__ [_name_](name.md) [_type_declaration_](type_declaration.md)__?__
-__(__ `=` [_expression_](expression.md) __)?__ __|__\
+[_binding_mode_]__?__ [_name_] [_type-annotation_]__?__ __(__ `=` [_expression_] __)?__ __|__\
 
-[_literal_](literal.md) [_type_declaration_](type_declaration.md)__?__ __|__\
+[_literal_] [_type-annotation_]__?__ __|__\
 
-`(` [_expression_](expression.md) `)` [_type_declaration_](type_declaration.md)__?__ __|__\
+`(` [_expression_] `)` [_type-annotation_]__?__ __|__\
 
-[_binding_mode_](binding_mode.md)__?__ [_name_](name.md)`...` [_type_declaration_](type_declaration.md)__?__
+[_binding_mode_]__?__ [_name_]`...` [_type-annotation_]__?__
 
+[_type-annotation_]: type_annotation.md
+[_binding_mode_]: binding_mode.md
+[_expression_]: expression.md
+[_literal_]: literal.md
+[_name_]: name.md
 
 ## Semantics
 Declares an argument for a function or lambda with a [_name_](name.md)

doc/language/syntax/attributes.md

@@ -40,14 +40,19 @@ This function will not return.
 An implementation must terminate the application if the function does
 return. Or proof that the function will not return.
 
-### pre()
+### pre(expression)
 Pre-condition is checked before calling the function.
 
-### post()
+### post(expression)
 Post-condition is checked after calling the function.
 
 A post-condition on a type will run after an object is modified.
 
+### constrain(expression)
+A condition that is checked when matching if the template arguments
+are valid for this specific overload in the overload-set.
+
+Constrain can also contain guard conditions.
 
 ### std.no_inline
 Calls to this function are never inlined.

doc/language/syntax/enum_definition.md

@@ -8,7 +8,7 @@
 [_tag_](tag.md) __|__
 [_context-argument_](context_argument.md) __|__
 [_positional-argument_](positional_argument.md) __|__
-[_variable-declaration_](variable_declaration.md) __|__
+[_variable-definition_](variable_definition.md) __|__
 [_operator-expression_](operator_expression.md) __|__
 [_if-control-expression_](if_control_expression.md) __|__
 [_while-control-expression_](while_control_expression.md) __|__

doc/language/syntax/enum_name.md

@@ -1,4 +1,4 @@
-# type-declaration
+# type-annotation
 
 ## Syntax
 

doc/language/syntax/enum_name_list.md

@@ -0,0 +1,8 @@
+# type-members
+
+## Syntax
+
+[_function-definition_](function_definition.md) __|__
+[_type-definition_](type_definition.md) __|__
+[_variant-definition_](variant_definition.md) __|__
+[_variable-definition_](variable_definition.md)

doc/language/syntax/expression.md

@@ -1,4 +1,4 @@
-# variable-declaration
+# variable-definition
 
 ## Syntax