No, its not. If it was, the attribute vs. child element distinction would not exist. HTML (and HTML-inspired XML) syntax is not a trivial alternative to S-expression syntax, it is more complex with additional distinctions.
A simplified subset of (HT|X)ML that uses only elements and no attributes is pretty much directyl equivalent to S-expressions, sure.
Add one more type, like a map, now you have attributes
(fn btn ()
(div
{onClick (fn ())}
"Click me"))For example, in elixir parsing html is this syntax: `{html_tag, attributes, children}`.
You indeed can include attributes in s expression
(parrot (@ (type "African Grey")) (name "Alfie"))
<parrot type="African Grey"><name>Alfie</name></parrot>
But I do think s-expressions are an improvement over HTML in certain scenarios.
That said (talking to OP now), why is the control handler outside the button?
In actual HTML, we have [button onclick="codeToBeEvaled()"]
In this thing, you have [button][onclick [sub-expressions]]
With s-expressions, at least you have some semblance of function calls, which would make control flow operators seem slightly more natural, but this hybrid of semantic and syntactic choice just seems bizarrely limited.
I agree. S expressions are a data interchange format. HTML is a markup language. They solve different problems.
S expressions define nested lists of atoms. HTML describes semantic hypertext documents defined by a document tree made of element nodes as subtrees, attribute nodes as subtree metadata, and text nodes. In some scenarios a uniform data structure like s expressions is nicer to work with.
To be honest it boggles my mind that XML was ever used as a universal data format.
"Code is data" is more general and fundamental idea; it's a fact of nature. Homoiconicity is a way to try and embrace it instead of fighting it.
The example from the link's main page is equivalent to:
[apparently HN strips all emoji but you get the idea]