Fork me on GitHub

hmm downside to using the iterator/iterable protocol: objects are not iterable


you have to call keys/values/entries to get an iterator


@lilactown @corasaurus-hex I wonder if we should "beautify" the names a bit so core.js can also be used from other JavaScript projects without typing assoc_BANG! - I'm just not sure what a proper name for it would be :)

Cora (she/her)12:08:39

maybe put mutable and immutable under different namespaces?

Cora (she/her)12:08:01

hmm no then we're just pushing that choice off onto the user


One realization I had later is that using the munged names is actually good if you want to use this stuff from CLJS

Cora (she/her)12:08:49

I'm not super clear on why?


because then you can write:

(:require ["clavascript/core.js" :refer [assoc-in!])


or :as clava + clava/assoc-in!

Cora (she/her)12:08:44

oh, and it knows how to handle the BANG and underscores. cool

Cora (she/her)12:08:04

but also... why would you want to use that from cljs?

Cora (she/her)12:08:23

to work with js structures directly I guess?


yeah, this issue is probably not that important, the primary use case for the lib is to be used from clavascripts...

Cora (she/her)12:08:54

makes sense, thanks for explaining:)


@lilactown Looking at your PR for a couple of hours now.. Running into this problem:


hmm. i can remove the + function from that PR


I think I might know what's going on, perhaps. It's a weird interaction between advanced compilation and this PLUS function that was added, but perhaps maybe only in the test build...


Instead of 1 + 2 + 3 the compiler now generates 1 _PLUS_ 2 _PLUS_ 3 as if the stringified symbol is optimized to the munged version


i was wondering how special form and function collisions would work. i was happy to see that it both generated infix when it could and used the function when passed as a value in test


yes, in call position it prefers the inline thing


The reduce PR was really cool


found a cute way of getting a "REPL"

echo '' | fzf --print-query --preview './node_cli.js --show -e {q}'
h/t @rayatrahman9 for the fzf life pro tip


well, more like a read-eval loop. still figuring out how to wrap the {q} in a println


Link to gist or something? We can extract the preview code to a script that can print something prettier if the code has an error, or something that colors the output if the user has bat, etc installed


Just for fun: brew install bat echo '' | fzf --preview './read-eval-print {q} *| _bat -l javascript_*' --preview-window Lmk if that looks interesting to ya


should I commit this in lieu of an actual REPL?


What's the benefit of doing this over using the browser playground?


idk, I've been using the CLI

Cora (she/her)19:08:25

I don't really have an opinion on it (I know, I'm helpful)

Cora (she/her)19:08:25

it would be nice if we could add syntax literals for js maps

Cora (she/her)19:08:43

there's #<key val> or #[key val] or maybe something else?

Cora (she/her)19:08:01

it's such a pain point

Cora (she/her)20:08:52

I know I'd use more maps in js if they weren't such a pain to use

Cora (she/her)20:08:06

a syntax like this might be nice Map#{ key val }

Cora (she/her)20:08:36 is a very old thread of people talking about map literals for js. it's interesting

Cora (she/her)20:08:31

I suppose it could just be a macro at that point, really. I just hate (js/Map [[key1 val1] [key2 val2] [key3 val3]])


@corasaurus-hex I'd like to learn more about what people are using Maps for instead of objects. Can you share? I think we could have a reader macro like #js/map {:k v} or just #map {:a 1} or so. Technically this isn't hard, but it's good to discuss stuff to make an informed decision on that

Cora (she/her)21:08:28

maps are used when you need to use non-string keys, mostly. objects have all sorts of pitfalls around keys like automatic conversion to strings and the potential for prototype pollution, too

Cora (she/her)21:08:10

> a = {}
> a[1] = 2
> a
{ '1': 2 }
> b = new Map()
Map(0) {}
> b.set(1, 2)
Map(1) { 1 => 2 }
> b
Map(1) { 1 => 2 }

Cora (she/her)21:08:45

I'm just breezing through some calva code realizing that there are probably instances that would be vulnerable to prototype pollution due to the use of objects instead of maps 😬


So, most JS APIs work with objects right? Are you using Maps for like say, internal app data?

Cora (she/her)21:08:41

yes, exactly that


Would you say that using #map {[1 2 3] [4 5 6]} would be a nice notation?

Cora (she/her)21:08:15

like in clojure you mostly use maps with string or keyword keys but sometimes you need lookup maps using keys that aren't either of those


(bad example probably since you don't look up arrays by equality but by reference, but just for the idea)

Cora (she/her)21:08:06

I think #map { key1 val1 key2 val2 key3 val3 } if that's what you mean

Cora (she/her)21:08:59

and like you just hinted, you need to be really careful with reference equality

Cora (she/her)21:08:27

in one of my recent projects we hand-rolled a deep-equals map


isn't it about time you just include immutablejs or lodash etc then?

Cora (she/her)21:08:45

we have lodash, but it doesn't give you a deep-equals map (where the keys are compared with deep-equals)


isEqual doesn't support that? hm

Cora (she/her)21:08:53

we use isEqual in there

Cora (she/her)21:08:00

it's gross but it gets the job done (for sufficiently small maps where this nonsense isn't too expensive)