This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-05-15
Channels
- # beginners (34)
- # boot (45)
- # cider (16)
- # cljs-dev (20)
- # cljsjs (1)
- # cljsrn (8)
- # clojure (207)
- # clojure-berlin (3)
- # clojure-dev (18)
- # clojure-greece (1)
- # clojure-ireland (1)
- # clojure-italy (9)
- # clojure-russia (20)
- # clojure-spec (27)
- # clojure-uk (19)
- # clojurescript (110)
- # code-reviews (2)
- # cursive (7)
- # data-science (2)
- # datomic (7)
- # devcards (1)
- # emacs (4)
- # graphql (1)
- # hoplon (2)
- # immutant (15)
- # jobs (5)
- # jobs-rus (1)
- # juxt (1)
- # luminus (7)
- # lumo (26)
- # microservices (3)
- # off-topic (27)
- # om (13)
- # onyx (11)
- # pedestal (7)
- # proton (4)
- # re-frame (24)
- # remote-jobs (1)
- # spacemacs (2)
- # specter (2)
- # unrepl (31)
- # untangled (7)
- # vim (14)
JS being single threaded doesn’t mean you can’t have several logical processes (cooperatively) sharing the thread. In many cases the callback you pass is the continuation of the current process. On the JVM this style is infrequent because there are preemptive threads. So bound-fn
is ok for the occasional call. In js you wouljd litter your code with bound-fn
calls.
Furthermore bound-fn
flattens the dynamic bindings stack. Which makes impossible some continuation stuff. E.g. in Clojure (with-open [f ...] (do sync IO))
can’t be translated to (with-open [f ..] (.on f "data" (bound-fn ...)))
because resource reclamation must happen in the continuation (otherwise by the time the callback is called the resource is already disposed.
Basically I think the callback-as-continuation scenario needs special support for dynamic variables and for the other dynamically scoped feature: try/catch/finally
I see, interesting. A difficult thing to achieve though! Although very simple if we were to generate ES.next code (with the new async functions)
could you explain how that would help @dominicm ?
@pesterhazy my understanding is that try/catch works with e.g. async/await
https://pouchdb.com/2015/03/05/taming-the-async-beast-with-es7.html yes, yes you can
Isn't the continuation approach exactly what cljs-zones
does?
I might have misread it from the Klipse example above
Reading as we speak 😀
I wouldn't say exactly. Plus I believe the prototype-based implementation is flawed: a set on a dynamic var bound in an outer scope should survive to the current scope
@cgrand I think that is exactly the point of using prototypes, but I am not a JS master so maybe we can summon @darwin to this channel 😄
@richiardiandrea (binding [a 1] (binding [b 2] (set! a 3)) a)
should evaluate to 3 not to 1.
returns 3
no sorry 😄
(ns zones.test
(:require [zones.core :as zones :include-macros true]))
(zones/binding [a 1] (zones/binding [b 2] (set! a 3)) a)
this evaluates to 3
again, not the author here, but prototypes inherit properties so this can go as deep as needed...
there are also a bunch of tests: https://github.com/binaryage/cljs-zones/blob/master/test/src/tests/zones/tests/core.cljs#L97
And if you replace set!
by zone/set! And plain a by (zone/get a) — sorry to use you as a repl but I only have two thumbs
np let me check 😄
(ns zones.test
(:require [zones.core :as zones :include-macros true]))
(zones/binding [a 1] (zones/binding [b 2] (zones/set! a 3)) (zones/get a))
=> 3no
zones/get
is the same
(ns zones.test
(:require [zones.core :as zones :include-macros true]))
(zones/binding [a 1] (zones/binding [b 2] (zones/set! a 3)) a)
...this one does not work as expected actually... so you need a zones/get
I like, it is good to see if we can break it 😉
Hmm I'll have to look at the impl because the prototype chain only works for getting a property. All sets are shallow.