Homoiconic Dichotomy and Interactive Publications
Both Linguistics and Computer Science have some concern about the difference between form and meaning. This difference is usually introduced in a syntax vs semantics lecture. I would like to show that it actually occurs in a wide variety of circumstances.
Form | Meaning | Domain |
---|---|---|
Syntax | Semantics | Linguistics (grammars), Computer Science (Parsing) |
Language | Thought | Cognitive Science, Artificial Intelligence, Sapir-Whorf Hypothesis |
Data | Code | Compilers, Interpreters, Metacircular Evaluators |
Document | Application | Web 2.0 |
Key to this topics is an interesting observation, for the syntax of any language to have meaning, there must exist an interpreter. For spoken languages, the interpreter is a brain (conventionally human, though the statistical models of machine learning experts are pushing the capabilities of electronic brains). In my own field of computer science, we’ve recognized that via a side-effect of the Church-Turing Hypothesis, formal languages can be turned to inspect themselves in a Strange Loop.
Lisp gives the most compelling example of this structural curiosity: For the underlying data structure of Lisp programs, the list, is syntactically represented in the exact same manner as Lisp programs themselves. This property makes the language homoiconic. The advantages are philosophically far-reaching: it makes very easy the ability to have code-writing-code, because a program can treat another function as data, manipulating it and restructuring it, until a new function is produced as a result.
Of course, if the system is allowed to point at itself, we have self-modifying code. And all the dangers, and advantages, and clever tricks that implies. I bring up this point, because of that last item: the difference between a document and an application is steadily blurring on the Web. It started with a desire for documents to have some level of interactivity, and has crescendoed into mail, maps, and even gaming (thanks to HTML5 canvas). But what’s really going on is, JavaScript, which is embedded in a document, has access to the document, and can modify the contents on the fly, in response to user input. It’s a self-modifying document (that can interact with the world through REST API’s, XmlHttpRequest, post/get webforms, etc).
[I just want to bury in here a mention of the Guidelines on Active Content and Mobile Code which focuses on the security implication of readily available, barely containable, documents with embedded code ]
Even if JavaScript, by chance, has some self-describing features as witnessed by JSON. I think the better medium would have been something Lisp or Scheme-like. We could port a publishing framework such as Skribilo to the web pretty easily. Just write a scheme interpreter in javascript, provide hooks for the html generator backend so that connects to its own page, and ship! Because Lisp and Scheme have some better theoretical underpinnings (due to their closeness to the lambda calculus) we ought to be able to get better security by moving our documents to such a form. At the very least though, we will definitely have an easier time maintaining our document/app chimeras.