# lib-laddertypes Rust Implementation of Ladder-Types (parsing, unification, rewriting, etc)
## Ladder Types ### Motivation In order to implement complex datastructures and algorithms, usually many layers of abstraction are built ontop of each other. Consequently higher-level data types are encoded into lower-level data types, forming a chain of embeddings from concept to `rock bottom' of byte streams. While a high-level type makes claims about the semantics of objects of that type, high-level types are ambiguous in regard to their concrete syntactical representation or memory layout. However for compositions to be type-safe, compatibility of concrete represenations must be ensured. For example in the unix shell, many different tools & utilities coexist. Depending on the application domain, each of them will potentially make use of different representational forms for the same abstract concepts. E.g. for the concept 'natural number', many representations do exist, e.g. with variation over radices, endianness, digit encoding etc. Intuitively, *ladder types* provide a way to distinguish between multiple *concrete representations* of the same *abstract / conceptual type*, by capturing the *represented-as* of layered data formats in the structure of type-terms. Formally, we introduce a new type constructor, called the *ladder type*, written `T1 ~ T2`, where `T1` and `T2` are types. The type-term `T1 ~ T2` then expresses the abstract type of `T1` being represented in terms of the concrete type `T2`, which can be read by "`T1` represented as `T2`". #### Example The following type describes a colon-separated sequence of timepoints, each represented as unix-timestamp written as decimal number in big-endian, encoded as UTF-8 string. ``` ~ ~ℕ ~ ~~Char>> ~ ~ ~UTF-8 ~ ``` An object that fits the format described by this type could look like this: ``` 1696093021:1696093039:1528324679:1539892301:1638141920:1688010253 ``` ### Syntax A type-term can be of the form: - `0` | `1` | `2` | ... (**Literal Integer**) - `'a'` | `'b'` | `'c'` | ... (**Literal Character**) - `SomeTypeName` (**Atomic Type**) - `` given `T_1` and `T_2` are type-terms. (**Parameter Application**) - `T_1 ~ T_2` given `T_1` and `T_2` are type-terms. (**Ladder**) Ontop of that, the following syntax-sugar is defined: #### Complex Types - `[T]` <===> `` - `{a:A,b:B}` <===> ` <"b" B>>` - `a:A|b:B` <===> ` <"b" B>>` #### Function Types - `A -> B` <===> `` #### Reference Types - `*A` <===> `` - `&A` <===> `` - `&!A` <===> `` ## How to use this crate ```rust use laddertypes::*; fn main() { let mut dict = TypeDict::new(); let t1 = dict.parse("").expect("couldnt parse typeterm"); let t2 = dict.parse("< C>").expect("couldnt parse typeterm"); assert_eq!( t1.clone().curry(), t2 ); assert_eq!( t1, t2.clone().decurry() ); } ``` ## Roadmap - [x] (Un-)Parsing - [x] (De-)Currying - [x] Unification - [x] Ladder-Normal-Form - [x] Parameter-Normal-Form - [ ] (De)-Sugaring - [ ] Seq - [ ] Enum - [ ] Struct - [ ] References - [ ] Function ## License [GPLv3](COPYING)