notes-computer-jasper-jasperMetaprogramming

links

    Languages as Libraries - University of Utah    toread, looks great
    www.cs.utah.edu/plt/publications/pldi11-tscff.pdf
    by S Tobin-Hochstadt - 2011

http://docs.racket-lang.org/guide/pattern-macros.html

http://lambda-the-ultimate.org/taxonomy/term/15 http://lambda-the-ultimate.org/taxonomy/term/24

http://stackoverflow.com/questions/4758564/are-there-whole-program-transforming-macros-in-lisp-or-scheme

 Taxonomy of the fundamental concepts of metaprogramminghttp://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.140.5164&rep=rep1&type=pdf

http://scholar.google.com/scholar?start=10&q=metaprogramming+macros+reflection&hl=en&as_sdt=0,5

http://www.danielzingaro.com/extensible.pdf

http://scholar.google.com/scholar?q=extensible+programming+language+reflect+macro&btnG=&hl=en&as_sdt=0%2C5

http://en.wikipedia.org/wiki/Extensible_programming

OMeta: http://www.vpri.org/pdf/tr2008003_experimenting.pdf

--

jasper metaprogramming design principals

design principal "metaprogramming hierarchy": ladder/hierarchy of metaprogramming methods, encourage use of easier to read/less powerful ones first

design principal "subturing metaprogramming": at lower levels of metaprogramming hierarchy, extend the base Turing-complete language with subturing extensions for limited metaprogramming; but at higher levels of metaprogramming hierarchy, also give similar but Turing-complete extensions

-- should macros look just like ordinary functions? why or why not?

---

should be able to have embedded parts of code that are parsed differently. is this different from the character meta construct?

---

should be able to embed arbitrary other languages. jasper should have constructs to 'understand' the ideas of programming language, source code, object code, execution, compilation.

it should be able to represent the mapping between parts of source code and parts of object code, and the correspondence between state during execution, and parts of source code. note that these mappings may not be bijective.

it should be able to understand the concepts of homomorphic and isomorphic languages.

it should be able to represent the mapping between objects in the language and their representation in memory

it should be able to represent the mapping between control flow constructs and stuff like the stack

in many cases, it should be able to access the AST of an embedded language that parses differently

should jasper have runtime self-modifyable code?

https://www.google.com/search?client=ubuntu&channel=fs&q=self+modifying+code+considered+harmful&ie=utf-8&oe=utf-8

---

Camlp4

metalua

plot

racket

metaocaml

---

language extensibility mechanisms:

toread:

Modern Extensible Languages - Computing and Software ... www.cas.mcmaster.ca/sqrl/papers/SQRLreport47.pdf

Modern Extensible Languages www.danielzingaro.com/extensible.pdf

---

ideas from the Stepper paper:

first-class macros, first-class reified continuations (and access to arbitrarily modify the current call stack), first-class reified environments, "functions that receive unevaluated arguments as program text", macros that can access runtime values during macro expansion, a construct 'up' that "would allow retrieving the original definition of a function" (which is dual to 'down', which is like a precompile part of eval, although 'up' and 'down are more interestingly interpreted as referring to an infinite tower of interpreters)

as noted below (my idea not stepper's), to make compilation easier, could restrict reification of continuations, call stacks, and the results of 'up' to labels in the source code.


in addition to call/cc (which allows you to be passed a capture the call stack from places which are not your lexical ancestors, and to do computation before you are passed the continuation which choose which continuation to pass), may be useful to support 'labels' which serve just as labeled gotos (gofroms) but only for places which are both your lexical and call stack ancestors (escape continuations which are also your lexical ancestors):

(Label1 (blah))

would be equivalent to:

(call/cc (lambda x (let [Label1 x] (blah))))

this is just sort of like call/cc'ing into a named local variable

--

i think in theory call/cc is expressive enough to do anything ("goto" indeed), because you can already call INTO any named procedure (goTO), so the only thing you need to add to give total freedom is to be able to manipulate the call stack (the stuff that will be executed after you return), or equivalently, the current continuation.

however, in order to get the escape continuation you want, the parent has to use call/cc and pass it down to you; and in order to get the call stack into some arbitrary situtation, you have to have someone else get there and then use call/cc and pass it over to you. These restrictions may or may not be useful constraints in simplifying reasoning (e.g. the way that structured programming is simpler than goto, or await is simpler than callbacks), i'm not sure.

possibly a simpler, more general thing would be to just allow you to manipulate the call stack, or equivalently the current continuation, directly and arbitrarily. e.g. to literally operate on it like a stack, and to be able to put any labeled point in the source code at any point of it. This is like Lisp-3's Lambda-reflect except with the sensible default of starting with the stack as it is, and except its even more reflective; this would require reifying the internal representation of the call stack, or current continuation. Note that the need to be able to deal with a current continuation as easily as a call stack (what if the programmer chooses to use CPS? they should still be able to fruitfully use this facility) implies that nested lambda expressions in a thunk should be able to be pulled apart and inspected and restructured at runtime.

this would seem to rule out most compiler optimizations (!). however one could make the restriction that the call stack and thunks are only available at the granularity of labeled points in the source code.

---