Hi, I saw cljs.core.specs.alpha ns being added in the repo, but that doesn't seem to be included in the latest released CLJS jar. Is it intended?

@athos there has not been a release that includes this yet

Haha, right:sweat_smile: I thought 1.9.946 was released after that.

Should CLJS accept more values for compare? The JS standard says that if an object has a valueOf function it needs to return a primitive value. So as long as the types are the same and they both have a valueOf fn they can be passed to garr/defaultCompare. Probably not an issue for many, this just came up in Datascript which is used by some JS folks... (which uses compare a lot)

@rauh sure file a ticket

I have run across David's post about combining JS generators and channels and found it fascinating (thanks!) especially in lumo where andare takes a while to compile. I was wondering if there is a way for ClojureScript to emit generator functions (or objects) - the GCC should support compiling them down. Sorry if it's an old question 😃

Oh I see I can build one: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/GeneratorFunction

no I can't apparently

CLJS emits ES3 so there is no official way to use ES7 features

@thheller GCC accepts ES6 in input though (aren't generators ES6?)

besides that the go macro does pretty much the same thing the closure compiler does to generator funcs

I know, but as I wrote above, andare is pretty slow to compile because of all the macros

so for me there is value in using an alternative

pretty sure andare still is faster than using CLJS+Closure to optimize?

not sure I understand the last sentence 😄

but why is compile time the issue? runtime should be all that matters no?

No well, I am producing JS, in a self-host like lumo

I compile down and macros are slow to compile

you can cache of course

still, directly use JS libraries like js.csp would be waaay faster

(of course)

what are you building where compile time is the main problem?

I in "exploratory" mode, if compile time can be reduced and I can obtain the same behaviors, that's a win

if not, I will go back using andare

also, in JS-centric work-places they don't like compile time 😄

I played with a few JS tools the last few days and I can say that CLJS compiler is just as fast as many JS tools or even faster

webpack in particular is slow compared to CLJS … IF you properly deal with startup time

right, we use node server side so no webpack

I don’t buy the speed argument anymore 😛

note that "compile time" is also valid in the REPL in lumo because of its self-hosted nature

well yeah self-hosted is slower but it should work fine in lumo with proper caching no?

yep, as I said, just exploring...On another note, and not directed to you Thomas in particular I don't like to answer questions without motivation. If a colleague asks me "Can we use generators in ClojureScript", I try to find a reason...technical maybe...and I don't like to just say, no you can't, go use andare 😄

I need to politically handle things like language adoption here

that's also part of the issue maybe 😉

ok, that argument I can understand but just dismissing what CLJS provides based on compile time seems counter productive

agree with you, and probably I should have added both motivations in there...anyways not a big deal, I will answer "go use andare" anyways 😄

the issue with generators is that CLJS sometimes generates extra functions to isolate scope and such

that breaks with generator functions if they don’t expect that

I think doseq and for do that a lot

uhm ok, I tried but it does not seem to be there:

cljs.user=> (new js/GeneratorFunction "test1" "test2")
GeneratorFunction is not defined
	 (evalmachine.<anonymous>:1:1)
	 ContextifyScript.Script.runInThisContext (vm.cljs:50:33)
	 Object.runInThisContext (vm.cljs:152:38)

thanks for your explanation

IIRC generators just return objects that have a next function, similar to lazy-seq

yep I was reading that today

the REPL probably does not "read" ES6, don't even know how to enable that actually

so from an interop perspective do you want to pass an object to JS to acts like a generator

or consume one via CLJS?

I need to pass a GeneratorFunction to JS code called within CLJS

@richiardiandrea Pretty sure you can just pass them an es6 iterable which we support for all collections.

so this works:

cljs.user=> (.constructor (.getPrototypeOf js/Object (js* "function*(){}")))
Evaluating (.constructor (.getPrototypeOf js/Object (js* "function*(){}")))
Object.getPrototypeOf(function*(){}).constructor()
#object[anonymous]

You wouldn't use their go, you'd have to use spawn, go will first invoke the fn

yep thanks it's cool that I can do that 😉

It's all just ES6 iterators: https://github.com/ubolonton/js-csp/blob/master/src/impl/process.js#L95

probably not worth ending up in core, it is one line basically, I can live with it 😉

I don’t think there is anything special about GeneratorFunction other than that its a function you cannot new.

tracked things here: https://github.com/anmonteiro/lumo/issues/345