Comment by publicdebates
5 hours ago
Not sure how homoiconicity is related to this at all. Macros don't seem involved.
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.
> Not sure how homoiconicity is related to this at all. Macros don't seem involved.
"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.
>But I do think s-expressions are an improvement over HTML in certain scenarios.
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.
For most tags you can also put the event handlers as first children inside the element, but self-closing tags like <input> don't support that. I'm now putting the event handlers always outside (as next siblings) for consistency.