This is very cool, and a direction that I hope more toolchains will go.<p>One problem, though, is that reading trees in text format is not very easy on the eyes. In fact, this might be one of the biggest reasons that LISP is (to people like me) not very readable. Trees in graphical form are orders of magnitude easier to parse visually.<p>I'd love to see software that makes visualizing tree structures easier. At one point I had a grand plan of porting graphviz to JavaScript, with SVG as an output format so it could be easily styled with CSS.<p>I think that approaches like this will be a lot more usable (and deliver a lot more "wow" factor) if you can view the trees graphically.
One thing that this kind of low level "interface" allows is a very rapid development of coding tools. How long until we see a context-context sensitive auto completion pop up? These language features would even allow more complex hints. Language analyzers can find bugs and note them right when writing code.<p>Of course, this is nothing new and already done in a few languages. But these features will make it easier (and hence faster) for the IDE to have some awesome coding features.
A footnote mentions that @which is not as helpful for functions defined the REPL, because it doesn't give a file and line number in that case. This is not the case, however, in the new IJulia notebook interface (a REPL based on the IPython notebook); there, each multiline input cell is named "In[nnn]" (like Mathematica) and is treated like a file, so you can type "@which foo(3)" and it will give "foo(x) at In[22]:1" if you defined foo on line 1 of input In[22].<p>Note also that, in the latest versions of the REPL (and IJulia), you can simply type "? foo(3)" instead of "@which foo(3)".
maybe this could go in the blank space under "introspection" in the current manual? just sayin... [edit: sorry, yes, reflection]<p>(julia is my new crush. i haven't actually used it yet, i just keep reading the docs and thinking how awesome it all sounds).
I'm not implying that their expression data structure is in anyway deficient, but given that Julia is so lispy in the first place, why was a design decision made to abandon (the more readable/familiar ?) S-expressions ? Can one of the devels give us an insight ?<p>Edit: Can someone also comment on how Julia compares to Dylan in the semantic sense ?