To expand a little on this, the article shows the parsed AST:<p><pre><code>   {
     type: &#x27;function&#x27;,
     value: &#x27;defn&#x27;,
     children: [ 
       { type: &#x27;function_name&#x27;, value: &#x27;average&#x27; },
       { type: &#x27;arguments&#x27;, children: [
                             { value: &#x27;x&#x27; },
                             { value: &#x27;y&#x27;}
                            ]
       },
       { type: &#x27;function&#x27;, value: &#x27;&#x2F;&#x27;, children: [...] }
     ]
   }
</code></pre>
The parenthesis-based surface syntax is directly translated into the above, which is IMO more verbose and contains no additional information. On the other hand, it is valid Javascript data.<p>So it looks like it is equivalent to manipulate the above form. Now, suppose you want to define a function which returns a form which performs a function call. We won&#x27;t use macros, but simply a function that builds an AST. We can&#x27;t write Javascript directly with this parser, so let&#x27;s say there are primitive Lispy functions to build equivalent javascript trees:<p><pre><code>    (defn my-funcall ()
      (js%hash (js%kv &quot;type&quot; &quot;function&quot;)
               (js%kv &quot;value&quot; &quot;my-fn&quot;)
               (js%kv &quot;children&quot;
                      (js%vector 
                        (js%hash 
                          (js%kv &quot;value&quot; 3))))))

</code></pre>
... whereas, a lisp-based approach would be:<p><pre><code>    (defn my-function (list &#x27;my-fun 3))</code></pre>