Backup commit before crunch

This commit is contained in:
2023-05-16 18:32:25 +01:00
parent 33413b2b0f
commit 126494c63f
59 changed files with 847 additions and 236 deletions

View File

@@ -55,9 +55,19 @@ Being a pure language, Orchid carries the potential to serialize functions and s
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
### Unsafe
TODO
These functions may be exposed by a direct Orchid interpreter but they would probably not be included in the library exposed by an embedder.
#### system calls
While individual system APIs can be exposed to the program using dedicated Rust bindings, this takes time and limits the power of the language. The general solution to this in high level languages is to expose the `system()` function which enables high level code to interact with _some kind of shell_, the shell of the operating system. What shell this exactly is and what tools are available through it is up to the user to discover.
#### DMA/MMIO
As a high level language, Orchid doesn't inherently have direct memory access, in part because it's not generally required. Regardless, a way of writing to and reading from exact memory addresses may be useful in the development of libraries that interface with hardware such as a rapsberry pi's GPIO pins.
On general this is probably better accomplished using Rust functions that interface with Orchid, but this will eventually inevitably lead to several functions that do nothing but read a number from an address or write a number to an address, except the addresses are wrapped in various tagged structs. This repetition could be nipped in the bud by simply exposing a function for mmio and allowing the Orchid side to define the wrappers.
## Type system
@@ -67,5 +77,5 @@ Originally, Orchid was meant to have a type system that used Orchid itself to bu
### 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.
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 error that results 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.