It looks like, due to the way the binding macro is implemented in ClojureScript
[1], the return value of an empty binding form happens to be the value of the
right-hand side of the last binding pair – :foo in the example in your post, 1
in your linked test case. The Clojure implementation of bin
On Friday, November 14, 2014 7:22:39 PM UTC-8, Colin Fleming wrote:
> Hi all,
>
> There's a discussion going on right now on clojure-dev
> (https://groups.google.com/d/topic/clojure-dev/6pnIeXFRwnI/discussion) about
> the Feature Expressions functionality currently slated for Clojure 1.7. This
I'm betting this is caused by the Objective-C runtime. Under the 32-bit
runtime, Objective-C's BOOL is actually a typedef and desugars to unsigned
char. Under the 64-bit runtime, BOOL instead desugars to _Bool – a distinct
type rather than a typedef. This behavior, and some of the problems it ca
On Saturday, August 16, 2014 3:56:45 PM UTC-4, Mike Fikes wrote:
> I am accessing a Boolean field on a JavaScript object and if the host is
> 64-bit JavaScriptCore I will get back either a true or false ClojureScript
> value. If it is instead a 32-bit JavaScriptCore host, I will get back either
(will-mount) is called outside of the render phase, so you can't directly
access the :world key on the cursor itself within that scope – you'll have to
deref it first to get at the backing map. (log (:world @data)) should do what
you're looking for.
Cursor access semantics are covered in the Om
FWIW: I was working on my own attempt at a self-hosting CLJS compiler up until
a few months ago, and actually wound up submitting a GSoC project proposal to
make the mainline cljsc self-hosting. Though it wasn't accepted, I did have the
opportunity to talk to some of the other people working on
