4 ms·

HTML (and XMLish syntax in general) is LISP syntax (not semantics) in disguise. A tag can be viewed as function application, with the attributes as named argume

HTML (and XMLish syntax in general) is LISP syntax (not semantics) in disguise. A tag can be viewed as function application, with the attributes as named arguments and the elements as variadic arguments. The example from the link's main page is equivalent to: (button "Say something") (on_click (selection-insert-after (div "Hello, World "))) [apparently HN strips all emoji but you get the idea]

lassejansen 9mo ago
Exactly, code is data ;)
- publicdebates 9mo 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.
  - lassejansen 9mo ago
    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.
  - scatbot 9mo ago
    >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.
  - TeMPOraL 9mo ago
    > 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.
dragonwriter 9mo ago
> HTML (and XMLish syntax in general) is LISP syntax (not semantics) in disguise 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.
- embedding-shape 9mo ago
  > 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"))
- npn 9mo ago
  Have you ever tried parsing html in s-expression languages before? For example, in elixir parsing html is this syntax: `{html_tag, attributes, children}`. You indeed can include attributes in s expression
- shakna 9mo ago
  Every Lisp I know of has SXML either baked in, or as a library because it absolutely can represent the fullness of HTML... (parrot (@ (type "African Grey")) (name "Alfie")) Becomes: <parrot type="African Grey"><name>Alfie</name></parrot> https://www.gnu.org/software/guile/manual/html_node/SXML.html https://www.gnu.org/software/guile/manual/html_node/SXML.htm...
  - dragonwriter 9mo ago
    Yes, (HT|X)ML have a semantic model that that can be represented in Lisp syntax, but so does everything else (well, every programming and data representation language, at least.) They don't do it with the same (or simple parallel) single simple syntactic fiundaton as Lisp, but with something more complex.
    - 9mo ago
SkiFire13 9mo ago
I'm not sure I see your point. Yes, you can describe the same meaning/structure with S-expressions and HTML/XML syntax, but that's the complete opposite of having the same syntax, in fact syntax is the difference!
chajath 9mo ago
Fun read! https://wiki.c2.com/?XmlIsaPoorCopyOfEssExpressions https://wiki.c2.com/?XmlIsaPoorCopyOfEssExpressions

lassejansen 9mo ago

Exactly, code is data ;)

publicdebates 9mo 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.
- lassejansen 9mo ago
  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.
- scatbot 9mo ago
  >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.
- TeMPOraL 9mo ago
  > 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.

dragonwriter 9mo ago

> HTML (and XMLish syntax in general) is LISP syntax (not semantics) in disguise 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.

embedding-shape 9mo ago
> 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"))
npn 9mo ago
Have you ever tried parsing html in s-expression languages before? For example, in elixir parsing html is this syntax: `{html_tag, attributes, children}`. You indeed can include attributes in s expression
shakna 9mo ago
Every Lisp I know of has SXML either baked in, or as a library because it absolutely can represent the fullness of HTML... (parrot (@ (type "African Grey")) (name "Alfie")) Becomes: <parrot type="African Grey"><name>Alfie</name></parrot> https://www.gnu.org/software/guile/manual/html_node/SXML.html https://www.gnu.org/software/guile/manual/html_node/SXML.htm...
- dragonwriter 9mo ago
  Yes, (HT|X)ML have a semantic model that that can be represented in Lisp syntax, but so does everything else (well, every programming and data representation language, at least.) They don't do it with the same (or simple parallel) single simple syntactic fiundaton as Lisp, but with something more complex.
  - 9mo ago

SkiFire13 9mo ago

I'm not sure I see your point. Yes, you can describe the same meaning/structure with S-expressions and HTML/XML syntax, but that's the complete opposite of having the same syntax, in fact syntax is the difference!

chajath 9mo ago

Fun read! https://wiki.c2.com/?XmlIsaPoorCopyOfEssExpressions https://wiki.c2.com/?XmlIsaPoorCopyOfEssExpressions