Fork me on GitHub

just fyi, there is a new #observability channel, for monitoring, logging, traces, alerting and higher level observability discussions :)

👍 12

core.match lists a paper which mentions an optimizing compiler for a backtracking automata based matching solution. I could never find a copy of the referenced paper except the ACM archives are free to use now so its finally online for free if anyone is interested.

😯 4

The tradeoff is one of code size versus run-time speed. Since core.match can throw some methodsize too large errors I wonder if this might be useful


How do HTML relates with XML? HTML is a "superset" of XML? There is a subset of HTML that is XML, and all HTML features are accessible from this subset? Context: I'm planning to do a SSR library in clojure and thinking if use will be a powerful choice

Alex Miller (Clojure team)19:04:24

they are both markup languages but in general you should not expect to be able to parse html with an xml lib


I thought the relationship was that XML and HTML had a common ancestor of SGML, but diverge from there


I seem to remember there being a variant called XHTML that was supposed to be XML-compliant HTML, but I don’t think it ever went anywhere.


I think that the options are:

(mylib/render ctx data) 
;; 1 => "<html>string</html>" ;; bad :(
;; 2 => [:html "hiccup-like"] ;; meh
;; 3 =>{:tag :html :content "will be useful?"} ;; ??
;; 4 => #object["something like j2html representation"]
;; 5 - comments

1️⃣ 4
2️⃣ 4
3️⃣ 4
4️⃣ 4
5️⃣ 4

Looking for Should be possible (and useful) to write a XHTML =xml/parse=> =custom-emit=> HTML


I will use XHTML for now and maybe a custom-emit


Any reason why you don’t like hiccup syntax? To me it seems a lot more succinct.


hiccup is nice to write/type, but i don't think that it's a good programmatic representation


You mean like it lacks something? Or it’s just too easy? 🙂


if you are manipulating it (creating it, but taking it and changing it) you constantly have to be checking if the second thing in a vector is a map or not


True. Would XHTML be better for that?


even though it is represented as data, it is a data format that is geared towards humans reading and writing it


it depends, xhtml is a serialization format, and you won't be directly manipulating that


you will be manipulating some data representation


the map representation uses is pretty good


(instaparse has a switch to do hiccup or map style parse trees)


I’m asking mostly out of idle curiosity, I don’t have a stake one way or another, but I’ve always found hiccup the easiest HTML-adjacent syntax to work with, so I’m surprised and interested in hearing about situations where it is arguably less than ideal.


it works very well if you are sort of top down building a page from fragments, it works worse if you then take that page and want to change some nested thing it

👆 4

there is also hickory that converts between hiccup style and data.xml style . I have used it for small things in past for editing html


Ok, so working with {:tag :div :attrs {:foo 1}} kind of stuff as opposed to [:div {:foo 1}]

Alex Miller (Clojure team)19:04:25

the biggest downside to programmatic use of hiccup is probably that it's at least partially positional

☝️ 12
💯 4

if I’m remembering data.xml style right


hiccup is a PITA to work with programmatically

Alex Miller (Clojure team)19:04:13

positional stuff tends to be more compact and easier for people (b/c it's implicit) but harder for programs (b/c it's implicit) - usually maps are better there

Alex Miller (Clojure team)19:04:39

(spec 2 has a map syntax too)

👏 4

With a poor benchmark, hiccup "emit" is 2x faster then data.xml


i thought much of the programmatic pain was alleviated by first normalizing any hiccup data before manipulating it?


I wrote a simple function that takes a vector of args and breaks it into opts and children based on whether or not the first value was a map. That made it pretty easy for me to work with hiccup for the use cases I was concerned with.


(let [normalize-hiccup (fn normalize-hiccup [[tag & [attrs :as vs] :as element]]
                         (let [has-attrs? (map? attrs)
                               v {:tag      tag
                                  :attrs    (when has-attrs?
                                  :children (map normalize-hiccup (if has-attrs?
                                                                    (rest vs)
                             (first [this]
                             (valAt [this key]
                               (key v))
                             (valAt [this key not-found]
                               (key v not-found))
                             (nth [this i]
                               (nth element i))
                             (nth [this i not-found]
                               (nth element i not-found)))))
      hiccup (normalize-hiccup [:div {:foo 42}
                                [:div {}]])]
  {:as-hiccup (nth hiccup 1)
   :as-map    (:attrs hiccup)})
Just for fun

Kelsey Sorrels21:04:37

Can you license this? I want to use it in a project I'm working on.

👍 4

though that was more for generating hiccup than manipulating it, now I think of it.


but it seems like it wouldn’t be too hard to build on that to convert hiccup to data.xml-ish maps.