The TUNES HLL- Subproject
For bootstrap purposes, we define a subset of the HLL that we can easily implement.
We want to keep the syntax as trivial as possible, so that initial lexing and parsing will not be a problem. There are two kinds of obvious choices:
- Trivial lexing, trivial parsing: the system tokenizes one word and executes the according code to parse it. But that's very low-level and if the only standard, yields dirty reflectivity.
- Easy lexing, easy parsing: the source is made of constructed objects, with a trivial s-exp constructor syntax.
- explicit constructors and destructors
- Lambda Calculus
- implicit binding and reduction
- Logical Constraints on Objects
- explicit specifications and proofs
- Modular Scoping
- explicit binding
- absorption and reification of features
- point of views on objects that describe what is or isn't relevant about the object.
- explicit rest of computations after return
- implicit environment parameters
- implicit alternate continuations in environment
- Simple pattern-matching,
- Annotations on objects
- implicit constructors
- implicit constraint analysis and enforcement
- Automatic partial pattern matching
- implicit destructors
- functions returning types
- Fluid binding
- implicitly realizing sub-interfaces
- Guarded Partial Evaluation
- implicitly optimizing a program for specialized environments.