This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (3)
- # aws (5)
- # beginners (65)
- # boot (17)
- # cljs-dev (112)
- # cljsrn (5)
- # clojure (146)
- # clojure-austin (3)
- # clojure-dusseldorf (3)
- # clojure-italy (18)
- # clojure-norway (13)
- # clojure-russia (84)
- # clojure-serbia (5)
- # clojure-spec (24)
- # clojure-uk (84)
- # clojurescript (204)
- # css (1)
- # cursive (21)
- # data-science (3)
- # datascript (21)
- # datomic (26)
- # emacs (5)
- # euroclojure (1)
- # hoplon (8)
- # jobs (7)
- # jobs-discuss (2)
- # keechma (35)
- # lumo (92)
- # mount (1)
- # nrepl (2)
- # numerical-computing (16)
- # off-topic (10)
- # om (58)
- # re-frame (13)
- # reagent (90)
- # remote-jobs (2)
- # ring-swagger (1)
- # spacemacs (9)
- # specter (6)
- # unrepl (17)
- # untangled (56)
- # yada (2)
i give up, what value would make this true. i thought the answer was nil, but its not considered true so it fails.
(let [x __] (and (= (class x) x) x))
@drewverlee imagine if you took an iterator, and took a class of a thing, and found the class of the class of the thing, etc.
After migrating to shadow-cljs I found my
build.boot already unnecessary except for releasing package.
@ghadi thanks, but I don't see how this ties to relying on one map initialization key while initializing another
I was thinking more along the lines of writing a macro, unless some pattern helps with that specific concern
Hi all! I'm developing a mobile app with re-natal. I need to draw a curved line chart, (and maybe animate it). what is the best API to do it? I saw d3 and ART, but d3 is most for the web.. I alsodiscovered Victory https://formidable.com/open-source/victory/docs/native and React-native-Chart https://github.com/tomauty/react-native-chart. What do you think? thanks 🙂
@gmercer Thanks. I tried
class and i thought i tried
java.lang.Class to, i must have done something else though.
I'd like to ask a question on ztellman's wonderful manifold: I have trouble to bring manifold deferreds and streams together to perform HTTP requests ins parallel.
I'm trying to understand how lazy evaluation works in Clojure. One thing I've noticed from playing around with the repl is the way in which lazy lists work, for example in Haskell
take 10000 $ repeat "foo" will pass the unevaluated values to
take and it would be the
take function which evaluates the list as it requires. However,
(take 10000 (repeat "foo")) requires an initial startup time where
repeat is initially lazy but then appears to be evaluated hastily evaluated by
take. My thinking on that is that either:
1. Take evaluates the tail first which means
(take x (...)) must evaluate to x before returning
2. Repeat does not pass the lazy list to
take but instead returns a list of length x
3. This is something to do with the repl and
ghci evaluates expressions lazily whilst the clojure repl doesn't
> Repeat does not pass the lazy list to
take but instead returns a list of length x
I'm not sure I understand.
(repeat "foo") knows how many (`x`) elements take wants before take is evaluated?
Only lazily realized lists. evaluation in clojure is always strict/eager, unlike haskell
The REPL in haskell confuses things a bit because you have evaluate stuff to print it meaninfully, right?
Ah ok, so http://www.braveclojure.com/core-functions-in-depth/#Infinite_Sequences_ is more just talking about the nature of lists rather than anything specific to clojure?
But the easiest way to think about it is: laziness in clojure specifically refers to lazy sequences
@alexsays repeat doesn’t realize anything, and take only parameterizes how many items will be returned, it’s the printing that realizes if anything (in a repl context at least)
Don't think any of it directly contradicts. It could be that I'm coming at from the concept of everything being lazy > A lazy seq is a seq whose members aren’t computed until you try to access them To me that indicates that for a list of xs, x won't be evaluated until that element is accessed.
@alexsays there’s a crucial bug in nrepl here - nrepl isn’t lazy, and if you call (take 1000 x) all 1000 elements are realized before any are printed
this is an nrepl bug, in a real direct clojure repl the items print as they are realized
> To me that indicates that for a list of xs, x won’t be evaluated until that element is accessed. remember that printing accesses the items
the chapter has a good book of exactly that:
(repeatedly (fn  (rand-int 10))) that function is not computed until the element is accessed
@ghadi the ghc repl is just a monad at its most basic level that's passed a stream of expressions that it lazily evaluates.
we have exactly one lazy type: clojure.lang.LazySeq - we don’t have lazy evaluation
So it's not really any strangeness is execution order but more to do with the fact that there's only a small number of data structures which are lazy
Is it worth tending to not think about the lazy structures - and assume that when the time comes to use them I'll know - or are they considered an important part of the language?
Thinking of my experience with scala where LazySeq is only really used in a few edge cases
the lazy structures are pretty ubiquitous: map, filter, remove, take, drop, concat
> So it's not really any strangeness is execution order but more to do with the fact that there's only a small number of data structures which are lazy there was confusion about this just a second ago
and why the exception was not caught
(let [will-throw (try (map risky-function collection) (catch Throwable nil))] (reduce rfunc  will-throw)
I've read a little bit on from that chapter and played around a bit. Think I've got my head around it; thanks for the help guys