ideas-computer-jasper-jasperLevels

i have this idea that Jasper should have 'levels' and that the semantics of the language should be similar at different labels, but should become more or less abstract.

an example is quoting/anti-quoting.

another example is EDSLs, esp. the way that http://www.haskell.org/haskellwiki/GADT creates an EDSL:

data Term x where K :: Term (a -> b -> a) S :: Term ((a -> b -> c) -> (a -> b) -> a -> c) Const :: a -> Term a (:@) :: Term (a -> b) -> (Term a) -> Term b infixl 6 :@

now we can write a small step evaluator:

eval::Term a -> Term a eval (K :@ x :@ y) = x eval (S :@ x :@ y :@ z) = x :@ z :@ (y :@ z) eval x = x

and then says that "Since the types of the so-called object language, being the typed SK calculus, are mimicked by the type system in our meta language, being Haskell, we have a pretty convincing argument that the evaluator won't mangle our types. We say that typing is preserved under evaluation (preservation.) Note that this is an argument and not a proof."

another example is the low-level or 'raw' version of things, e.g. absolute apply instead of ask-the-argument-how-to-apply

i also have the idea that Jasper is going to have to have constructs with semantics relevant to the concepts of "programming language", "source code", "compiled code", "execution". Not sure why i think that. It seems relevant to the levels, though, if the levels are the relation of e.g. a compiler to the code that it is compiling.

---

hmm, how does my meta hierarchy fit in with my jasper ideas?

level 0 is data. you have a bunch of memory locations with a bunch of numbers.

level 1 is information, or data with also about data (metadata). even a type system would count as something in level 1, but to really max this out you want an extensible type system combined with an extensible metadata system and an extensible annotation system (these could all be the same, or they could be different), and a way to dynamically construct program code (an 'eval).

level 2 type one is meta-(metadata). metadata about the metadata itself. pointers to pointers, types of types, reflection on metadata and annotation (and eval within eval, which is probably always provided).

level 2 type two is meta-(meta)data. explicit representation of the meta- relation between the data and the meta-data. at this point we are already going beyond many existing programming languages. now we have to (a) be able to explicitly represent pointers to pointers, have an in-language notion of what a 'pointer' means, and to compute with the topology of pointers as if it were normal data, (b) be able to explicitly represent types of types, have an in-language notion of what a 'type' means, and to compute with types as if they were normal data, (c) be able to reflect, and to compute with metadata and annotations as if they were normal data, and have an in-language notion of what annotations and meta-data mean, (d) have facilities for traversing 'levels' of eval and have an in-language notion of what execution of code means.

level 3 type one-one is meta-(meta-(metadata)). Presumably already there if you have level two type one. Pointers to pointers to pointers, types of types of types, reflection on reflective capabilities, eval within eval within eval.

level 3 type two-one is meta-(meta)-(metadata). Presumably boring; the same as level 2 type two but applied to the jump between pointers and pointers to pointers, rather than the jump between raw data and pointers.

level 3 type two-two is meta-(meta)-(meta)data. Reflection on the jump to level 2 type two. An in-language notion of what it means to have an in-language notion of all those meta- things described above.

level 3 type three is meta-meta(-)metadata. Reflection on this hierarchy. An in-language notion of meta. Levels.

---

one way in which there is 'levels' in jasper is towers of composition. This applies not only to the exception towers of Maybe/Option types, but also to the way that an object applies its __get protocol method to an underlying object with fields that it can 'get' directly, without going thru __get. One could imagine that the underlying object could itself actually have a __get protocol method hiding a second level of underlying immediately accessed object, etc, etc.