When you state a function you bind it already to an implementation, in fact
to a specific function from a specific ns.
While for simple functions its not that bad, things start to get hairy when
you manage a large number of custom validations also using just string?
leaves out metadata (like er
Why not just use functions for the validations? string? instead of :String.
Then you get disjunction for free.
On Sat, Jul 27, 2013 at 12:22 PM, ronen wrote:
>
> Thanks for the feedback!
>
> Hi,
>>
>> Some feedback and questions, as I've made something similar in the past.
>> - allow normal fns
Thanks for the feedback!
Hi,
>
> Some feedback and questions, as I've made something similar in the past.
> - allow normal fns and classes as a predicates.
>
- having one global Var for predicates is an antipattern
>
The Var is only for the built in ones and is internal and private, external
Hi,
Some feedback and questions, as I've made something similar in the past.
- allow normal fns and classes as a predicates.
- having one global Var for predicates is an antipattern
- can you compose predicates logically (AND/OR)?
- can you validate a contents of the vector?
As an inspiration, t
Substantiation is an opinionated simple nested map validation library:
- Predicates and description kept separate.
- Validation description map follows validated input structure.
- Pure data structures to describe validations.
- Composability of validations is trivial.
- Validati
The implementation(s) acts a bit counter-intuitive on non-nested maps:
FAIL in (deep-merge-test) (test.clj:5)
expected: (= (merge {:a 1, :d 1} {:a 2, :c 1}) (deep-merge {:a 1, :d 1} {:a
2, :c 1}))
actual: (not (= {:c 1, :a 2, :d 1} {:a 2, :c 1}))
ERROR in (deep-merge-with-test) (Numbers.java
>>
>> -S
>>
>>
>>
>> On Thursday, April 25, 2013 4:41:33 PM UTC-4, Joachim De Beule wrote:
>>>
>>> Hi list,
>>>
>>> I was searching for an "easy" way to combined nested maps, e.g. as in
>>>
>>> (combine {:fo
deep-merge vals)
> (last vals)))
>
> -S
>
>
>
> On Thursday, April 25, 2013 4:41:33 PM UTC-4, Joachim De Beule wrote:
>>
>> Hi list,
>>
>> I was searching for an "easy" way to combined nested maps, e.g. as in
>>
>> (combine {:foo {
;
> > On Thursday, April 25, 2013 4:41:33 PM UTC-4, Joachim De Beule wrote:
> >>
> >> Hi list,
> >>
> >> I was searching for an "easy" way to combined nested maps, e.g. as in
> >>
> >> (combine {:foo {:bar "baz"}} {:foo
ot;
> [& vals]
> (if (every? map? vals)
> (apply merge-with deep-merge vals)
> (last vals)))
>
> -S
>
>
>
>
> On Thursday, April 25, 2013 4:41:33 PM UTC-4, Joachim De Beule wrote:
>>
>> Hi list,
>>
>> I was searchin
[& vals]
(if (every? map? vals)
(apply merge-with deep-merge vals)
(last vals)))
-S
On Thursday, April 25, 2013 4:41:33 PM UTC-4, Joachim De Beule wrote:
>
> Hi list,
>
> I was searching for an "easy" way to combined nested maps, e.g. as in
>
> (co
Greevey wrote:
Seems you want a cross between update-in and merge. Maybe something
like this?
(defn combine
"Merge maps, recursively merging nested maps whose keys collide."
([] {})
([m] m)
([m1 m2]
(reduce (fn [m1 [k2 v2]]
(if-let [v1 (get m1 k2)]
Seems you want a cross between update-in and merge. Maybe something like
this?
(defn combine
"Merge maps, recursively merging nested maps whose keys collide."
([] {})
([m] m)
([m1 m2]
(reduce (fn [m1 [k2 v2]]
(if-let [v1 (get m1 k2)]
(if (an
On Apr 25, 2013, at 15:41 , Joachim De Beule wrote:
> I was searching for an "easy" way to combined nested maps, e.g. as in
>
> (combine {:foo {:bar "baz"}} {:foo {:x "y"}})
> => {:foo {:bar "baz", :x "y"}}
user=> (merge-with
Hi list,
I was searching for an "easy" way to combined nested maps, e.g. as in
(combine {:foo {:bar "baz"}} {:foo {:x "y"}})
=> {:foo {:bar "baz", :x "y"}}
I would expect that there is some core map operation to do this, but
neither me
Here are some potentially interesting observations. First, as similar
lazy and eager versions as I could come up with:
(defn flatten-maps-lazy [coll]
(lazy-seq
(when-let [s (seq coll)]
(let [m (first s)]
(cons (dissoc m :c)
(flatten-maps-lazy
(con
2011/4/14 Meikel Brandmeyer :
> Hi,
>
> On 14 Apr., 11:35, Laurent PETIT wrote:
>
>> I don't understand either.
>> Anyway, if there is no flaw in the tests, this could end as a good
>> example of where premature optimization (of CPU at least) via recur
>> does not get the expected result !
>
> Alw
Hi,
On 14 Apr., 11:35, Laurent PETIT wrote:
> I don't understand either.
> Anyway, if there is no flaw in the tests, this could end as a good
> example of where premature optimization (of CPU at least) via recur
> does not get the expected result !
Always prove your assumptions. But I'm still s
2011/4/14 Meikel Brandmeyer :
> Hi again,
>
> On 14 Apr., 09:42, Laurent PETIT wrote:
>
>> What could explain the result of your tests ? (I'm really curious !)
>
> On the other hand the lazy version really just creates a simple linked
> list with some fast boilerplate concerning the laziness. The
Hi again,
On 14 Apr., 09:42, Laurent PETIT wrote:
> What could explain the result of your tests ? (I'm really curious !)
On the other hand the lazy version really just creates a simple linked
list with some fast boilerplate concerning the laziness. The vectors
however *are* more involved to con
Hi Laurent,
On 14 Apr., 09:42, Laurent PETIT wrote:
> Doesn't it seem counter intuitive to you that the lazy version is the
> fastest ?
>
> What could explain the result of your tests ? (I'm really curious !)
This is exactly the question I had earlier in this thread. :) I was
also surprised by
And more numbers. d-small does not contain vectors with more than 50
elements, so the unrolled version should always hit a special case in
this run. However it's still twice as slow as the eager versions. The
lazy version is still the fastest.
user=> (bench (doall (flatten-maps d-small)))
Evaluati
Hi,
On 14 Apr., 01:18, Kevin Downey wrote:
> I beg your pardon, if you don't understand then it must have been sent
> to you in error, please accept my apologies.
I'm sorry. I was confused. Here a new set of measurements with
different input and different machine. Including your unrolled
versio
I beg your pardon, if you don't understand then it must have been sent
to you in error, please accept my apologies.
On a side note: what does "this asian trait" have to do with anything?
On Wed, Apr 13, 2011 at 3:00 PM, Meikel Brandmeyer wrote:
> Hi,
>
> Am 13.04.2011 um 23:44 schrieb Kevin Down
Hi,
Am 13.04.2011 um 23:44 schrieb Kevin Downey:
> https://gist.github.com/918487
I never understood this asian trait of pointing to something and then leaving
the other without clue. Do you care to enlighten me, what I'm missing?
Sincerely
Meikel
--
You received this message because you are
https://gist.github.com/918487
On Wed, Apr 13, 2011 at 11:56 AM, Meikel Brandmeyer wrote:
> Hmm…
>
> I did the following timings with criterium. d is a random data structure
> generated by virtue of the following function:
>
> user=> (defn data
> [size]
> (let [l (rand-int size)
Hmm…
I did the following timings with criterium. d is a random data structure
generated by virtue of the following function:
user=> (defn data
[size]
(let [l (rand-int size)
l2 (/ l 2)]
(repeatedly l #(array-map :a 1 :b 2 :c (vec (data l2))
The t
On 13 abr, 20:14, Alex Robbins wrote:
> That has tricked me before. The lazy one is fastest because all you
> are timing is the creation of the lazy seq, not its realization. Wrap
> the lazy seq in a doall inside the time macro.
Didn't know. Thanks !!
Now the timing of the lazy one is clearly
That has tricked me before. The lazy one is fastest because all you
are timing is the creation of the lazy seq, not its realization. Wrap
the lazy seq in a doall inside the time macro.
On Wed, Apr 13, 2011 at 12:59 PM, babui wrote:
> I was asking because my timings show that the lazy version is t
I was asking because my timings show that the lazy version is the
fastest one.
My (very simple & stupid) test is:
(defn flatten-maps
"The original one"
)
(defn flatten-maps-lazy
"The lazy one"
)
(defn flatten-maps-eager
"The eager one"
)
(defn flatten-maps-r
(time (...)) I guess.
http://clojuredocs.org/clojure_core/clojure.core/time
On Wed, Apr 13, 2011 at 6:38 PM, babui wrote:
> A solution using recur:
>
> (defn flatten-maps-recur
> ([ms] (flatten-maps-recur ms ()))
> ([ms fl] (if-let [[f & r] (seq ms)]
> (recur (concat
A solution using recur:
(defn flatten-maps-recur
([ms] (flatten-maps-recur ms ()))
([ms fl] (if-let [[f & r] (seq ms)]
(recur (concat (get f :c) r) (cons (dissoc f :c)
fl))
fl)))
Please, can you publish how are you doing your timings?
Thanks,
JM
On Wed, Apr 13, 2011 at 8:19 PM, Meikel Brandmeyer wrote:
> Did you also check the eager one?
Yes, I did. That one was much faster but still took double the time than mine.
Regards,
BG
--
Baishampayan Ghose
b.ghose at gmail.com
--
You received this message because you are subscribed to the
Hi,
On 13 Apr., 16:13, Baishampayan Ghose wrote:
> Sorry, I checked it with incorrect data. Your solution works just
> fine, only that it's slower than mine (don't know why).
Did you also check the eager one?
Sincerely
Meikel
--
You received this message because you are subscribed to the Goo
On Wed, Apr 13, 2011 at 6:04 PM, Meikel Brandmeyer wrote:
> Both work for me, although in the flatten-maps-lazy there is a typo in
> the recursive call. It should be named flatten-maps-lazy there, too.
Sorry, I checked it with incorrect data. Your solution works just
fine, only that it's slower t
Hi,
On 13 Apr., 14:25, Baishampayan Ghose wrote:
> By the way, both of your functions raised ClassCastException.
Both work for me, although in the flatten-maps-lazy there is a typo in
the recursive call. It should be named flatten-maps-lazy there, too.
user=> (defn flatten-maps-lazy
[coll]
On Wed, Apr 13, 2011 at 4:42 PM, Meikel Brandmeyer wrote:
> However your specification was not very clear how the ordering of the
> flatten should be. The above reflects the intent as far as I
> understood it. Your implementation was also not clear because you mix
> conj with vectors and sequences
Hi,
haha! Golf! I haven't tested the speed, but this should be straight-
forward:
(defn flatten-maps-lazy
[coll]
(lazy-seq
(when-let [s (seq coll)]
(let [m (first s)]
(cons (dissoc m :c) (flatten-maps (concat (get m :c) (rest
s
However your specification was not ver
Hi,
I have a peculiar sequence of nested maps which have the following structure -
{:a 1 :b 1 :c []}
The keys :a & :b always have scalar values but the :c key can have
either an empty vector or a vector of maps of the same kind. For
example -
{:a 1 :b 1 :c [{:a 1 :b 1 :c [{:a 1 :b
On Wed, Jan 28, 2009 at 10:31 PM, Vincent Foley wrote:
>
> (-> person :employer :address :city) would be my pick
I tend to prefer this method as well. I find that doto and -> in
general are excellent tools for picking apart and poking nested
structures.
>
> Vincent
>
> On Jan 28, 4:02 pm, Mark
On Wed, Jan 28, 2009 at 4:02 PM, Mark Volkmann
wrote:
>
> Is this the best way to retrieve the employer city?
> (reduce get person [:employer :address :city])
That's the definition of 'get-in', but the -> suggestion sounds good too.
> Is this the best way to get a new map where the city is chan
(-> person :employer :address :city) would be my pick
Vincent
On Jan 28, 4:02 pm, Mark Volkmann wrote:
> I have a map that describes a person.
> It has a key that describes their address.
> It also has a key for their employer.
> The employer has its own address.
>
> (def person {
> :name "Ma
I have a map that describes a person.
It has a key that describes their address.
It also has a key for their employer.
The employer has its own address.
(def person {
:name "Mark Volkmann"
:address {
:street "644 Glen Summit"
:city "St. Charles"
:state "Missouri"
:zip 63304}
43 matches
Mail list logo
