3 ms·

i think it's deeper than that. the progression is from object (every one hand-crafted) to template-based object-maker (hand-crafted per kind of object, but can

by zem 14y ago

i think it's deeper than that. the progression is from object (every one hand-crafted) to template-based object-maker (hand-crafted per kind of object, but can produce a bunch of objects of that kind), to metatemplate-based template maker. however, once you hit that second level of abstraction, you have almost invariably added enough flexibility that the range of templates your template-maker can make includes templates for other template makers. that is, it's not just a quirk of linguistics that a meta-meta-template-maker is called a meta-template-maker, they really do tend to be objects on the same level of abstraction and flexibility.

evincarofautumn 14y ago
We seem to be saying the same thing; I just don’t see any inherent meaning in it. A literal interpretation of meta- would have us define it like this: Instance ::= 0 Meta(X) ::= Succ(X) But it’s much more convenient to define meta- recursively: Instance ::= 0 Meta(X) ::= Succ(X) | Meta(Succ(X)) In both cases, we have an arbitrary designation: Class ::= Succ(Instance) That kind of redundancy is a linguistic artifact, not a deeply meaningful one. It’s not the case that reaching the second level of abstraction necessarily results in enough flexibility to make the inductive step. As a counterexample, consider C macros, which only add one meta- because they are only expanded once. Lisp macros, on the other hand, are expanded until a fixed point is found. That’s why Lisp macros are Turing-complete while the C preprocessor is only a pushdown automaton.
- kpreid 14y ago
  A bit of disagreement with your last paragraph: The (Common) Lisp macro processor is Turing-complete trivially because it invokes a Turing-complete language along the way, not because of power inherent in its expansion strategy. Common Lisp macro bodies are written in Common Lisp, i.e. written in a Turing-complete language — they would still be Turing-complete even if we wrote them in the subset Lisp-without-macros. The C preprocessor, on the other hand, does not invoke a Turing-complete language to compute a macro's expansion.

by zem 14y ago

evincarofautumn 14y ago

We seem to be saying the same thing; I just don’t see any inherent meaning in it. A literal interpretation of meta- would have us define it like this: Instance ::= 0 Meta(X) ::= Succ(X) But it’s much more convenient to define meta- recursively: Instance ::= 0 Meta(X) ::= Succ(X) | Meta(Succ(X)) In both cases, we have an arbitrary designation: Class ::= Succ(Instance) That kind of redundancy is a linguistic artifact, not a deeply meaningful one. It’s not the case that reaching the second level of abstraction necessarily results in enough flexibility to make the inductive step. As a counterexample, consider C macros, which only add one meta- because they are only expanded once. Lisp macros, on the other hand, are expanded until a fixed point is found. That’s why Lisp macros are Turing-complete while the C preprocessor is only a pushdown automaton.

kpreid 14y ago
A bit of disagreement with your last paragraph: The (Common) Lisp macro processor is Turing-complete trivially because it invokes a Turing-complete language along the way, not because of power inherent in its expansion strategy. Common Lisp macro bodies are written in Common Lisp, i.e. written in a Turing-complete language — they would still be Turing-complete even if we wrote them in the subset Lisp-without-macros. The C preprocessor, on the other hand, does not invoke a Turing-complete language to compute a macro's expansion.