Clojurians Log v2

The changes to the fn macro are because of (^:async fn ...) support

correct yes

one thing that's been on my mind: we could make async itself not a macro but a special form based on context like catch in try is. So when you use async outside of an async context, you would just get `"Unresolved symbol: async", perhaps with a better location.

Not sure which is best

you mean the testing macro? It wasn't really intended for general usage

no I don't mean the testing macro, I mean the (defmacro async ...)

maybe I'm missing something but isn't this in cljs.test or is that a part of the patch? (sorry in the middle of a close review, so maybe not there yet)

no it's in cljs.core

sorry, I mean defmacro await

so either await as a macro or contextual special form like catch in try/catch

could do, but first thought is that await can see &env - is that only locals or can you get the expr context there? I thought it had the full compiler env unlike in Clojure

it's just a regular CLJS macro so env is whatever all macros get in CLJS. The expr context is in there right now. But it doesn't have to be this way really, we could do without a macro as well

I'm mostly thinking about good error messages when you try to use await outside of an async context

I just mean is there any advantage w/ the special form? I think in CLJS it doesn't make much difference for something this simple - but maybe you have something else in mind I don't see yet?

I guess it's fine how it is now, wrt error messages.

$ clj -M:cljs-repl -m cljs.main -re node
ClojureScript 0.0.1487400309
cljs.user=> (defn foo [] (await 1))
Unexpected error (AssertionError) macroexpanding cljs.core/await at (<cljs repl>:1:14).
Assert failed: await can only be used in async contexts
(:async &env)
cljs.user=> (defn foo [] (catch 1))
WARNING: Use of undeclared Var cljs.user/catch at line 1 <cljs repl>
#'cljs.user/foo

just wanted to share my doubts if await really has to be a macro or not, but it's probably fine

I mean sometimes a macro is simpler, adding a special form is a bit more invasive.

That said it's harder for tooling to understand if you don't have a new AST type.

another benefit of a macro is that the symbol isn't coming out of nowhere

so it does help tooling if we move to special form.

still maybe some more feedback appropriate here before we decide ...

right, we could change it based on feedback, too early to tell I think

I see you allow async assignment to def in the patch? is there a test for that? Does top level async work?

top level async/await doesn't work. in the REPL you can make it work by using a self-calling async fn though. can you point me to what you are referring to?

file and line number

https://github.com/clojure/clojurescript/pull/310/changes#diff-68529abdf99d2186ebe35d927fb683ab9b1a01fb6e841354f697375307a47a60L868

async when def emits var, (note this is a REPL thing only)

I just captured all the IIFE creation with two functions, iife-open and iife-close to be consistent

ok, I will check if this leads to bad code gen in the REPL

let me know, I'm curious what you come up with :)

will do, thanks for doing this - this is fun to review and excited to play w/ it when I have all the notes down

sounds good. at least with iife-open / close we can now track where the implicit iife-s are happening in the code.