> Since the compilation unit of most Lisps is a form instead of a file like on most other languages, the core of the ClojureScript compiler can be seen as a program that will take a string representing a Clojure form as input, read it, recursively parse it into a tree of expressions also known as an AST (abstract syntax tree), and then walks down the tree emitting strings containing JavaScript code.
There might be a string representation of the code, but one thing that’s unique about a lot of lisps is that the input to compile/eval is not text: there is usually a function called something like “read” that turns the textual format into normal lisp objects and then eval can take any lisp object and evaluate it. Typical lisp objects are “self-quoting”, but what characterizes a lisp is that the domain and codomain of eval are the same type.
> [...] eval can take any lisp object and evaluate it.
eval cannot be generalized to accepting any Lisp object, only specifically symbolic expressions (symbols, or lists (potentially nested) of symbols). I discovered this because I thought Chibi Scheme was throwing a warning for valid code[0] to inject a value into an expression for eval, but Marc helped me understand that the warning was correct, because Scheme only specifies what eval does for symbolic values.
Anyways, here's CL's spec for eval[1]:
eval form => result*
IMO, the useful definition of homoiconicity is "the domain and codomain of eval are the same type". One of the "results" of eval might be that the evaluation routine signals error, if the object has a special evaluation rule.
EDIT: I just read that github thread more carefully, and I guess Scheme's eval is stricter and so, IMO, Scheme is less "homoiconic" :) FWIW, my experience is that Scheme pioneered a lot of things that are more similar to non-lisps than to the more lispy lisps: e.g. schemes typically seem to prefer batch-style compilation to REPLy environments. Source as files vs. image-based development and the standard defines the language in terms of text rather than datastructures.
[1] http://www.lispworks.com/documentation/HyperSpec/Body/f_eval...
[2] http://www.lispworks.com/documentation/HyperSpec/Body/26_glo...
[3] http://www.lispworks.com/documentation/HyperSpec/Body/26_glo...
The difference between debugging and profiling Clojure and ClojureScript is night and day. e.g. async-profiler and VisualVM are much better than whatever I've seen in the Node.js and browser ecosystems. But tools like FlowStorm seem to be helping close this gap, if you decide to use the custom compilers designed for it.
As someone whose day job is developing with ClojureScript, I've been keeping a close eye on developments in FlowStorm, and I always send this video to get people interested: https://www.youtube.com/watch?v=4VXT-RHHuvI
edit: sorry realize my comment is confusing, I got very emotional when I saw about flow storm http://www.flow-storm.org/
clojurescript debugging.. oh my god I can't even imagine.