Clojurians Log v2

Ah, ...args this is why you were saying ES-2016 moving forward :)

yeah ...args + Reflect is fast

we don't need to know anything now - i.e. :param-tags

yeah I've also been using Reflect.construct in SCI since forever

#?(:cljs
   (defn invoke-js-constructor* [ctx bindings constructor args]
     (js/Reflect.construct constructor (.map args #(sci.impl.types/eval % ctx bindings)))))

(I even forgot I had it in there)

yeah we avoided for the obvious reasons, too new, and in the beginning not efficient. But time to move ahead now.

If ES6 is now the minimum, I also could've stayed with emitting string templates in the str optimization. Not that it matters much probably

in squint I do emit them since I assume ES6 there

yeah I think anything in ES 2016 is fair game.

for people who need earlier support 1.12.42 has plenty of power and stability

(let [x 10]
  (str 1 2 3 x))

let x2 = 10;
`123${x2}

let isn't faster than var

the point here isn't let vs var, it's the string template

I haven't followed, the string template thing whether it's actually any faster

mostly only care about ES 2016 features that are faster or let us achieve some special

I haven't noticed any perf difference, just liked reading the output better :)

hehe, yeah not a priority

I thought CLJS maintained emitting old JS because it had to run on some special devices with old JS engines or so. But I'm not complaining about bumping to ES6

well in past there was no reason to use new features because it just complicates things. But also engines historically were only fast on the old specification of the language

finally there are perf wins in ES 2016

but they are in strange places

(wrt. CLJS)

ES6 also was the version that introduced import. Does GC now actually support this? I remember it having trouble with this

or maybe it was just dynamic import

In squint I emit ES6 modules by default (not because they're cool, just because they are expected in the JS world). One huge problem with this is that you can't set! vars in other namespaces because ES6 modules don't allow this.

We're never going to do anything with ES6 modules, Google doesn't care about it - it's a hassle for DCE, they compile it away internally.

Reflect makes doing any thing about ES6 classes less interesting.

generators, async still curious about especially if the later can simplify cljs.core.async

generators are nice :lite-mode , interop laziness w/o our machinery

yep, Reflect is a great tool when you need it for await...of did remind me a lot of core.async channels

with machinery do you mean, the go macro?

Yeah

Oh no for generator I mean the interop methods for JS are not lazy which is annoying - keys entities etc

Using map etc pulls in stuff. But if we could return generators could be lazy and lighter

that's how squint implements laziness

JS api for functional operators on generators is coming

Nice - squint is definitely giving me some inspiration

one difference with CLJS here is that lazy seqs aren't cached

For interop that is ok

I have a setting where you get a warning where a lazy seq is realized multiple times so you can iron that out. I haven't actually seen that many cases. Most often a lazy seq is just iterated once in typical programs

you can iterate them multiple times in squint, but the results are re-calculated

when you want to cache you just turn it into an array first.

credit where credit is due, @lilactown came up with that idea

ok, that's interesting indeed. es6 iterables seem to support .map etc. https://squint-cljs.github.io/squint/?src=gzip%3AH4sIAAAAAAAAE9MoS01W0NDLTSxQ0EgtNtPNLEktSizJL1LQAAll5iUrRBsqGCkYx2pqgniamgCyQJNXMQAAAA%3D%3D

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Iterator#instance_properties

Pretty sure all of the Iterator api should work

concat is a proposal that is coming I believe