> l))
>>
>>
>>
>> Hopefully that’ll give you some options to think about…
>>
>>
>>
>> Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
>> An Architect's View -- http://corfield.org/
>>
>> "If you're not annoying so
Practically speaking, Java numbers cannot be extended with the IFn
interface to make this possible.
On Mon, Nov 13, 2017 at 9:15 AM, Alex Miller wrote:
> Regarding the title, this is incorrect. Map keys are not functions;
> keywords are functions that take an associative data structure and will
ield.org/
>
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
>
>
> --
> *From:* clojure@googlegroups.com on behalf of
> Stephen Feyrer
> *Sent:* Monday, November 13, 2017 5:19:32 PM
> *To:*
Sent: Monday, November 13, 2017 5:19:32 PM
To: clojure@googlegroups.com
Subject: Re: Map Keywords are functions, why not vector elements?
Hi Alex, Didier,
Thanks for your patience.
That covers everything which I can think of and a fair bit more :) I have a
bit of reading and thinking to do now.
Ag
Hi Alex, Didier,
Thanks for your patience.
That covers everything which I can think of and a fair bit more :) I have
a bit of reading and thinking to do now.
Again, thank you.
--
Rule of thumb simple question, complicated answer
Stephen.
On 13 November 2017 at 22:09, Didier wrote:
> Yo ar
Yo are looking for indexOf (.indexOf vector value).
(.indexOf ["a" "b"] "b")
=> 1
(.indexOf ["a" "b" "b"] "b")
=> 1
Note how indexOf searches for the index of the first value which matches value.
To do what you ask, is a query over a vector, which requires a search on each
element. This will t
On Monday, November 13, 2017 at 11:40:10 AM UTC-6, Stephen Feyrer wrote:
>
> Updating subject to make it make more sense, hopefully.
>
> On 13 November 2017 at 14:15, Alex Miller wrote:
>
>> Regarding the title, this is incorrect. Map keys are not functions;
>> keywords are functions that take
Updating subject to make it make more sense, hopefully.
On 13 November 2017 at 14:15, Alex Miller wrote:
> Regarding the title, this is incorrect. Map keys are not functions;
> keywords are functions that take an associative data structure and will
> look themselves up in it. So, the premise her
Regarding the title, this is incorrect. Map keys are not functions;
keywords are functions that take an associative data structure and will
look themselves up in it. So, the premise here is not even correct to start.
Usually we prefer to work by starting from a problem and consider
alternatives
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
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
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
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
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
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
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
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
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
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
Hi Moe,
Thanks, i didn't know about :when and :let in for. That is my favorite so
far, small and readable, looks good.
Sven
Am Dienstag, 25. August 2015 11:17:23 UTC+2 schrieb Moe Aboulkheir:
>
> Sven,
>
> To me, the keep version would be a lot more readable if it were creating a
> literal map
Sven,
To me, the keep version would be a lot more readable if it were creating a
literal map in a fn.
I think (for) is almost always the right thing. It's not as fun to write,
but much easier to read:
(for [i (range 1 11)
:let [id (keyword (str "answer_correct_" i))]
:when (params i
The reduce in your mapped function is already implemented by get-in. Other
possible implementations using get-in:
(defn map-in [coll ks f & args]
(->> coll
(map #(get-in % ks))
(map #(apply f % args
Or:
(defn map-in [coll ks f & args]
(map #(apply f (get-in % ks) args) col
juxt?
user=> (map (juxt zero? even?) (range 5))
([true true] [false false] [false true] [false false] [false true])
user=> (map (apply juxt [zero? even?]) (range 5))
([true true] [false false] [false true] [false false] [false true])
On Monday, November 17, 2014 8:25:07 PM UTC-8, Andy L wrote:
Thanks! I was playing around with similar variants last night & came up with
some that seem to work for one element, but not many.
I was seeing a similar result from your version:
=> (map2 count [(repeat 1e8 "stuff") (repeat 1e8 "stuff") (repeat 1e8
"stuff")])
OutOfMemoryError GC overhead limi
At least in your particular case, replacing map with map2, defined below as
a small modification to a subset of map, seems to do the trick:
(defn map2 [f coll]
(lazy-seq
(when-let [s (seq coll)]
(let [r (rest s)]
(cons (f (first s)) (map2 f r))
(map2 count [(repeat 1e8 "stuff
oke,
So map is taking the first item of coll and put's it in x. Then it calling
second-item .
Now I understand .
Thanks a lot for the patience and explanation.
Roelof
Op vrijdag 24 oktober 2014 16:01:48 UTC+2 schreef Laurens Van Houtven:
> (defn double [x] (* x 2))
>
> See, x is right the
(defn double [x] (* x 2))
See, x is right there ^
Now, I do (double 10). How does Clojure “know what the x is”? There’s no x in
that expression.
Exactly the same with map. The x is just a name; it doesn’t matter what it is.
The only thing that matters is that you call that function (whether it
Sorry but I still do not have a clue how clojure knows what x is.
the first part where x is mentioned is the fn part and on the map
part there is no mention about x.
Roelof
Op vrijdag 24 oktober 2014 15:51:30 UTC+2 schreef Laurens Van Houtven:
> Hi Roelof,
>
> > I understand that part.
>
Hi Roelof,
> I understand that part.
>
> so we have (map second-item collection) where second-item and collection are
> arguments of map.
Yep.
> Then we have second-item ( fn [x] (get x 2)
> which can be read as :
>
> ( second-item [x] (get x 2) .
This makes no sense to me. second-item
Op vrijdag 24 oktober 2014 15:32:33 UTC+2 schreef Laurens Van Houtven:
>
> Hi Roelof,
>
> On 24 Oct 2014, at 15:12, Roelof Wobben >
> wrote:
>
> > I understand that part but when I look at the map part there is no x.
> When I look at the function no x.
>
> I’m assuming you mean that when yo
Hi Roelof,
On 24 Oct 2014, at 15:12, Roelof Wobben wrote:
> I understand that part but when I look at the map part there is no x. When I
> look at the function no x.
I’m assuming you mean that when you look at the function, you do see the x —
it’s right there, both in the argument list and i
I understand that part but when I look at the map part there is no x. When
I look at the function no x.
So how does Clojure know what the value of x is.
Roelof
Op vrijdag 24 oktober 2014 15:06:05 UTC+2 schreef Laurens Van Houtven:
> Hi Roelof,
>
> On 24 Oct 2014, at 15:00, Roelof Wobben >
Hi Roelof,
On 24 Oct 2014, at 15:00, Roelof Wobben wrote:
> (defn second-elements [collection]
>(let [second-item (fn [x] (get x 1))]
> (map second-item collection)))
>
> one thing I m not sure I understand complete. x is the output of the map
> command, if so, how does Clojure know t
Yes.
I solved the problem with :
(defn second-elements [collection]
(let [second-item (fn [x] (get x 1))]
(map second-item collection)))
one thing I m not sure I understand complete. x is the output of the map
command, if so, how does Clojure know that.
Roelof
Op vrijdag 24 oktober
Hi Roelof,
OK, so, what you want to do is look at the example right before it, (defn
mungefy …).
You want to do something very similar: except instead of munge you’ll have a
different (fn [x] …) that uses get on x. Make sense?
hth
lvh
signature.asc
Description: Message signed with OpenPGP
I try to make exercise 16.
Roelof
Op vrijdag 24 oktober 2014 14:27:19 UTC+2 schreef Laurens Van Houtven:
> Hi Roelof,
>
>
> I had no idea iloveponies was a Clojure introduction.
>
>
> https://iloveponies.github.io/120-hour-epic-sax-marathon/structured-data.html
>
> What exercise are you at
Hi Roelof,
I had no idea iloveponies was a Clojure introduction.
https://iloveponies.github.io/120-hour-epic-sax-marathon/structured-data.html
What exercise are you attempting, exactly?
cheers
lvh
signature.asc
Description: Message signed with OpenPGP using GPGMail
Thanks, but still very confusing for a beginner.
the exercise is talking about using a helper function and it looks like
second does the same as (get coll 1 )
Roelof
Op vrijdag 24 oktober 2014 14:19:28 UTC+2 schreef Laurens Van Houtven:
> Hi Roelof,
>
> On 24 Oct 2014, at 14:16, Roelof Wob
Hi Roelof,
On 24 Oct 2014, at 14:16, Roelof Wobben wrote:
> oke, and second could be the helper function.
`second` is part of Clojure. You do not have to write it.
> I know what schould be done map has to pick up the items and on that item I
> have to be doing the get.
Yes. map calls its fi
Op vrijdag 24 oktober 2014 14:09:13 UTC+2 schreef Laurens Van Houtven:
>
> Hi Roelof,
>
> On 24 Oct 2014, at 14:05, Roelof Wobben >
> wrote:
>
> > I have to use map and get a vector of all the second items in a list.
> > I know I can use map to do things with all the items in a list.
> > and
Hi Roelof,
On 24 Oct 2014, at 14:05, Roelof Wobben wrote:
> I have to use map and get a vector of all the second items in a list.
> I know I can use map to do things with all the items in a list.
> and with get I can get the second item (get collection 1)
Yes, depending on what the items in the
Thanks Lee. You are correct there is something wrong with my input to this
function that is causing the problem, not the function. Sorry for the
error.
On Tuesday, July 8, 2014 8:13:36 PM UTC-7, Lee wrote:
>
>
> Hi Glen,
>
> You haven't really provided what we would need to replicate your pro
Hi Glen,
You haven't really provided what we would need to replicate your problem.
Specifically:
- You call but don't provide definitions for address or is-blank?
- You refer to unbound symbols some-string and another-string.
- You don't provide an input for report, or the top-level call you
I am still having difficulties with this, so let me clarify by showing some
sample code.
My fn looks like this:
(defn report [text]
(str
"string1"
"string2"
(apply str (map-indexed (fn [idx itm] (time-text idx itm)) (filtered-list
text))
When I invoke spit in order to output a tex
That's not your problem. From (doc str):
"With more than one arg, returns the concatenation of the str values of the
args."
The str value of a lazy sequence is something like:
"clojure.lang.LazySeq@386e0460"
which is the result of (.toString your-seq)
What you probably want is something like
Sometimes you have to manually stamp out laziness, for this among other reasons.
In some cases I apply the list function to do this:
=> (str (map inc (range 10)))
"clojure.lang.LazySeq@c5d38b66"
=> (str (apply list (map inc (range 10
"(1 2 3 4 5 6 7 8 9 10)"
-Lee
> On 8 July 2014 09:49,
To force realisation of a sequence, use one of the do* forms.
https://clojure.github.io/clojure/clojure.core-api.html#clojure.core/do
If you post a gist of your code then someone may be able to give more specific
guidance.
Daniel.
> On 8/07/2014, at 2:15 pm, Glen Rubin wrote:
>
> yes, that
yes, that is exactly my issue. i am trying to get the lazy sequence fully
realized as you say, but it's not happening in the context i put it in.
On Monday, July 7, 2014 6:04:00 PM UTC-7, Daniel Compton wrote:
>
> Hi Glen
>
> One thing to keep in mind with lazy sequences is that running them at
Hi Glen
One thing to keep in mind with lazy sequences is that running them at the
REPL will force them to be fully realised, whereas a lazy sequence may not
be realised in other contexts. I didn't understand where 'clojure-lazy-seq'
is coming from in your question so I'm not sure if that's your is
doh!, thanks for the above. I actually did read this a few weeks ago but
totally forgot about it. :o/
--
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 that posts from new members are m
Not everything is chunked, but data-structures like vectors produce
chunked-seqs.
On Fri, Feb 28, 2014 at 5:06 PM, Jim - FooBar(); wrote:
> Clojure works on a chunked basis for performance reasons...THe size of a
> chunk is 32 elements - thus you would actually get 32 printouts if you
> supplied
Hi Andy,
Lazy sequences are realised in chunks of 32.
You can see this by running:
(take 1 (map prn (range)))
(0
1
..
30
31
nil)
Thanks,
Ambrose
On Sat, Mar 1, 2014 at 1:04 AM, Andy Smith wrote:
> Hi,
>
> Can someone correct my misunderstanding here. I was lead to believe that
> map produced
Clojure works on a chunked basis for performance reasons...THe size of a
chunk is 32 elements - thus you would actually get 32 printouts if you
supplied a collection larger than 31 elements.
Jim
On 28/02/14 17:04, Andy Smith wrote:
Hi,
Can someone correct my misunderstanding here. I was lea
On Sun, Feb 9, 2014 at 4:46 AM, Michał Marczyk wrote:
The Contrib library algo.generic provides a function fmap which does
> preserve the type of its input.
>
Thanks for the pointer.
> So, these are some of the available conceptual arguments. There is
> also a rather convincing practical argume
Agreed - there are always tradeoffs. Another common example is that pretty
well any language that uses IEEE floating point is also breaking
referential transparency in the interest of pragmatism:
user=> (= 0.3 (+ 0.1 0.2))
false
user=> (= (bigdec 0.3) (+ (bigdec 0.1) (bigdec 0.2)))
true
- Kor
There are many types and flavors of equality, and only handful of symbols.
Symbol '=' in Clojure does not represent yours fundamental = comparison
operator. = in Clojure compares for the actual value ignoring concrete
types of collections and the internal representation of how the items are
stored.
The Contrib library algo.generic provides a function fmap which does
preserve the type of its input.
As for the idea that clojure.core/map should preserve type, it's worth
remembering that in order to map a function over a set and return a
set, we must do two things: (1) apply the function to each
Maybe physical identity is too strong of a requirement for equality. So
another way to think about it is that it's 'hash-set', 'set', and '#{}'
that are--you know--"broken", but that there's a fix, which is to always
use 'sorted-set'. (I'm assuming that calling 'seq' on any two sorted sets
th
Maybe another way to put it is that what is, uh, "broken" isn't 'map' or
'seq', but '=', which is willing to tell you that two things (sets) are the
same when they're not! We also have the non-broken predicate 'identical?',
however, that gets it right. It's nice to also have a set-equal predic
I can ensure all of you that it is very uncomfortable for a newcomer with a
goofy nick to just come in and say things are broke LOL . So at that point
I have two choices:
1) as suggested, find another programming language but that would mean that
I would have to erase my Clojure tattoo (very painf
To add just one more thing to this: Referential transparency is clearly
valuable, but it's not the *only* valuable property a function or system might
have. There are always tradeoffs to be made. Clojure has made different
tradeoffs than you expected, or would yourself have made, but that doesn't
/
Hi Andy,
Andy C wrote:
>
>
>> user> (= s1 s2)
>> true
>> user> (= (seq s1) (seq s2))
>> false
>
>
> Thx. If a=b then f(a) must = f(b). Something is broken here.
If a seq is a sequential view of a thing, and a set is an unordered thing, then
it does not seem shocking to me that multiple sequenti
It is working as designed.
If you do not want this, consider using sorted sets / sorted maps, where (=
s1 s2) implies (= (seq s1) (seq s2)).
Or, perhaps another programming language would be more to your liking.
Andy
On Sat, Feb 8, 2014 at 4:10 PM, Andy C wrote:
>
> user> (= s1 s2)
>> true
>
> user> (= s1 s2)
> true
> user> (= (seq s1) (seq s2))
> false
>
Thx. If a=b then f(a) must = f(b). Something is broken here.
--
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 that pos
On Feb 8, 2014, at 7:59 AM, Andy C wrote:
> Your assertion that I "am misunderstanding something" is wrong.
Now that you've seen everyone else's responses, perhaps you understand my
assertion was correct? :)
Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
"If you're
Well it does not break referential transparency if both equalities (for
input values and for results) are of a same kind. You would have to compare
inputs by value and outputs by identity, if you want to percieve an
inconsistency.
JW
On Saturday, February 8, 2014 6:49:39 PM UTC+1, Andy Fingerh
I've forgot the most interesting part :)
user> (= s1 s2)
true
user> (= (seq s1) (seq s2))
false
JW
On Sat, Feb 8, 2014 at 11:32 PM, Jozef Wagner wrote:
> Yes. Behold a Murmur3 hash collision:
>
> user> (def n1 -2023261231)
> #'user/n1
> user> (def n2 9223372036854771971)
> #'user/n2
> user> (=
Yes. Behold a Murmur3 hash collision:
user> (def n1 -2023261231)
#'user/n1
user> (def n2 9223372036854771971)
#'user/n2
user> (== (hash n1) (hash n2))
true
user> (def s1 (conj #{} n1 n2))
#'user/s1
user> (def s2 (conj #{} n2 n1))
#'user/s2
user> (= s1 s2)
But practically, I cannot think of any sc
On Feb 8, 2014, at 15:14 , Andy C wrote:
> It all boils down this:
> is it possible to have two clojure.lang.PersistentHashSet with identical
> values (in mathematical sense) but producing different seqs?
Are you serious? The entire point of the email you responded to was to answer
that ques
On Sat, Feb 8, 2014 at 1:46 PM, Jozef Wagner wrote:
> Two collections equivalent by their values may easily have a different
> order of their items.
>
It all boils down this:
is it possible to have two clojure.lang.PersistentHashSet with identical
values (in mathematical sense) but producing
By 'same' I've meant an identical :).
Two collections equivalent by their values may easily have a different
order of their items. This is because in unordered collections, their
internal order (as any other implementation detail) must not be taken into
account when comparing for value equivalence
First, thanks everybody for explanations of design decision behind map and
collections. I should in fact change subject to seq semantics ;-).
For me the bottom line is that while I do not care about order so much I
still can count on that seq function will produce consistent sequences. Or
wait a
On Sat, Feb 8, 2014 at 6:39 PM, Timothy Baldridge wrote:
> First of all, you are right. Map with things like sets is a bit of iffy
> concept. Now, most of the the time, I just don't care. If I was to increment
> every value in a set I'll just do (set (map inc #{1 2 3})) and not really
> care less
The sequence abstraction is documented here:
http://clojure.org/sequences
Clearly map is documented as working on sequences.
A sequence is not a concrete type as explained by others on
this thread.
If you really need some specific behavior from a concrete type then
do not rely on sequences. Use
This might be too detailed a point, but I wanted to mention that while you
will always get the same order for the same collection (same as determined
by identical?, or Java ==, i.e. it is the same object in memory), you are
*not* guaranteed to get the same order for collections of the same type
tha
First of all, you are right. Map with things like sets is a bit of iffy
concept. Now, most of the the time, I just don't care. If I was to
increment every value in a set I'll just do (set (map inc #{1 2 3})) and
not really care less about data structure theory. It works and I can get
work done.
Ho
The definition of map in Clojure is that it is a function on seqs. It is
defined as operating on a seq, and returning a seq.
Whereas in Scala, you hold an object and have thus access to its class (so
you can call Set.map on a set and List.map on a map), in Clojure there is
only one function clojur
On Sun, Feb 9, 2014 at 12:40 AM, Andy C wrote:
> >Every persistent collection in Clojure supports conversion to the
> sequence of items. This is clearly documented in the official docs and
> there is no surprise here.
>
> Would you mind to point me to that piece where doc describes what order
> s
>Every persistent collection in Clojure supports conversion to the sequence
of items. This is clearly documented in the official docs and there is no
surprise here.
Would you mind to point me to that piece where doc describes what order seq
chooses when converting a set to it. (I honestly tried to
Every persistent collection in Clojure supports conversion to the sequence
of items. This is clearly documented in the official docs and there is no
surprise here.
The order or items in the resulting sequence is dependent on the collection
type. As the conversion to the sequence is a referentia
On Sat, Feb 8, 2014 at 12:06 AM, Sean Corfield wrote:
> But you're misunderstanding what map does: it converts its collection
> arguments to _sequences_ and then it processes those sequences. Map
> doesn't operate on sets, or vectors, or maps, only on sequences.
>
Your assertion that I "am misun
But you're misunderstanding what map does: it converts its collection
arguments to _sequences_ and then it processes those sequences. Map
doesn't operate on sets, or vectors, or maps, only on sequences.
Scala goes out of its way to retain input types as output types on
many of its collection opera
> Following your intuition, what would you expect from the following?
> > (map + [1 3 5] '(2 4 6))
> # => ?
>
It only gets worse, as the result of below should be undefined (using
classic set definition):
user=> (map + #{0 1} #{0 1})
(0 2)
user=> (map + #{1 0} #{1 0})
(0 2)
--
You received this
On Friday, February 7, 2014 10:17:15 PM UTC-6, Andy C wrote:
>
> But what really bothers me is that laziness / not laziness affects the
> result of evaluation as in above example. That is against some fundamental
> rules of FP (gotta check how Haskell does it :-P).
>
Well, it's not really lazine
On Fri, Feb 7, 2014 at 9:41 PM, Andy C wrote:
> I do perceive sets, lists, vector as atoms which are indivisible (well,
> this is not true but this is popular meaning) from semantics standpoint.
> Therefore map is just a function which processes them as whole, again from
> semantics point of view
On Feb 7, 2014, at 22:17 , Andy C wrote:
> Having map to produce a lazy seq implies that the input must be serializable
> (or linear).
That's just what map is in Clojure: an operation on sequences. It works on
various concrete types because those can be viewed as sequences; map knows
nothing
I actually like the laziness by default but as you suggest, wish there is a
way to switch it on/off for blocks of the code (rather than compiler
option). Scala guys did some research and in most practical cases Lists are
very short hence they are not lazy and evaluated at once. Just an
interesting
Andy C, I think that in the Clojure world, there is a widespread view that
lazy sequences should be the (or one of the) primary datatypes, that
iteration should usually produce lazy sequences, etc. They are something
like the default in Clojure. Clojure includes a systematically organized
and
I do perceive sets, lists, vector as atoms which are indivisible (well,
this is not true but this is popular meaning) from semantics standpoint.
Therefore map is just a function which processes them as whole, again from
semantics point of view. Implementation and laziness should not matter
really a
user=> (map #(mod % 3) #{3 6})
(0 0)
user=> (set (map #(mod % 3) #{3 6}))
#{0}
--
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 that posts from new members are moderated - please be pat
On Sat, Feb 8, 2014 at 3:05 AM, Andy C wrote:
>
> set-s are indeed a sticky point here since the result of a map would
> different depending in the convention.
>
>
No the result would be the same. Only the order of the elements in the lazy
sequence would differ, but that's to be expected since se
On Fri, Feb 7, 2014 at 7:53 PM, Atamert Ölçgen wrote:
> Why should it build a concrete result?
>
I realize the benefits of using LazySeq and do not have a strong opinion
besides things gotta be consistent. Putting practical advantages and having
a good default behaviour aside, I was wondering i
Why should it build a concrete result?
Here's my reasons why it makes sense to be lazy here:
- It would use more memory otherwise. Since, if you are transforming a list
to a set there's got to a transformed copy of the original data structure
when it's materialized.
- It might take longer than ne
Thanks, that's very helpful!
--
--
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 that posts from new members are moderated - please be patient with your
first post.
To unsubscribe fr
Please try these exercises if you want to know what a channel is:
https://github.com/halgari/clojure-conj-2013-core.async-examples/blob/master/src/clojure_conj_talk/core.clj
Op vrijdag 13 december 2013 11:01:57 UTC+1 schreef Joachim De Beule:
>
> Thanks, that indeed did the trick.
>
> More genera
Thanks, that indeed did the trick.
More generally it's not clear to me what makes a channel an "output
channel" or an "input channel". Aren't all channels input and output
channels depending on whether you read from or write to it?
Op vrijdag 13 december 2013 04:28:53 UTC+1 schreef Carlo:
>
On Thu, Dec 12, 2013 at 06:08:11PM -0800, Joachim De Beule wrote:
> I expected to see a sequence of the form "<><><>...". However, only one or
> very few ">" get printed, so I get a sequence "<>>>...". Why?
They're getting buffered. Try this:
(as/pipe (as/map< (fn [x] (print "<") (flush) x) sou
On 26.07.2013 00:34, Brian Craft wrote:
> Is there a better way to do this, making a map of certain keys from a
> list of maps?
>
>> (apply hash-map (mapcat (fn [x] [(x :a) (x :b)]) [{:a "blah" :b "ack"}
> {:a "red" :b "blue"}]))
> {"red" "blue", "blah" "ack"}
Here's another way:
(let [xs [{
You can use whatever functions you want with juxt:
user=> (into {} (map (juxt #(% "a") #(% "b")) [{"a" "blah" "b" "ack"} {"a"
"red" "b" "blue"}]))
{"blah" "ack", "red" "blue"}
On Thursday, July 25, 2013 2:55:18 PM UTC-7, Brian Craft wrote:
>
> Ah, interesting. Only works for keys that are func
I use this:
https://github.com/jaycfields/jry/blob/master/src/clojure/jry/set.clj#L3-L4
On Thu, Jul 25, 2013 at 5:55 PM, Brian Craft wrote:
> Ah, interesting. Only works for keys that are functions.
>
>
> On Thursday, July 25, 2013 2:48:10 PM UTC-7, Gary Trakhman wrote:
>
>> user> (into {} (ma
1 - 100 of 205 matches
Mail list logo
