Hacker News Reader

Comment by velcrovan | Hacker News Reader

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]

View on HN

> 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.

> 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"))

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

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.htm...

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.

... I'd call that simple, without complex additions. You're not exactly requiring a parser, here.

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!

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

Exactly, code is data ;)

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.

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.

>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.

> 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.

Reply on news.ycombinator.com