To relate this example to the OP's request for a concurrency example:
The Clojure versions shown below, if they are correct at all, are correct in
the face of concurrency.
The Java version is not generally correct, and cannot be made correct without
switching to Clojure's interfaces and persist
This is in fact guaranteed. Eloquent documentation patch welcome.
Stu
The fact that currently having vals and keys return seqs in the same
>>> order is not guaranteed by the documentation ?
>
> At the recent Pragmatic Studio class I asked Rich and Stuart about
> this very point. As I recall
2010/9/21 Meikel Brandmeyer
> Hi,
>
> On 21 Sep., 09:39, Laurent PETIT wrote:
>
> > So (= m1 m2) may not imply (= (zipmap (keys m1) (vals m1)) (zipmap (keys
> m2)
> > (vals m2))) for any (m1, m2), hmmm, good to remember somewhere in my head
> > ... :)
>
> I don't think that this is the case. Wha
Hi,
On 21 Sep., 09:39, Laurent PETIT wrote:
> So (= m1 m2) may not imply (= (zipmap (keys m1) (vals m1)) (zipmap (keys m2)
> (vals m2))) for any (m1, m2), hmmm, good to remember somewhere in my head
> ... :)
I don't think that this is the case. What is meant, is (= (keys m1)
(keys m2)) is not n
2010/9/21 Phil Hagelberg
> On Mon, Sep 20, 2010 at 7:15 PM, David Cabana wrote:
> >> > > The fact that currently having vals and keys return seqs in the same
> >> > order is not guaranteed by the documentation ?
> >
> > At the recent Pragmatic Studio class I asked Rich and Stuart about
> > this
On Mon, Sep 20, 2010 at 7:15 PM, David Cabana wrote:
>> > > The fact that currently having vals and keys return seqs in the same
>> > order is not guaranteed by the documentation ?
>
> At the recent Pragmatic Studio class I asked Rich and Stuart about
> this very point. As I recall, Rich said vals
> > > The fact that currently having vals and keys return seqs in the same
> > order is not guaranteed by the documentation ?
At the recent Pragmatic Studio class I asked Rich and Stuart about
this very point. As I recall, Rich said vals and keys do behave as one
would hope, so that for a map m we
2010/9/21 Meikel Brandmeyer
> Hello Laurent.
>
> Am 20.09.2010 um 22:38 schrieb Laurent PETIT:
>
> > The fact that currently having vals and keys return seqs in the same
> order is not guaranteed by the documentation ?
>
> Touché. Hard to swallow the own pill. It is not mentioned in the
> documen
Hello Laurent.
Am 20.09.2010 um 22:38 schrieb Laurent PETIT:
> The fact that currently having vals and keys return seqs in the same order is
> not guaranteed by the documentation ?
Touché. Hard to swallow the own pill. It is not mentioned in the documentation,
but it is chouser's believe that
2010/9/20 Meikel Brandmeyer
> Hi,
>
> Am 20.09.2010 um 18:52 schrieb John Cromartie:
>
> >> (def flip-map #(apply zipmap ((juxt vals keys) %)))
> >>
> >
> > If I was going to write flip-map it might be a tad longer, but lazy
> > and a bit clearer (IMO), with:
> >
> >(defn flip-map [m] (into {
Hi,
Am 20.09.2010 um 18:52 schrieb John Cromartie:
>> (def flip-map #(apply zipmap ((juxt vals keys) %)))
>>
>
> If I was going to write flip-map it might be a tad longer, but lazy
> and a bit clearer (IMO), with:
>
>(defn flip-map [m] (into {} (map (juxt second first) m)))
Is there some
There's no such thing as a lazy map. into uses reduce, which is
necessarily not lazy either.
Clarity is in the eye of the beholder, of course. I think my version
is clearer, but if you replaced second/first with val/key I'd rate
them about the same. You might even replace (just val key) with
rever
On Sep 20, 12:08 pm, Alan wrote:
> A few days ago I was thinking about how different it would be to write
> flip-map* in Java vs Clojure. A very simple, small program, but easy
> to see how Clojure can be more expressive.
>
> public static Map flipMap(Map map)
> {
> Map result = new HashMap(ma
Oh, I see you put the word "concurrency" in the subject but don't
mention it in your post. I guess my example isn't interesting for you,
then. You will get better responses if you put all relevant
information in the actual body - the subject is a space to summarize
the body, not to add to it.
On S
A few days ago I was thinking about how different it would be to write
flip-map* in Java vs Clojure. A very simple, small program, but easy
to see how Clojure can be more expressive.
public static Map flipMap(Map map)
{
Map result = new HashMap(map.size());
for (K key : map.keys()) {
I'm new to clojure, so sorry if this is a dummie question.
Studyng clojure I can understand the syntax and so onbut I would
like a real example comparing clojure and java.
Do you know some benchmark using first just java and than showing the
best results with clojure ?
--
You received this
16 matches
Mail list logo