Another way to do it
(defn apply-map-fn [m f & ks]
(reduce #(update-in %1 [%2] f) m ks))
--
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 -
Inspired by Chas Emerick's Clojure surveys, I have created a survey to
assess the experiences and needs of (potential or actual) users of
ClojureCLR. Building community and lowering barriers to adoption have
to be priorities for this project. I hope this survey will provide
some guidance for this
> Hey, I've got a case where I want to apply a function to *some* values
> in a map but not all. For instance:
>
> (def m { :a 1 :b 1 :c 1 :d 1 })
>
> (defn apply-map-fn [m f & ks]
> (into m (zipmap ks (map f (map #(% m) ks)
>
> (apply-map-fn m inc :a :c)
>
> => { :a 2 :b 1 :c 2 :d 1 }
>
>
On Sat, 2011-10-22 at 12:55 -0700, Mike wrote:
> (defn apply-map-fn [m f & ks]
> (into m (zipmap ks (map f (map #(% m) ks)
>
> Is there a more idiomatic way to do this? Something shorter than
> apply-map-fn I wrote? I.e. something where I don't have to use apply-
> map-fn?
I'm not sure
Ha ! Ok, I missed the digression here and I now understand the issue.
Considering that a PersistentArrayMap may eventually become a PersistentHashMap
this opens the door to *funny* bugs.
Is this the only known case ?
Luc
On Sat, 22 Oct 2011 18:55:52 -0400
Paul Stadig wrote:
> On Sat, Oct 22,
On Sat, Oct 22, 2011 at 5:42 PM, Luc Prefontaine <
lprefonta...@softaddicts.ca> wrote:
> What's missing from your shortened example ?
>
I think what you want is the example I posted originally:
user=> (get {(Long. -1) :here} (Integer. -1))
:here
That works fine because you are actually creating
I was looking for the exact same thing a few months ago. Take a look at this
thread:
http://groups.google.com/group/clojure/browse_thread/thread/a86d8d8c78bcab6b
2011/10/21 Timothy Baldridge
> I'm a bit unsure as to the best way to solve this. Assuming I have the
> following tree:
>
> {:parent
> Note that I'm not claiming to have any deep insights into what's broken and
> what's not, either in Clojure or in Java. All I'm saying is that claiming
> anything along the lines of "Clojure is not Java, so we can do whatever we
> want - contracts do not apply" does not lead to sane map behavi
Your example is so short that I cannot replicate it:
user=> (def a (hash-map -1 :a))
#'user/a
user=> (def b (array-map -1 :a))
#'user/b
user=> (= a b)
true
user=> (= (key (first a)) (key (first b)) -1)
true
I said to myself, "Ok he's been throwing some ints in there":
user=> (def a (hash-map (in
On Saturday, October 22, 2011 4:31:29 PM UTC-4, Luc wrote:
>
> Where's the contract breach here ?
>
Glad you asked. Consider the following clojure session (1.3), shortened for
your reading pleasure:
map-1 => {-1 :yo}
map-2 => {-1 :yo}
key-1 => -1
key-2 => -1
Just some simple maps and val
Simplicity was described as being a property of the artefact, not the
construct wasn't it? So I'm not sure what it means exactly for Clojure to
be simple or complex.
Does Clojure allow you to write artefacts that are simple? Yeah, I think
so, and I think it often makes it easier.
There was a ta
On Sat, Oct 22, 2011 at 10:35 AM, Tim Robinson wrote:
> (is 'complected' even a word? - lol) .
OED: http://photo.pds.org:5004/view/Entry/37640?redirectedFrom=complect#eid
> Do the Clojure language designers plan to make changes to Clojure to
> make it simpler? And if so, how so?
This reminds me
The contract in Clojure is clear, they are only long integer values except if
you cast
them accordingly for Java interop purposes. Anything else is a long so there
are no
contract breaches.
It's not a platform issue, it's a Java issue. Equality is implemented by Java
for objects.
It has nothin
Luc,
On Sat, Oct 22, 2011 at 3:40 PM, Luc Prefontaine <
lprefonta...@softaddicts.ca> wrote:
> All the contracts you mention are language centric, each of them defined
> their contract according
> to their own needs. Clojure should have the right to do so.
>
The contract is required for implement
I'll be there to talk about JVM meta programming (not about Clojure).
On Fri, Oct 21, 2011 at 5:25 AM, Demetrius Nunes
wrote:
> Me too! It's gonna be great!
>
> On Wed, Oct 19, 2011 at 10:30 PM, Abbas wrote:
>>
>> Look forward to your talk.
>>
>> Cheers,
>> Abbas
>>
>> On Oct 18, 5:19 pm, Aaron
Hey, I've got a case where I want to apply a function to *some* values
in a map but not all. For instance:
(def m { :a 1 :b 1 :c 1 :d 1 })
(defn apply-map-fn [m f & ks]
(into m (zipmap ks (map f (map #(% m) ks)
(apply-map-fn m inc :a :c)
=> { :a 2 :b 1 :c 2 :d 1 }
Is there a more id
a) Clojure does not to implement Integer, Byte, ... or any of the number
related Java classes.
It uses native JVM data types. The Integer class has nothing to do with the
JVM primitive types.
These are Java concepts. It has nothing to do with Clojure itself. It's
alien stuff.
Dunno why
On Sat, Oct 22, 2011 at 1:49 PM, Luc Prefontaine <
lprefonta...@softaddicts.ca> wrote:
>
> Java != JVM.
>
> That's a too common mistake. Integer vs Long, Byte, ... are Java creations.
> They have nothing to do with the JVM primitive data types.
>
> Clojure implements a semantic different than Java
On Sat, Oct 22, 2011 at 8:31 AM, Tyler Perkins wrote:
> Just take an idea from Haskell (as usual!). Function 'flip' returns a
> function taking its first two arguments in order opposite the given
> function:
That works nicely for functions with two arguments but in this
situation I tend to have m
Java != JVM.
That's a too common mistake. Integer vs Long, Byte, ... are Java creations.
They have nothing to do with the JVM primitive data types.
Clojure implements a semantic different than Java on top of the JVM, why not ?
That's the whole idea of having the JVM around. Abstracting the metal
So I've read the previous post > Rich Hickey: "Simple Made Easy" from
Strange Loop 2011, but I wanted to ask some simple questions not
complected by the interweaving path the other has post followed (is
'complected' even a word? - lol) .
I know the presentation was, while inclusive of Clojure, no
Just take an idea from Haskell (as usual!). Function 'flip' returns a
function taking its first two arguments in order opposite the given
function:
user> (defn flip [f] (fn [a2 a1 & more] (apply f a1 a2 more)))
#'user/flip
user> (- 10 2 3)
5
user> ((flip -) 2 10 3)
5
user> ((partial < 2000) 1000)
On Sat, Oct 22, 2011 at 9:48 AM, Chas Emerick wrote:
> If Clojure's primary objective were Java interop, I might agree with you.
> However, it's not, and it's bizarre to see someone argue that this is not
> broken:
>
> user=> (.equals (Integer. -1) (Long. -1))
> false
>
> Sure, not broken accord
I agree. Thanks for general guidance on using parameterized queries. I
will switch to use prepared statements instead.
On Oct 22, 3:51 am, Alan Malloy wrote:
> Yep. Rpeating you for emphasis, not repeating myself to disagree with
> you.
>
> On Oct 22, 12:37 am, Sean Corfield wrote:
>
>
>
>
>
>
>
If Clojure's primary objective were Java interop, I might agree with you.
However, it's not, and it's bizarre to see someone argue that this is not
broken:
user=> (.equals (Integer. -1) (Long. -1))
false
Sure, not broken according to the Java object model and its equality semantics,
but damn
2011/10/22 Ivan Koblik :
> I reread your original post, sorry I saw that you managed to declare type
> constrained methods. Then, what was your question about?
I just reread it too and realized I didn't make a whole lot of sense.
I'll try again:
> Do you mean the interface name?
Compiling the fol
On Wednesday, October 19, 2011 10:38:56 AM UTC-4, stuart@gmail.com
wrote:
>Integers and longs are going to be painful no matter what because they are
broken in Java, e.g.
It is incorrect to say that "Integers and longs...are broken in Java."
user=> (.hashCode (Integer. -1))
-1
user=> (.hash
And one more thing to say about polymorphism.
In functional programing protocols are OO polymorphism inside out.
It is possible because FP doesn't care of state, its operates only on
its input and gives outputs (it is by definition - functional).
We are taught from very beginning how to function in
Having watched Rich's talk yesterday, then Stu's "Simple Ain't Easy"
talk an hour ago, I've been trying to wrap my head around this.
What are the benefits of simplicity in the non-compound sense? Stu
mentioned that often we think of simplicity in terms of counting
things and then sort of brushed
A TL;DR update on this in case anyone else has similar issues. Short
version - seriously consider congomongo, clutch etc.
Part 1 - The Past
==
After some thinking, I headed towards deftype, to provide a level of
abstraction atop clojureql.
Queries can be incrementally refined like this (
Yep. Rpeating you for emphasis, not repeating myself to disagree with
you.
On Oct 22, 12:37 am, Sean Corfield wrote:
> On Fri, Oct 21, 2011 at 10:47 PM, Alan Malloy wrote:
> > Can't repeat this strongly enough. Do not, ever, decide you can escape/
> > sanitize the strings yourself so you don't n
On Fri, Oct 21, 2011 at 10:47 PM, Alan Malloy wrote:
> Can't repeat this strongly enough. Do not, ever, decide you can escape/
> sanitize the strings yourself so you don't need a parameterized query.
> Maybe it works, but one of these days you'll slip up and get something
> wrong. Just prepare a s
32 matches
Mail list logo
