alter-meta!’s docstring says: Atomically sets the metadata for a namespace/var/ref/agent/atom

it doesn’t seem to work for Vars, though

because it call this: (set! (.-meta iref) (apply f (.-meta iref) args)) and the Var deftype doesn’t have a meta field, but _meta instead

is this known/expected or should I file a JIRA ticket?

the same for reset-meta!

it seems that the bigger issue is that they're not backed by a protocol

in clj alterMeta and resetMeta are found in the IReference interface

cljs does have IWithMeta which is essentially clj's IObj but it seems to be missing the abstraction for objects with mutable metadata, IReference

@bronsa: so in a perfect world alter-meta! and reset-meta! would just defer to alterMeta and resetMeta or whatever we’d end up calling it in the IReference protocol?

seems cleaner

my guess is these functions predate the Var implementation and they worked fine just for atoms

@mfikes: re 1668, we actually need to be able to write two specs, one for the runtime and one for the macro syntax checking

so what I’m suggesting is to just have fdef be macro ns aware so we can define the spec twice

@dnolen: Yes… I realized that what I proposed isn’t consistent with JVM ClojureScript

So, macro specs with JVM ClojureScript are likely to be placed in the macro namespace itself

yep

and by doing it this way we have portable specs for both runtime and macros

even if they share the same name

Let me try an experiment with the 2nd patch. I bet that if I put a spec in a macro namespace (say, at the bottom of the file), where that spec uses an unqualified symbol, it will automatically resolve by adding $macros suffix without the developer being aware.

@mfikes: heh even better if this just works 🙂

@dnolen: any thoughts on the alter-meta! stuff for vars I mentioned earlier?

(Starting to better understand the corner cases that need to be handled 🙂 )

@anmonteiro: it’s harder than it seems

vars are emitted at compile time

that is two var expressions aren’t the same object

so would need to consider this aspect of the problem - perhaps vars could share their state through an atom or something?

@dnolen: I wasn’t aware of that

what about the IReference protocol?

should we copy Clojure there?

it doesn’t seem particularly useful to me

at least not without considering how keeping vars in sync will actually work first

it would really only apply to vars and atoms, I believe

@dnolen: OK thanks for the input. where in the codebase is the var emission code?

yeah this is uglier than it seems

for example you emit a var in a bunch of places then redef at the REPL

I suspect that just works in Clojure

unclear how to make that work in ClojureScript

so would want to think through this first before considering IReference

makes sense. I was just wondering where vars are emitted so I could go through that code path

line ~979 in analyzer.cljc for the analysis bit

~327 in compiler.cljc for the emission

thanks!

np

Yes… one pair of specs works uniformly in both JVM and bootstrap ClojureScript. Writing up example in the ticket for reference. 🙂

@mfikes: excellent, better when there’s nothing to do 🙂

@dnolen: Yes, it is challenging enough to write code satisfying the constraints of all of these platforms. The less done by devs (in terms of mucking with qualifying names) the better. Perhaps letting thing implicitly qualify is simplest.

@mfikes patch 2 applied

Cool. Crossing my fingers that it covers all the cases we need it to for now 🙂

Need to pick up your brains. I have made quite nice progress on code completions in Dirac 0.6.0 thanks to your suggestions: https://github.com/binaryage/dirac/releases/tag/v0.6.0 I’m parsing all ns-forms using cljs.analyzer[1], it was much easier than expected 🙂 Motivated with this quick win I would like to go further. The idea: thanks to source maps, I have full cljs source code snapshots at the point it was loaded in the browser. On client-side I could run analyzer pass not only on ns-forms like I do now, but in theory on the whole file. This could give me some contextual info for subsequent REPL eval requests. This way I could get rid of warnings[2] which are generated because after in-ns people don’t run (require 'my-namespace) prior executing their commands in the REPL. In theory I could be able to “setup” eval environment according to "browser state" before each eval request. Partially I already do something like that by providing :locals when paused on a breakpoint. I would be just able to provide more contextual info from browser side (existing vars, current ns-form info, etc.). Do you think something like could fly? Is it even possible? Ideas? [1] https://github.com/binaryage/dirac/blob/master/src/implant/dirac/implant/analyzer.cljs#L7 [2] https://github.com/binaryage/dirac/blob/master/src/runtime/dirac/runtime/prefs.cljs#L25-L26

I don’t know too much about the fine details, but this sounds similar in behaviour to what Figwheel does, where you can in-ns anywhere and eval without requiring