Deref Nil

Hey all, I'm having some pain with atoms and dereferencing nil - mostly around my functions sometimes returning an atom and other times nil - I don't really want to create a special 'nil' atom and do the bits for returning that and I don't want to be checking nils absolutely everywhere when nil

Re: Efficient comparison of persistent structures

Live code snippets that demonstrates the performance issues: app.klipse.tech?cljs_in=...

map/filter/remove etc. change underlying structure

Hi all, So in the spirit of exposing my ignorance to the internet :-), I have just been bitten by a bug due to the behaviour of the core libraries which I find really surprising: (def v [1 2 3]) (conj v 4) => [1 2 3 4] (conj (map identity v) 4) => (4 1 2 3) (conj (remove (constantly false) v) 4

Re: map/filter/remove etc. change underlying structure

I find the current behaviour to be perfectly intuitive. I think it would be unnecessarily complex and confusing to have seqs behave differently depending on what data structure they were originally derived from. - James On 9 September 2016 at 11:23, Colin Yates wrote: > Hi all, > > So in the sp

Re: map/filter/remove etc. change underlying structure

Everything from the Clojure cheatsheet's "Seq in Seq out" section processes the input as a sequence (ignoring its concrete type) and always returns a lazy sequence. When you pass in a vector v, the very first thing these functions typically do is call `seq` on it, and they process the input using

Re: map/filter/remove etc. change underlying structure

Scala behaves more like your intuition, generally assuming you want back the same kind of collection as what you passed in. It can be a bit of a pain, though, when that's *not* the behavior you want. Clojure's way puts you in control by always producing a sequence and letting you put it into the

Re: map/filter/remove etc. change underlying structure

To me, Changing type or order is a lack of facility for basic task. In the end comping task is also become more hard. Have you tried to use Specter? Why do you not consider Specter lib? Br, Mamun On Friday, September 9, 2016 at 12:23:37 PM UTC+2, Colin Yates wrote: > > Hi all, > > So in t

idiomatic way of counting loop iteration

Hi, I'm just stating to learn clojure, i made a first read of "clojure programming" to get the big picture, and i'm starting to play with the repl, trying to solve some katas. A lot of theses katas involves returning the count of loop iterations. Most of the time, i end up with this kind of fu

Re: map/filter/remove etc. change underlying structure

I did look at Specter and it looks nice and well engineered, but I never really ran into the sorts of problem it solves, at least not enough to warrant the cost of depending on a new library. On Fri, 9 Sep 2016, at 12:49 PM, Mamun wrote: > To me, Changing type or order is a lack of facility for ba

map/filter/remove etc. change underlying structure

Here's some background that might help give this some context: http://clojure.org/guides/faq#seqs_vs_colls http://insideclojure.org/2015/01/02/sequences/ http://insideclojure.org/2016/03/16/collections/ Alex -- You received this message because you are subscribed to the Google Groups "Clojure"

Re: idiomatic way of counting loop iteration

loop/recur is more typical for this kind of counting loop, as it avoids the risk of a stack-overflow when the number of iterations is high. Also, I recommend against the [a b & [n]] argument pattern here: https://stuartsierra.com/2015/06/01/clojure-donts-optional-arguments-with-varargs –S On F

Re: map/filter/remove etc. change underlying structure

Functions like map/filter/remove are not "collection functions" but rather "sequence functions." The collection functions like conj preserve the type of their argument. Sequence functions, by contrast, coerce any argument to a sequence, and always return a sequence. Since Clojure 1.7, transduce

Re: Deref Nil

This approach would only work in ClojureScript, where IDeref is defined as a Protocol. In Clojure(JVM), the core functions are defined in terms of Java interfaces, which are not extensible to `nil`. I don't find atom-or-nil to be a common value pattern. But if it's something you encounter frequ

Re: idiomatic way of counting loop iteration

Generally speaking, `loop`, `recur`, and writing recursive functions are not idiomatic in Clojure. Using things like `iterate`, `map`, and `filter` are considered clearer. If `n` is used just to count iterations, then `iterate` would be useful. e.g. (first (drop n (iterate (fn [[a b]] ... [new-a

[ANN] Clojure 1.9.0-alpha12

Regarding performance, the validation benchmark project has been updated with alpha12: http://muhuk.github.io/validation-benchmark -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note tha

Re: Deref Nil

Thanks Stuart, Ah, yes - in my case I am using ClojureScript - I assumed it worked the same in Clojure - oops! Ok, I'll likely just step around it by making the functions returning (atom nil) - but I assumed there would be reasoning behind the core deref not nil-punning to nil? I'm keen to hear t

Re: [ANN] Release 0.35.0 of Counterclockwise

Great! I was actually fearing that CCW had been abandoned, so good to see you are still around (even though I am a few months late). And just because there is not a lot of activity in here: I still use CCW more or less full time, and I appreciate the work update. On Saturday, July 9, 2016 at

Clojure spec for domain model

Hi All, I have different type of model in my domain like User, Credit. I would like to define spec of the model in one clj/cljs but not different clj/cljs file. Because I don't want to create one clj file for per model. On the other hand Clojure namespaces are very similar to Java packages. (

Re: Clojure spec for domain model

You seem to be working pretty hard here. Why don't you just do: (s/def :User/id string?) (s/def :Credit/id number?) The keyword qualifier does not have to map to a loaded namespace. (It does if you want to use namespace aliases, but that doesn't seem necessary here.) On Friday, September 9, 20

Re: idiomatic way of counting loop iteration

Thanks, i like the "unambiguous intent" argument from your post, and indeed i met the stack-overflow issue. On Friday, September 9, 2016 at 2:28:46 PM UTC+2, Stuart Sierra wrote: > > loop/recur is more typical for this kind of counting loop, as it avoids > the risk of a stack-overflow when the

Re: idiomatic way of counting loop iteration

Thanks for helping me! In your first example: (first (drop n (iterate (fn [[a b]] ... [new-a new-b] Given that iterate will return a sequence whose length is the number of iteration i'm looking for, the "(first (drop n" part will return one element of this sequence (depending on n value), an

Re: map/filter/remove etc. change underlying structure

Hi Colin, I too have been bitten by this type of inconsistency in clojure.core functions. The root of the problem is that conj has different behavior for lists and vectors, and that a seq behaves like a list. When map, filter, etc convert the source vector into a seq, the behavior of conj changes

Re: Deref Nil

Like Stuart, I don’t encounter atom-or-nil as a common pattern – could you explain why you have functions that might return an atom or might return nil? FYI, We have about 40,000 lines of Clojure at World Singles and just a handful of atoms (and most of those are going away as we refactor the

Re: map/filter/remove etc. change underlying structure

On Friday, September 9, 2016 at 11:36:22 AM UTC-5, Alan Thompson wrote: > > Hi Colin, > > I too have been bitten by this type of inconsistency in clojure.core > functions. > I disagree that the problem here is consistency. The core functions are very consistent, but I think it's easy to build

Re: Efficient comparison of persistent structures

The only way to have diff consider internal structures is to have a diff protocol (with access to internals) to speed up comparison between items of the exact same Java class. However, much of the slowdown you see is from intermediate vectors created during the reductions in diff-associative an

Re: map/filter/remove etc. change underlying structure

When I first started learning Clojure 3.5 years ago I was "bit" by this in my first month or so of doing Clojure but after spending a little bit of time to understand how the sequence abstraction works it was never a problem again. I agree with everything that Alex says here. On Friday, Septem

Re: [ANN] Clojure 1.9.0-alpha12

Hey guys, I'm getting this compilation error with Alpha 12 (use the gist link) https://gist.github.com/raspasov/188a8e60f1f6e695b6492cf2d3d19471 Rangel On Wednesday, September 7, 2016 at 2:15:25 PM UTC-7, Alex Miller wrote: > > Clojure 1.9.0-alpha12 is now available. > > Try it via > > - Downl

Re: [ANN] Clojure 1.9.0-alpha12

The keys of an :or destructuring map should be symbols, not keywords. > On Sep 9, 2016, at 7:52 PM, Rangel Spasov wrote: > > Hey guys, > > I'm getting this compilation error with Alpha 12 (use the gist link) > > https://gist.github.com/raspasov/188a8e60f1f6e695b6492cf2d3d19471 > > Rangel >

Re: [ANN] Clojure 1.9.0-alpha12

Ah, got it - https://github.com/ztellman/aleph/commit/7d6f2f5bf743301c5a4ab0705725bf9b50b91896 - thanks! On Friday, September 9, 2016 at 6:22:15 PM UTC-7, Alex Miller wrote: > > The keys of an :or destructuring map should be symbols, not keywords. > > On Sep 9, 2016, at 7:52 PM, Rangel Spasov

Re: [ANN] Clojure 1.9.0-alpha12

Oh yeah, I fixed that one a while back. :) I think there is a newer release of aleph with the change. On Fri, Sep 9, 2016 at 10:11 PM, Rangel Spasov wrote: > Ah, got it - https://github.com/ztellman/aleph/commit/ > 7d6f2f5bf743301c5a4ab0705725bf9b50b91896 - thanks! > > On Friday, September 9, 2

Re: map/filter/remove etc. change underlying structure

On Friday, September 9, 2016 at 6:36:17 AM UTC-5, puzzler wrote: > > ... > You can use `into` to "pour" the sequence into the collection of your > choice. If you're using `into`, then most of these sequence functions > support transducers to avoid allocation of intermediate sequences, > provi