On Wednesday, May 7, 2014 6:37:20 AM UTC-7, Mike Innes wrote:
>
> You could certainly define homoiconicity as "zero syntactical distinction
> between data and code" – Clojure would pass this test because writing code
> and writing a list are exactly the same, whereas Julia would fail it.
>
> This definition is perfectly valid, so the problem isn't that it's
> incorrect so much as that it's a really uninteresting criterion. I for one
> am not nearly as interested in syntax as the ability to produce and
> manipulate expressions, which is something that both languages obviously
> share.
>
I think being able to produce and manipulate expressions means being able
to parse the language into a tree, and then manipulate the tree. Are there
any languages that make it actually impossible to implement a parser for
themselves? Pretty much every language can manipulate trees. Of course once
you've manipulated a tree, you want to be able to execute the new tree, and
not every language has eval, so that at least seems like a useful
distinction.
> Perhaps a better definition would be "the ability to quote language
> expressions", e.g. '(foo x y) or :(foo(x,y)). Clojure and Julia pass,
> JavaScript does not – and that actually tells you something about the
> abilities of the language.
>
Do you see a fundamental distinction between :(foo(x,y)), and parse("foo(x,
y)")? I agree the first one is aesthetically preferable, but they both get
the same job done, right? And it's possible to make the second one in JS,
even though JS doesn't have the first one as a syntactical construct.
Another nice thing that Julia has going for it is that it's very easy to
traverse the AST. Everything is either a leaf, or is an expression with a
head and args, so you can walk the whole tree by walking all the args of
every expression you encounter.
Some ASTs aren't like this: e.g. the JS AST that people are settling on has
different names for the "args" of expressions with different "heads", so
you need a lot more logic to make sure you traverse everything. For
example, their IfStatement has the properties: type (the head), test,
consequent, and alternate (the three args) [1]. You have to know all these
names when you encounter an IfStatement in order to keep walking all of its
children. But that isn't really a feature of the language, it's just a
feature of a particular AST representation that some people are starting to
use. It would certainly be possible to create a more Julia-like AST for JS
without changing the language.
It's hard to talk about things like "the definition of homoiconic" without
appearing to be trolling, but it actually is useful (to me anyway) to get
to the bottom of which features are critical for effective
meta-programming, and which features aren't.
[1]
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Parser_API#Statements
On Wednesday, 7 May 2014 12:48:03 UTC+1, Isaiah wrote:
>
> The word "homoiconic" was removed from the official docs because it was
> not very informative and was occasionally contentious.
>
>
> On Wed, May 7, 2014 at 4:03 AM, Ivar Nesje <iva...@gmail.com> wrote:
>
>> Great!
>> Finally I got a definition of homoiconic that Julia does not fulfill.
>> According to Jason, homoiconicity has nothing to do with language
>> features/standard library features or how you are encouraged to structure
>> your code to get an idiomatic program, but is solely a vague measure of the
>> complexity of the parser for "syntactic code"->AST transformation.
>>
>> By that definition Julia fails, because the syntax is created to be
>> simple humans to write and read to express ideas, and the AST is designed
>> to be easy for a human to work with through a machine. The transformation
>> between is complex and not one to one.
>>
>> Ivar
>>
>>
>> kl. 09:12:44 UTC+2 onsdag 7. mai 2014 skrev Jason Merrill følgende:
>>
>>> Glad to hear that you've been enjoying picking up Julia. I've felt the
>>> same way about Julia having a more gradual on-ramp than some other cool
>>> languages. You don't have to wrap your head around a new paradigm to get
>>> started, but there are lots of nice advanced features waiting for you when
>>> you're ready.
>>>
>>> Re homoiconicity: I know a lot of people have been saying that Julia is
>>> homoiconic, but I don't really buy it. Is the claim that any language that
>>> gives you access to the parser and eval at runtime is homoiconic?
>>>
>>> Let's consider Javascript for a second. 5 years ago, I don't think
>>> anyone would have said that Javascript is homoiconic. But now there are
>>> javascript parsers like Esprima and Acorn written in javascript, so you can
>>> take a string of JS code, parse it into an AST at runtime, traverse and
>>> manipulate the AST the same way you traverse and manipulate other objects,
>>> and then emit and eval new code. Did JS become homoiconic when someone
>>> wrote Esprima? I don't really think so.
>>>
>>> In my mind, syntax is relevant to homoiconicity. For a language to be
>>> homoiconic, the map from syntax to AST should be very simple; or in other
>>> words, the parser should be fairly trivial. This is true of Lisp, but not
>>> really true of Julia. Incidentally, the parsers of concatenative languages
>>> like Forth are even simpler than for Lisp, and more modern concatenative
>>> languages like Joy and Factor take advantage of this in really cool ways.
>>>
>>> All that said, I think the people who say Julia is homoiconic would be
>>> right if they instead said that Julia gives you the power to do most of the
>>> things that people take advantage of homoiconicity to do in homoiconic
>>> languages. Meta-programming Julia really isn't too bad at all.
>>>
>>> On Tuesday, May 6, 2014 8:15:36 PM UTC-7, Abram Demski wrote:
>>>>
>>>> Hi all!
>>>>
>>>> I've been using Julia for a little over a month now, and I thought it
>>>> would be fun/informative to write a little post about my experience.
>>>>
>>>> I'm mostly a Common Lisp guy. I write AI code in an academic setting.
>>>> However, I recently became enthusiastic about Clojure and was trying to
>>>> start a project in that.
>>>>
>>>> Indecisive as usual, I continued poking around looking for the best
>>>> programming language to do the project in, even as I became fairly
>>>> committed to doing it in Clojure.
>>>>
>>>> I had heard about Julia some time ago (looked at it very briefly), but
>>>> looked at it a second time when a friend mentioned it on twitter earlier
>>>> this year.
>>>>
>>>> Looking at it again, I realized that:
>>>>
>>>> 1) Julia is "essentially a Lisp", IE, it is homoiconic (despite not
>>>> appearing so) and has the metaprogramming capabilities I am used to. (I
>>>> don't need these often, but if a language lacks it, I feel like I'm
>>>> missing
>>>> an essential tool.)
>>>> 2) Julia's type system and multiple dispatch capabilities give me much
>>>> of what I liked about Clojure's multimethods and protocols.
>>>> 3) Julia is significantly faster (at least for many things).
>>>>
>>>> I decided to start hacking out my project in Julia, abandoning the
>>>> Clojure code I had started.
>>>>
>>>> After using it for a bit, I feel like it's been much easier to pick up
>>>> what I need to know than it was with Clojure. Both Julia and Clojure have
>>>> the deep, elegant stuff I like in a programming language; however, it
>>>> seems
>>>> like Clojure creates a rich, interlocking set of concepts which you
>>>> *must* learn in order to write very much code, whereas Julia has a
>>>> gentle learning curve, facilitating "normal" programming and allowing the
>>>> user to learn the deeper features as they become useful. At least, that's
>>>> been my feeling.
>>>>
>>>> Monkeying around with the metaprogramming *has* taught me that it's a
>>>> *bit* less convenient than Lisp. Thinking about expr.head and
>>>> expr.args is not as intuitive as composing expressions as lists, I think.
>>>> It's not a big obstacle, though.
>>>>
>>>> I've also found it a bit annoying that array access is not the same as
>>>> function application, again a feature of Clojure. Being able to treat
>>>> arrays and dictionaries as functions is convenient for certain
>>>> higher-order
>>>> functions like map.
>>>>
>>>> Overall, although I admit I'm judging Julia by Lisp/Clojure standards,
>>>> it comes out rather favorably. :)
>>>>
>>>> --
>>>> Abram Demski
>>>> Blog: http://lo-tho.blogspot.com/
>>>> Leave anonymous feedback: http://www.admonymous.com/abramdemski
>>>>
>>>
>
