Live data from Hacker News

Produce HTML from S-Expressions

github.com

21–30 of 63 posts

Re: Produce HTML from S-Expressions

#21
post #2

(h1 :disabled Hello world!) (div :class="alert" So long, and (b thanks) for all the (em fish)) I hate that syntax for attributes. :class="alert" is strictly worse than ((class . "alert")) or any other variation that actually leverages s-expressions instead of merging key and value into the same symbol. Ew. Not a fan of the bare words instead of strings either, which means this cannot be naively evaluated by a Lisp. I…

> :class="alert" is strictly worse than ((class . "alert")) or any other variation that actually leverages s-expressions instead of merging key and value into the same symbol. Ew. I hear you, but I wasn't aiming for leveraging the power of macros. Using `((class . "alert"))` does not provide any benefits over :class="alert". > Not a fan of the bare words instead of strings either, which means this cannot be naively e…

This might be okay too?

  (div (class "alert") So long, and (b thanks) for all the (em fish))
or

  (div {class "alert"} So long, and (b thanks) for all the (em fish))

Re: Produce HTML from S-Expressions

#22
post #18

I actually really love this. I much prefer this over HTML syntax. Add a way to do custom tags and imports and this becomes a very, very neat static site generation tool.

> Add a way to do custom tags

I don't know what that means - it currently uses the first element of the list as the tagname, so you can use whatever tags you want to.

> and imports and this becomes a very, very neat static site generation tool.

I've toyed with the idea of adding more functionality (like imports, environment variables, conditionals, etc).

Not too sure I want to go in that direction.

Re: Produce HTML from S-Expressions

#23

Nice, thanks for sharing. Curious what your motivation was for making it. Perhaps include a "why" at the start of the repo. As evidenced by some comments, depending on whether the goal was to write HTML with a lisp compatible syntax, vs, a more concise but simple xml alternative, it creates different expectations. Personally I'm just interested from a parser/ compiler perspective.

> Curious what your motivation was for making it. Perhaps include a "why" at the start of the repo. As evidenced by some comments, depending on whether the goal was to write HTML with a lisp compatible syntax, vs, a more concise but simple xml alternative, it creates different expectations.

You are quite correct, my goal appeared to be "Lisp interpreted HTML", my actual goal is "Write HTML tag trees easier".

Re: Produce HTML from S-Expressions

#24
post #21

Earlier quoted context omitted.

> :class="alert" is strictly worse than ((class . "alert")) or any other variation that actually leverages s-expressions instead of merging key and value into the same symbol. Ew. I hear you, but I wasn't aiming for leveraging the power of macros. Using `((class . "alert"))` does not provide any benefits over :class="alert". > Not a fan of the bare words instead of strings either, which means this cannot be naively e…

This might be okay too? (div (class "alert") So long, and (b thanks) for all the (em fish)) or (div {class "alert"} So long, and (b thanks) for all the (em fish))

Personally, i'd go with

   (div (class [alert someothercss]) [so long and (b [thanks]) for all the (em [fish and chips])])

Re: Produce HTML from S-Expressions

#26
The Scheme community seemed to standardize on Oleg Kiselyov's SXML format for XML and HTML: https://en.wikipedia.org/wiki/SXML

The initial driver for adoption was that Oleg made an excellent XML parser (SSAX) that used SXML. Then a bunch of people (including me) built new tools to work with SXML, and changed existing tools to use it.

Later, I realized that SXML permitting unnecessary list nesting, which initially seemed sloppy and inefficient, actually has a very useful efficiency property, once you're using immutable lists: you can compose larger XML with a small allocation and no mutation like:

    (list some-huge-tree another-huge-tree)
Racket-specific starting point: https://docs.racket-lang.org/sxml-intro/index.html

Re: Produce HTML from S-Expressions

#28
If one uses the XML tree of the XHTML as the primary internal representation instead of S-expressions, no conversion is needed at all, as XHTML can be viewed in the browser simply by associating a CSS style sheet via "rel".

Nothing is a faster converter than avoiding a conversion step altogether... but that is not why I did it; I used that technique in my Ph.D. thesis back in 2007 [1,2] to avoid directories full with hundreds of auxiliary files (xml/ html.tmp/ ..), which may be confusing to manage, slow to copy, and eventually lead to the file system running out of i-nodes.

EDIT:

[1] https://www.sciencedirect.com/science/article/abs/pii/S01989...

[2] pp. 132-134 in https://era.ed.ac.uk/bitstream/handle/1842/1849/leidner-2007...

Re: Produce HTML from S-Expressions

#29
Hiccup syntax for Clojure uses hash maps (curly braces) for attrs, e.g. `{:style {:background "red" :margin "1em"}}`

See Reagent which uses Hiccup syntax: https://reagent-project.github.io/

    (defn simple-component []
      [:div
       [:p "I am a component!"]
       [:p.someclass
        "I have " [:strong "bold"]
        [:span {:style {:color "red"}} " and red "] "text."]])

Re: Produce HTML from S-Expressions

#30
post #15

Reminds me of hyperscript like in https://mithril.js.org m("h1", {class: "title"}, "My first app")

Yep. Also it’s worth mentioning that that’s the signature of React.createElement

Here’s a simplified implementation: https://github.com/uxtely/js-utils/tree/main/react-create-el...

Post reply on HN