Fork me on GitHub
#beginners
<
2017-06-18
>
vitruvia00:06:47

is there a way to eval a piece of code and insert it in a separate window on vim? (as to keep a visual history of commands used)

seancorfield00:06:57

@vitruvia You might check the #vim-fireplace room and see if anyone can help you there?

seancorfield00:06:21

(also bear in mind it's late afternoon on Saturday and that tends to be a quiet time in here)

petterik05:06:00

Regarding (first (filter pred? ...)): If I'm not mistaken, filter will return a chunked-seq, which will return a seq up to 32 elements when doing (first (filter pred? ...)). See:

(first (filter #(do (prn %) (some? %)) (into [] (range 1e3))))
;; prints  0 1 2 3 4 .. 31
;; returns 0
If it's important that you process as few items as possible you can use some instead of first and filter, but you'll have to wrap your pred? in #(when (pred? %) %):
(some #(do (prn %) (when (some? %) %)) (into [] (range 1e3)))
;; prints  0
;; returns 0

seancorfield06:06:55

(this is why it's important to have side-effect-free sequence generation)

weavejester21:06:11

In Medley, there’s a find-first function that uses (reduce (fn [_ x] (if (pred x) (reduced x))) nil coll)

weavejester21:06:48

Reducing avoids the problem with chunked seqs, and is generally faster.

drewverlee22:06:31

why implement functions with multiply arity in this fashion?

# [org.clojure/clojure "1.8.0"] clojure.core/apply

## Usages
  [f args]
  [f x args]
  [f x y args]
  [f x y z args]
  [f a b c d & args]
is it convince? Is its necessary? does it make creating the function easier? or using the function?

drewverlee22:06:06

as opposed to [f & args]

noisesmith22:06:32

it performs better

noisesmith22:06:15

don't write normal code that way, but clojure.core is in everyone's "hot path" so they do make things the most performant way, even if it looks weird