|author||Mike Gerwitz <email@example.com>||2017-07-19 16:22:08 -0400|
|committer||Mike Gerwitz <firstname.lastname@example.org>||2017-07-19 16:22:08 -0400|
Compiler TODO for algebraic types
* doc/todo.texi (Compiler): Add section.
Diffstat (limited to 'doc')
1 files changed, 29 insertions, 0 deletions
diff --git a/doc/todo.texi b/doc/todo.texi
index fde27e2..6ef7b1b 100644
@@ -50,6 +50,35 @@ Performance has improved drastically,
+The compiler itself has cruft from over the years and most of the code
+ exists from the design prior to object files and symbol tables.
+There is plenty of room for optimization.
+ @item Validate against an algebraic type system.
+ Certain classes of bugs can be avoided entirely by stating that
+ values must always be a vector of positive real numbers, for
+ The compiler can determine the type of expressions by the
+ symbols it references and by its child expressions.
+ In situations that are not resolvable at compile-time,
+ runtime checks via terminating classifications would do;
+ an example being the sum of two unsigned integers being
+ In cases where types are simply too difficult to determine
+ without significant compiler work,
+ annotations can be used to declare expressions equivalent
+ to certain mathematical concepts
+ (e.g. ``this function is equivalent to rounding to the
+ nearest integer'');
+ this can also serve as an alternative to primitives in
+ certain instances,
+ since native target language features could be used.
@section Input/Return Map
@item Generate normal packages and use templates rather than a