Clojurians Log v2

compiler and runtime tests now running and passing

will add some more JS runtimes, self-host, and REPL tests soon

def interested in testing browser REPL, and code splitting in a browser - probably via puppeteer

all the things that really shouldn't break but inevitably get missed because there a lot of things to remember

🎉

Congrats. I've used https://github.com/igrishaev/etaoin for browser testing as well, works fine for all major browsers

is there no uniqueify pass in cljs? that information is kept in a chain of shadow information?

@dpsutton like uniquify a symbol?

one thing to realize is that the pass stuff came very late to ClojureScript

so there might be cases where passes would simplify how things are currently done

the and expansion introduces a let. so i imagine i need to collapse the let and just inline usages of the booleans if i can. so we don't emit (let [x true] (js* "{}~ && {}~" x ...)

so to remove the introduced let need to replace the inline constants with the binding. and to do that need to worry about shadowing. i think the optimizations done at the macroexpansion level are far easier than working on an AST in general.

so I'm not following

the whole point of the macro thing is to remove bindings

so the optimization should throw them away you don't need them

you just need the right hand side

it is true you may need to mark the let with metadata that let's the compiler know it should run an optimization pass on it

(with-meta '(let ...) {:optimize :and}) or something like that

if you see this you know the expression will be a completely regular thing

you can collect all the tests, check that they are all boolean

and then construct the optimized AST if they are

Ah. I was wondering if I could annotate with something to mark that the expansion came from an and

I think that removes the benefit that other forms will benefit from the optimization though

hrm that's true ...

but now that I think about you can probably ignore the let and start with if ?

and just handle the nested conditionals

Ok. I’ll start there but I’m worried we will be emitting closures around the js* form

hrm, why?

note we're looking for a specific pattern here

(if x (let [y exp] (if y ...)) ...)

if isn't that specific pattern ignore it

The let is above the if though

later we can think about different pass

but the let is trivial

this what I'm saying, you're looking for nested if with trivial lets

if the let form is complex, you just bail

Gotcha

Thanks

k I think I have most of the tests running in CI - I did run into trouble with the self-parity tests that I couldn't immediately understand - so that still needs to be done \cc @mfikes