[HN Gopher] Produce HTML from S-Expressions
___________________________________________________________________
Produce HTML from S-Expressions
Author : lelanthran
Score : 28 points
Date : 2023-08-30 12:13 UTC (10 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| fabiofzero wrote:
| Basically Haml then.
| iLemming wrote:
| Haml is not homoiconic. It's like saying "the flask is
| basically a teapot". Sure, they both can serve similar
| purposes, but categorically they are very different things.
| They look different, they are usually made of different
| materials, and they are used very differently. So, no, it's not
| "Basically Haml"
| brabel wrote:
| There are so many of these already:
| https://cliki.net/html%20generator
|
| And still I can't find one that I like (which is why I also wrote
| one myself :D).
| fouc wrote:
| Reminds me of hyperscript like in https://mithril.js.org
| m("h1", {class: "title"}, "My first app")
| sph wrote:
| (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 wouldn't say this is producing html from s-exps, rather that it
| is vaguely inspired by them.
| messe wrote:
| > Not a fan of the bare words instead of strings either
|
| It _is_ consistent with HTML however, especially the fact that
| both collapse whitespace.
| giraffe_lady wrote:
| Pollen's tagged xexp is probably the most sophisticated
| approach to this I've seen. Though hiccup is about as good and
| easier to work with. https://docs.racket-
| lang.org/txexpr/index.html
| KRAKRISMOTT wrote:
| Like this amirite
|
| https://github.com/weavejester/hiccup
| xemoka wrote:
| The thi.ng umbrella has a hiccup variant for JS that looks
| pretty neat too: https://thi.ng/hiccup
| Zambyte wrote:
| > Not a fan of the bare words instead of strings either, which
| means this cannot be naively evaluated by a Lisp.
|
| Most Lisps (all that I know of) have a way to convert symbols
| to strings. The hard part is resolving the ambiguity between
| what should be text, and what should be treated as an HTML
| node. Like, what if I wanted to actually write the string "(b
| thanks)" on a page? R7RS could probably do this with the pipe
| identifier syntax[0], but I think R7RS is fairly unique in its
| capability for identifiers (and thus symbols) with such a wide
| range of supported characters.
|
| [0] https://standards.scheme.org/corrected-r7rs/r7rs-
| Z-H-4.html#...
| sph wrote:
| Bare words are fine until you have a variable with the same
| name as your bare word, so you need additional syntax to
| determine if you're referencing a variable, or it is just
| text.
| lelanthran wrote:
| > Bare words are fine until you have a variable with the
| same name as your bare word, so you need additional syntax
| to determine if you're referencing a variable, or it is
| just text.
|
| This doesn't have variables. Or functions.
| lelanthran wrote:
| > :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 evaluated by a Lisp.
|
| I traded off ergonomics against "Evaluation by a Lisp
| processor".Instead of (div "My first " (b
| "hello") (em " world"))
|
| I'd rather do (div My first (b hello) (em
| world))
|
| Thank you for your input.
| sph wrote:
| > Using `((class . "alert"))` does not provide any benefits
| over :class="alert".
|
| Of course it does. It is a s-exp, like everything else in
| this language, so it's just another list you can map, apply
| or otherwise transform. The keyword approach instead requires
| a weird incantation of (string-trim (cadr
| (string-split (keyword->string :class="alert") ?=)) ?")
|
| to extract the value from the attribute. For what benefit? If
| the goal is using s-exps, why not use s-exps for everything?
| lelanthran wrote:
| > If the goal is using s-exps, why not use s-exps for
| everything?
|
| My goal wasn't "Use s-expressions", it's "More readable and
| writable HTML trees."
|
| This isn't a Lisp interpreter either, TBH. There's plenty
| of those around and they require the user to use a Lisp
| implementation, and write Lisp code.
|
| map, string-trim, car, cadr etc are not required for
| s-expressions, they're required for Lisp.
| bjoli wrote:
| I your aready using a scheme you can use SXML. The tooling makes
| XML fun.
| junon wrote:
| 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.
| leumassuehtam wrote:
| Shameless plug of a similar idea to embed lisp into LaTeX files.
|
| https://github.com/keyehzy/lispylatex
| datastack wrote:
| 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.
___________________________________________________________________
(page generated 2023-08-30 23:02 UTC)