backup commit of notes so far

notes/papers/report/parts/future_work.md

@@ -0,0 +1,71 @@
+# Future work
+
+## Standard library
+
+There are a few libraries I would like to implement in the future to demonstrate various uses of the language
+
+### Macro error reporting
+
+When describing syntax transformations with Orchid macros, it's fairly easy to make assertions about the stages during which given tokens should exist in the code in terms of the lower and upper bound of the currently active priority number. When these assertions fail, the consequences can be very difficult to debug since a partially transformed syntax tree with all sorts of carriages around conforms to neither the public API of any library nor the core language and lambda calculus. This problem can be addressed with guard rules and bubbling errors. To demonstrate, consider this module:
+
+```
+-- in client library
+import std::macro_error::missing_token
+
+-- what this carriage does is not relevant to the example, focus on the priority numbers
+start_carriage $init =100=> carriage ($init)
+carriage ($state) $f =10_001=> carriage (($f $state))
+carriage ($state) stop_carriage =10_002=> $state
+
+-- report the suspected reason why this carriage did not get consumed
+carriage ($state) =0=> (missing_token stop_carriage ($state))
+
+export ::(start_carriage, stop_carriage)
+```
+
+```
+-- in std::macro_error
+
+-- convert various errors to uniform format
+export (missing_token $token ..$details) =1_000_000=> (bubbling_error
+  "{} was not found" ($token) (..$details)
+)
+
+-- forward error upwards
+(..$_prefix (bubbling_error ...$args) ..$_suffix) =1_000_001=> (bubbling_error ...$args)
+[..$_prefix (bubbling_error ...$args) ..$_suffix] =1_000_001=> (bubbling_error ...$args)
+{..$_prefix (bubbling_error ...$args) ..$_suffix} =1_000_001=> (bubbling_error ...$args)
+```
+
+With this, various options are available for displaying the error:
+
+1. bubbling_error could be a magic token that always causes the macro executor to format and print the following string
+2. bubbling_error could be defined as a function to raise an error when the problematic function is called. This only supports the (in my opinion, insufficient) level of error reporting Python provides for syntax errors
+3. bubbling_error could be left undefined, the runtime could expose processed functions that contained undefined names after macro execution, and dev tooling could parse bubbling_error out of this data.
+
+### Extensible structural(?) pattern matching
+
+Since all tokens are namespaced, complicated protocols can be defined between libraries for dispatching macro resolution. I would like to make use of this to build a pattern matching library that resolves patterns to a series of function calls which return some kind of Maybe value. This is something I often wish Rust supported, for instance when matching a type part of which is stored in a reference-counting pointer, a second match expression is required to extract data from the reference-counted part.
+
+### Function serialization
+
+Being a pure language, Orchid carries the potential to serialize functions and send them over the network. This enables for instance an Orchid web framework to represent UI as well as and database transactions as simple callbacks in server code that are flush with the code describing server behaviour. I would like to explore this option in the future and develop a general library that allows 
+
+### Macros for UI, declarative testing, etc. 
+
+The flexible macro system enables library developers to invent their own syntax for essentially anything. I considered defining macros for html, music scores / midi data, marble and flow diagrams.
+
+### DMA/MMIO
+
+TODO
+
+## Type system
+
+### Early plans
+
+Originally, Orchid was meant to have a type system that used Orchid itself to build generic types using logic of unconstrained complexity from their arguments. The time constraints did not allow for this to be done in the initial version, but it is still on the roadmap.
+
+### Alternatives
+
+During initial testing of the working version, I found that the most common kind of programming error in lambda calculus appears to be arity mismatch or syntax errors that result in arity mismatch. Without any kind of type checking this is especially difficult to debug as every function looks the same. This can be addressed with a much simpler type system similar to System-F. Any such type checker would have to be constructed so as to only verify user-provided information regarding the arity of functions without attempting to find the arity of every expression, since System-F is strongly normalising and Orchid like any general purpose language supports potentially infinite loops.
+