This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-08-17
Channels
- # announcements (1)
- # babashka (21)
- # beginners (46)
- # calva (21)
- # cherry (10)
- # cider (5)
- # clojure (54)
- # clojure-europe (16)
- # clojure-nl (2)
- # clojure-norway (37)
- # clojure-spec (7)
- # clojure-uk (4)
- # clojurescript (30)
- # conjure (3)
- # cursive (1)
- # datalog (5)
- # datascript (3)
- # datomic (13)
- # emacs (5)
- # fulcro (82)
- # girouette (1)
- # helix (4)
- # hyperfiddle (2)
- # joyride (1)
- # juxt (1)
- # kaocha (4)
- # lambdaisland (3)
- # luminus (1)
- # malli (15)
- # off-topic (60)
- # pathom (3)
- # polylith (1)
- # practicalli (3)
- # releases (1)
- # ring (4)
- # sql (3)
- # squint (85)
hmmm not sure how to check out tree-shaking to see what it's doing
npx esbuild <compiled-script.mjs> --bundle --minify --platform=node --outfile=dist/index.mjs --format=esm
I'm wondering if a separate compiler is needed, or just an alternate cljs.core? If you subbed a cljs.core where hashmap created a JS object, list a JS array, etc. And it made no use of Google Closure. Wouldn't that give the same result?
@didibus Yes, the compiler core can be the same between cherry and clavascript, with minor differences
There will also be differences between macroexpansion of doseq
etc, so it's not just the core lib that will be different
the only reason I would want to think of alternatives is that it's too close to #calva
how about some kind of riff on cherry?
like berry or something
What I intend with the name clavascript: it's inspired (and built) with CLJS but the semantics are JavaScript (use the platform, no custom datastructures that you have to convert between when doing interop). I think with that in mind, the name makes sense. Just wanted to double check if clavascript wasn't too lame.
you could call it blossom
so we have cherry and blossom
cranberry?
are we trying to stick with fruit? 😜
that's true
¯\(ツ)/¯
What about the name licorice? lilactown + cora + hmm, it doesn't make sense beyond that ;)
I do love licorice (to the chagrin of everyone who spends a large amount of time with me, they all hate it)
and I hate it 😂
and we all have a love/hate relationship with js
I guess the good thing about clavascript is that it's a unique name and you will hit the right github repo when you search for it
you could name it cloy 🤪
Typescript is a language and tsc
is a program that converts typescript to javascript (I think). Does Clavascript refer to the language or the program? Traditionally, I consider javascript, typescript, coffeescript, actionscript, applescript, all refer to the language/syntax. I consider cherry, shadow-cljs, nbb, etc, refer to the program. But I think here, it's still just 'clojurescript', right? And Clavascript is the program? If so, I think that's a departure from convention.
No, clavascript is the language :) It's a dialect of CLJS which transpiles directly to JavaScript's built-in data structures. The program is called clava
.
Do you think there'll be any way to share code between Clojure and ClavaScript in cljc files? Or will the semantics end up so different probably not?
Since Clava is based on mutable native data structures, it might be a nice language to do Advent of Code in (and then compare performance against regular CLJS would be interesting too). Also, doing those Advent of Code puzzles might be a nice way to detect bugs in Clava :)
tbh I've been thinking about something like clavascript for a long time. you've built a beautiful foundation for me to play with 🙂 I appreciate the work you've put into building all of that and how open you are to collaborate
I'd be happy to add you as a core team developer since you've contributed some pretty awesome core ideas to the core library
you too @corasaurus-hex?
sure!!
I'll still expect to wait until one of you review my changes before I merge a PR
Yes, let's do that. I just love the idea of clava being a we thing instead of a me thing
I've moved cherry to the github org now and will pull out the common compiler parts so they can be re-used (and things will work consistently between the two: jsx, etc)

@U4YGF4NGM @corasaurus-hex Hmm, part of me wants to keep the compiler just as it is now, since we can then freely make changes to everything in either cherry or clavascript, but bug fixes in the compiler namespace will have to be made twice.
would it make sense to keep them separate for a while until we flesh out the languages more and then see how best to merge them (or not merge them) later
or we could have a goog-define thing that says: I'm using this from cherry or clava and then do something different based on that, or perhaps a macro or so
if we merge them then it's only a few more steps until we have a clojure-ish language toolkit 😅
we can wait until bug fixes are painful across them? Im a fan of delaying work until we're sure we want to do it (or sure we want to spike on it)
feels like it might be smart to plan for interop to make plan a little for the immutable data structures coming to js eventually here
Not sure what to do about those. I think similar to #map {:a 1}
we could support #immutable-map {:a 1}
(with a shorter name) and add support to assoc
and friends to return another immutable version (but perhaps this will already work since those TC39s will support the spread stuff?)
And btw, this is just a proposal right now, there's still a change that it won't make it and it will take a long time before we will probably see this "everywhere"?
still a chance, for sure. my understanding is that it's likely but still tentative.
I can't remember where I learned that ... maybe my brain just really wants it to be true
I like going the same route as map
#rec and #tup or something
is undefined something we want to represent in the language? the distinction between nil and undefined can matter sometimes
it might especially matter for interop
oh, js/undefined, cool
thanks
even undefined
works, but js/undefined
works better with clj-kondo, etc and is standard CLJS syntax
it's been so long since I used cljs, this is great to know
Now working on JSX again. I think I've got the right approach this time:
$ ./node_cli.js --no-run --show -e '(defn App [] (let [x 1] #jsx [:a {:href x} "dude"]))'
var App = function () {
let x1 = 1;
return <a href=x1>"dude"</a>
;
};
export { App }
The only thing here is, when should we emit { x1 }
- we could try to "autodetect" this since in CLJS you will use strings instead of symbols for raw text anyway. On the other hand, being explicit is more in line with that JSX does:
(defn App [] (let [x 1] #jsx [:a {:href ~x} "dude"]))
E.g. we could use ~
to escape the JSX-mode. I'll have to play around with this. Off to bed now.