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

2016-09-09 Thread Mars0i
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

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

2016-09-09 Thread Rangel Spasov
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: map/filter/remove etc. change underlying structure

2016-09-09 Thread Alex Miller
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: map/filter/remove etc. change underlying structure

2016-09-09 Thread Alan Thompson
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: map/filter/remove etc. change underlying structure

2016-09-09 Thread Stuart Sierra
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: map/filter/remove etc. change underlying structure

2016-09-09 Thread Colin Yates
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

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

2016-09-09 Thread Mamun
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

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

2016-09-09 Thread Mark Engelberg
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

2016-09-09 Thread Mark Engelberg
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

2016-09-09 Thread James Reeves
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