Many languages claim to be "lisps" for various reasons, and there's always someone who disagrees.
Also, what exactly do you mean by "homoiconic"? People love this word because it sounds fancy and marks them as someone who geeks out on programming, but the fact is that this word is, if not ambiguous, at least prone to abuse. Let me give a specific example.
The new language Julia has a macro system and Julia's designers claim that the language is homoiconic. Is it? It has a way to quote expressions such that
a + b
is just the result of a + b whereas
:(a + b)
returns the expression tree for a + b. This can then be modified, eval'd, and otherwise sliced and diced. But what does that expression tree look like? When you print it in Julia, you get something like:
Question: does that look like a normal snippet of Julia code you could paste into your test editor and eval? No. The "real" syntax for that code is something like:
{:call, {:+, :a, :b}, Any}
(Julia-ish pseudocode, not precise)
In any event, while you CAN write a Julia program using the literal syntax for the data structures that represent Julia programs, people usually don't do that.
So what does homoiconic mean? Does it mean that you can get to the data structure representing your code and then manipulate it at will? Or does it mean that PLUS the fact that programs in your language always take exactly the form of the data structure that represents that code?
If the former, then a lot of languages (including C# with its expression trees) can claim to be partially or fully homoiconic. If the latter, then the list is much smaller.
So would a homoiconic Haskell be a lisp? I think what you'd end up with after taking things far enough wouldn't be Haskell at all. It'd be a lisp with a REALLY good type system.
After all, things like monads and morphisms and applicative functors aren't Haskell, they're mathematics.
Yeah, the word is admittedly a bit problematic. If one wanted to be overly pedantic, any language with strings might be called homoiconic. The better answer is to ask how commonly-used are the data structures for storing the expressions. What makes Lisp so powerful is that these data structures are lists and lists are used all the time; this enables a large amount of code sharing between macros and regular functions.
Now this makes it very straightforward to evaluate the usefulness of Julia's claim of homoiconicity: how often would you expect to use the data structures Julia uses to represent its expression trees? If the answer is not very often, then the language suffers for it because you're going to have to write special-purpose code for macros instead of reusing the libraries you'd use anyway.
Also, what exactly do you mean by "homoiconic"? People love this word because it sounds fancy and marks them as someone who geeks out on programming, but the fact is that this word is, if not ambiguous, at least prone to abuse. Let me give a specific example.
The new language Julia has a macro system and Julia's designers claim that the language is homoiconic. Is it? It has a way to quote expressions such that
is just the result of a + b whereas returns the expression tree for a + b. This can then be modified, eval'd, and otherwise sliced and diced. But what does that expression tree look like? When you print it in Julia, you get something like: Question: does that look like a normal snippet of Julia code you could paste into your test editor and eval? No. The "real" syntax for that code is something like: (Julia-ish pseudocode, not precise)In any event, while you CAN write a Julia program using the literal syntax for the data structures that represent Julia programs, people usually don't do that.
So what does homoiconic mean? Does it mean that you can get to the data structure representing your code and then manipulate it at will? Or does it mean that PLUS the fact that programs in your language always take exactly the form of the data structure that represents that code?
If the former, then a lot of languages (including C# with its expression trees) can claim to be partially or fully homoiconic. If the latter, then the list is much smaller.
So would a homoiconic Haskell be a lisp? I think what you'd end up with after taking things far enough wouldn't be Haskell at all. It'd be a lisp with a REALLY good type system.
After all, things like monads and morphisms and applicative functors aren't Haskell, they're mathematics.