The Tunes HLL- Subproject
For bootstrap purposes, we need a subset of the HLL
that we can easily implement.
Let's define the minimalistic HLL- core.
-
Syntax
-
we want to keep the syntax as trivial as possible,
so that initial lexing and parsing be not a problem.
There are two kinds of obvious choices:
- one is do like FORTH -- 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.
- The other is to do like LISP -- easy lexing, easy parsing:
the source is made of constructed objects,
with a trivial s-exp constructor syntax.
-
Semantics
-
We want to have
- structures, i.e. explicit constructors and destructors
- lambda-calculus, i.e. implicit binding and reduction
- logical constraints on objects, i.e. explicit specifications and proofs
- modular scoping, i.e. explicit binding
- absorption and reification of features, i.e. reflexion
- point of views on objects that describe
what is or isn't relevant about the object.
Then we can define everything we want.
From simplest to most complicated constructs:
- Continuations, i.e. explicit rest of computations after return
- Side-Effects, i.e. implicit environment parameters
- Exceptions, i.e. implicit alternate continuations in environment
- Simple pattern-matching,
- Annotations on objects, i.e. implicit constructors
- Typing, i.e. implicit constraint analysis and enforcement
- Automatic partial pattern matching, i.e. implicit destructors
- Functors, i.e. functions returning types
- Fluid binding
- Inheritance, i.e. implicitly realizing sub-interfaces
- Guarded Partial Evaluation, i.e. implicitly optimizing a program
for specialized environments.
You may also want to
Go up to the
HLL subproject
subproject
go to the Tunes Subproject tree
or go back to the main Tunes page.
Subproject coordinator:
Faré
-- rideau@ens.fr