Clojurians Log v2

Is there a css parser that can turn css into garden syntax?

@c.westrom I searched for such a thing a couple years ago and found nothing

I thought about trying to write such a thing and looked into it. The first step would be having a parser for CSS that we could use from Clojure. This might be a step in the right direction: https://github.com/phil-brown/jCSS-Parser

I feel like this would be a real game-changer for garden adoption

another option, use clojurescript to do the conversion, and leverage this JS parser https://github.com/shawnbot/sast

Even without ^:export?

> Yes but some build tools don’t support custom readers for CLJS. @p-himik Which tool did you have in mind?

Shadow-cljs

Couldn't find it in the documentation but here's a reference from the relevant issue: https://github.com/thheller/shadow-cljs/issues/272#issuecomment-386865049

So far I’ve been using https://github.com/luke0x/clj-css. But this https://github.com/phil-brown/jCSS-Parser you just linked to me may just be what I need.

(ns wildwestrom.tailwind-garden
  (:gen-class)
  (:require [clj-css.core :as parser]
            [clojure.pprint]))

(def preflight-url "<https://raw.githubusercontent.com/tailwindlabs/tailwindcss/master/src/plugins/css/preflight.css>")

(def tailwind-url "<https://unpkg.com/tailwindcss@^1.0/dist/tailwind.min.css>")

(slurp tailwind-url)

(defn css-to-data
  [source]
  (parser/parse-css (slurp source)))

(def tw-preflight (css-to-data preflight-url))

(def tw-full (css-to-data tailwind-url))

I also found this: https://github.com/emilianbold/netbeans-css-parser Netbeans seems pretty mature. I could probably rewrite the tests in clojure.

https://www.w3.org/Style/CSS/SAC/

What would a proper -equiv look like for a bigdecimal-like type on cljs? https://github.com/funcool/decimal/blob/c0bee2ee62c62a3ba2a80008ec02e01daa0a736e/src/decimal/core.cljs#L752 This is broken because it fails if other is non-numeric I assume we want to be hosty and, unlike on the jvm, copy the fact that in js (= 1 1.0) ? If so .eq does this for us in this case. So does it have to be something like

(and (or (decimal? other) (number? other)) (.eq v other))

Although I guess it's important that this would work if the argument order to = were reversed, so I guess it must return false for other numbers that aren't our custom decimal type

Typically you would like -equiv to be reflexive, symmetric, and transitive, and if you want to be able to use the values as elements in sets or keys in maps, you want hash consistency, i.e. "if (-equiv x y) is true, then (= (hash x) (hash y)) is true". That last one can be difficult to implement, and I wouldn't be surprised if it was one of the reasons that (= 1 1.0) is false in Clojure.

cljs makes some different choices there in the details, and I don't know all of the differences between clj and cljs here.

in clj, = does not work between integer and floating point types, has nothing to do with hash consistency

for historical reference, see https://archive.clojure.org/design-wiki/display/design/Documentation%2Bfor%2B1.3%2BNumerics.html

"The = operator (equality) tests equality. It compares values in a type-independent manner, but not between floating points and integer types. This allows numbers to be used as map keys with correct semantics. To check numerical equivalence between floating point and integer types, use the == (equivalence) operator."

@alexmiller The part that catches my attention in that line that may have to do with hash consistency is "This allows numbers to be used as map keys with correct semantics."

But it isn't necessarily clear to me precisely what "with correct semantics" is intended to mean there.

keep in mind this is design stuff from the 1.3 overhaul of numerics so some of this may be vs the pre-1.3 world

there are some other pages in that vicinity of the design archive with more info, and some old pages that I'm not sure are still available that were on the clojure web site back then too

The reason for my "I wouldn't be surprised if" (meaning, this is my guess), is that it would be really really difficult to make = behave like == for numbers, and also make hash consistent with such a different =, e.g. you would have to figure out how to make hash return the same value for 3/2, double 1.5, float 1.5, etc., even though clj at least tries to return different hash values for 1.51 and other only-slightly-different numeric values. cljs seems to convert all numeric values to the nearest integer before hashing, but clj definitely does not, so this might be easier to do in cljs, at the cost of all numeric value whose floor is the same integer colliding in their hash value.

For example, with Clojure 1.10.1 (and going back further for sure):

$ clj
Clojure 1.10.1
(hash 1.5)
1073217536
(hash 1.51)
-42502948
(hash 1.511)
1778136477

In ClojureScript:

$ cljs
WARNING: When invoking clojure.main, use -M
ClojureScript 1.10.773
(hash 1.5)
1
(hash 1.51)
1
(hash 1.511)
1
(hash 1.01)
1
(hash 1.9)
1

hash consistency is much easier to achieve if you are willing to have lots of collisions 🙂

I mean, if you're using floats as keys in a hashed coll, that's not ever really a good idea (but particularly bad in this case)

Sure, not recommending it. You know I can do angels-on-the-head-of-a-pin discussions with the best of them. I'm not worried about any of this stuff, but much more attuned to it after writing the Clojure guide article on equality.

How can I add props to the & children in a reagent component? I basically have a parent component that takes unknown child components, and I want to add certain props to these children. The React way seems to be calling React.cloneElement(child, {additionalProps: ..})