Hacker News Reader

Comment by 4ad | Hacker News Reader

Julia is homoiconic, so it can do things non-homoiconic languages can't do. E.g. symbolic differentiation of Julia expressions.

Of course Lisp and Scheme can do this too, but it's virtually non-existent in any common language today. SICM makes heavy use of this.

Now, is there any other language with Lisp-like macros and static typing?

View on HN

R is actually homoiconic. It's somewhat awkward and not a language feature that many packages exploit, but it's there. I wouldn't describe R as having Lisp-like macros, though... maybe "macro-like functions."

edit: and _definitely not_ static typing.

Typed clojure

When do you call a language "homoiconic" exactly? When it exposes its own AST (abstract syntax tree) structure? In that case, you can call any language homoiconic, whenever somebody builds a library that can transform a given AST back into executable code.

I'm not sure if it is a very distinctive feature.

It's not about any "given" AST, it's about having a computable representation of any code. For example, if I pass you a higher order mathematical function that calculates the first derivative of another function (f), you can create an algorithm that integrates the function symbolically, thus obtaining (another) primitive (related to the original f by a constant).

Note that I mean to symbolically calculate derivatives and integrals, not numerically. A homoiconic language can deconstruct any object representing code and can construct another object based on the underlying structure of the original, not based on any particular value of the original. The original doesn't even need to be invoked at all.

In mathematical parlance, a homoiconic language allows implementing functionals, as opposed to mere higher-oder functions (which is nothing more than function composition).

Please note that all this works with higher-order functions. You don't have to have a textual representation of the function. A.i. you don't parse your own source code.

LISP was actually invented to be able to implement functionals and symbolic calculations like this. The original paper demoed implementing function differentiation (among other things).

So, to understand what you are saying, is it true that in LISP, you can write a function F that can take any function object G, and turn it into an equivalent AST of G?

The spirit of your statement is true, but the precise formulation is incorrect. In LISPs, when you pass a function, you pass a list that defines the function. There is no special "turn into AST" step. Executable code is data, and you can create genuinely new executable code out of this data. There's no special "turn code into data" or "find the data corresponding to this code" step. Code just is data.

Typed Racket?

Never heard of it. Will check it out.

Racket is a scheme derivative, actually it consists of several languages including some domain specific ones, that all are compatible with each other. It also has a _very_ nice C foreign function interface (much better than Haskells for example).

Thanks for the note. When I first heard "typed racket" I thought: "oh no, an obscure dialect of an already obscure language" and I was slightly disappointed, but now I understand that typed racket is not a derivative of racket, but rather racket is a domain of languages including typed languages. This makes it much more interesting to me. Thanks for the note.

Is that the one with

    (: fun (natural natural -> real))

procedure signatures?

I believe so.

Reply on news.ycombinator.com