Re: Lots of newbie clojure questions
On Tue, Dec 7, 2010 at 2:15 AM, javajosh wrote: > Mike and I have had a nice off-line conversation where we enumerated > the possible things that can come after open-parens. I listed 7, he > added 3: > >> 1. A value (if the paren has a tick '( ) >> 2. A function. >> 3. A map - which is a psuedo function that takes a key as an arg. >> 4. A keyword - which is a psuedo function that takes a map as an arg. >> 5. A macro. This is the normal case, I think. Looking through the mailing >> list, it appears that most clojure programming questions revolve around >> which one of the hundreds of macros to invoke and in which order! >> 6. The Java form: (MyClass. ) >> 7. The java method form (.doSomething) > 8. A function returning a function to invoke - ((find-my-function) ) > 9. A loop - (recur ) > 10. The anonymous function macro: #( ) > > So, at least I know why I feel uneasy about open paren! It's super > overloaded. Not really. (...) is a non-atomic s-expression. If it's evaluated unquoted, the first nested s-expression is evaluated and if it's not callable an exception is thrown. Macros, special forms (which are sort of like system-internal macros and are used to build all the other macros, and functions), Java constructors, Java methods, and functions are callable (and maps and keywords -- also vectors -- act as functions for this purpose). The only real overloading always involves macros: #() evaluates to a function and doesn't run its insides right away. Then again so does (defn foo [x] (inc x)) -- the (inc x) is run when foo is called, calling inc, but not when the (defn ...) is called. Macros can delay evaluation of their contents, and #() is a reader macro. '(x y z) is another reader macro and expands to (quote (x y z)). And lastly some macros use a Common Lisp style of expecting a parenthesized list argument whose first element isn't (at some point) called as an invokable of some sort. The ns macro is particularly guilty of this. I say guilty because I think it's bad design, which I guess may have been grandfathered in before the standard was settled on to use [] around non-executable lists of data such as binding lists. (In some cases the first element, e.g. when it's :use or :require, can be thought of as a pseudo-operator defined solely within the ns form. I don't have an objection in cases where the first element of the list can be thought of as a command or a call of some sort. But many of the nested inputs to e.g. :use have the stain.) But (x y z w) is similar to C's x(y z w); or Java's y.x(z w); in what it generally means. Except when quoted, or in a few macro arguments (particularly, ns arguments). > Mike also points out that things that aren't functions (not used in > that context) can't be aliased with def or use. Really? user=> (def a 3) #'user/a user=> (def b a) #'user/b user=> b 3 -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: math utilities question
Standard way, definitely no. As others have pointed out, Incanter is The Clojure Math Tool, but strongly biased towards statistics and linear algebra, and outside those fields you'll need other tools. Apache Commons Math (http://commons.apache.org/math/) is one of the better self-contained Java math libraries. I think it can do at least 4 (in one dimension), 5, and 7 (e.g. Levenberg-Marquardt). Another tool worth mentioning is jHepWork (http://jwork.org/ jhepwork/). It contains an impressive collection of various numerical Java libraries glued together, using Jython as its scripting language. Probably it wouldn't be too hard to glue Clojure into it, but how idiomatic it would be is another question... Best Regards, Joonas On Dec 6, 1:27 am, Robert McIntyre wrote: > I'm trying to use clojure for scientific data analysis but I keep > running into lacunas of functionality. > > I'd love to hear the community's recommendations and experiences with this: > > Is there a standard way to do things like: > 1. take the convolution of two vectors > 2. work with imaginary numbers, quaternions, octonions, etc > 3. work with matrices of arbitrary dimension > 4. Fourier transform ( in multiple dimensions) > 5. integration / finite difference > 6. symbolic manipulation as in sage > 7. minimizing non-linear functions > 8. finding zeros of non-linear functions > > thank you all in advance for any recommendations you might have. > > --Robert McIntyre -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: math utilities question
(defmacro defchunk [name tps] `(def ~name (quote ~tps))) (defmacro let-chunk [vname name val-vec & body] (let [chunk-def @(resolve name) types (map first chunk-def) part-names (map (comp symbol (partial str vname "!") second) chunk-def)] `(let [~vname ~val-vec ~@(interleave part-names (map #(list %1 (list vname %2)) types (iterate inc 0)))] ~...@body))) user=> (defchunk foo [[int x][double y]]) #'user/foo user=> (let-chunk afoo foo [1 1.7] afoo) [1 1.7] user=> (let-chunk afoo foo [1 1.7] afoo!x) 1 user=> (let-chunk afoo foo [1 1.7] afoo!y) 1.7 Simple enough, and afoo!x and afoo!y are primitive. (defchunk complex [[double real][double imag]]) (defn cx-mult [w z] (let-chunk w complex w (let-chunk z complex z [(- (* w!real z!real) (* w!imag z!imag)) (+ (* w!imag z!real) (* w!real z!imag))]))) (after a few runs to get it all JITted) user=> (time (nth (iterate #(cx-mult % %) [0.0 1.0]) 1)) "Elapsed time: 14.12232 msecs" [1.0 -0.0] Looks like one iteration taking less than 2 microseconds to me. And that's with iterate. Loop gives this: user=> (time (loop [c [0.0 1.0] n 1] (if (= n 0) c (recur (cx-mult c c) (dec n) "Elapsed time: 2.54112 msecs" [1.0 -0.0] Interestingly, using definline to define cx-mult slows this down instead of speeding it up. Another macro could give you a super-defn that let-chunks certain function parameters, so the (let-chunk foo bar foo ...) stuff wrapping the body of cx-mult disappears into a macro. Yet another could give you a loop-chunk. For truly high performance, though, the vector boxing is a problem. JIT doesn't seem to be eliminating it, or the speed would be up to 1000x faster still. Defstruct/defrecord is probably what's needed here; this would mean a) modifying defchunk to emit a suitable defstruct/defrecord in addition to the type-partname pairs structure and b) making the other macros destructure these instead of vectors. But the above shows a working, if crude, first pass at implementing the facility under discussion in this thread. Replacing vectors with structmaps/records in it will probably produce a large speedup when the things are passed across function boundaries. The remaining bugbear will be that the let-chunk and loop-chunk will create a heap allocated structmap/record even if it's unused. Having the macros detect if it's unused might not be easy. I'm unsure, though, that heap allocation is as horrid as everyone here seems to be assuming it to be. It may be horribly slow in FORTRAN or even in C but modern JVMs make heap allocation very cheap. I wouldn't be surprised if using heap-allocated structmaps or records directly will do fine. There are also supposed to be more optimizations for primitive use, including passing across function boundaries, in the forthcoming Clojure 1.3. -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Lots of newbie clojure questions
On Dec 6, 6:01 pm, Mike Meyer wrote: Mike and I have had a nice off-line conversation where we enumerated the possible things that can come after open-parens. I listed 7, he added 3: > 1. A value (if the paren has a tick '( ) > 2. A function. > 3. A map - which is a psuedo function that takes a key as an arg. > 4. A keyword - which is a psuedo function that takes a map as an arg. > 5. A macro. This is the normal case, I think. Looking through the mailing > list, it appears that most clojure programming questions revolve around > which one of the hundreds of macros to invoke and in which order! > 6. The Java form: (MyClass. ) > 7. The java method form (.doSomething) 8. A function returning a function to invoke - ((find-my-function) ) 9. A loop - (recur ) 10. The anonymous function macro: #( ) So, at least I know why I feel uneasy about open paren! It's super overloaded. Mike also points out that things that aren't functions (not used in that context) can't be aliased with def or use. -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Lots of newbie clojure questions
On Dec 6, 6:24 pm, Robert McIntyre wrote: > @javajosh You're speaking of the Turing description of computation, > you might be interested in Church's lambda calculus description which > works just as well and doesn't use mutability to describe computation, Thanks, I'll look into that. Is there a difference in the "simplest possible physical representation" of a "Church" vs. a "Turing" machine? -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Moderately off-topic: installing emacs on OSX
On Dec 6, 9:16 pm, Phil Hagelberg wrote: > On Mon, Dec 6, 2010 at 9:00 PM, javajosh wrote: > > Sorry for asking here, but I think it's at least a little relevant to > > Clojure since I for one wouldn't be installing emacs if it wasn't for > > Clojure and Slime. Getting prompts about what the function arguments > > are seems like a HUGE benefit when learning this langauge. I imagine > > other non-emacs people might have a related question, so I'll give > > asking this question a shot. > > >>sudo ports install slime > > Swank Clojure (the Clojure adapter for SLIME) depends on a particular > version of Slime; the one in Macports is probably not it. I recommend > installing via package.el instead as the swank-clojure readme > suggests:https://github.com/technomancy/swank-clojure#readme Thanks Phil, I'll give that a shot. -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
[OT] ASF loses Java showdown vote to Oracle
Hello, http://www.theregister.co.uk/2010/12/07/apache_google_vote_no_oracle_roadmap/ http://news.ycombinator.com/item?id=1977720 Does this mean anything for Clojure (on the JVM)? Regards, BG -- Baishampayan Ghose b.ghose at gmail.com -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: mapmap?
Ahh apply does it again! I saw how the code be simplified, but just tonight learned how apply can be used in situations like this. -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: How can I avoid needing this other function?
On 10-12-07 01:37 AM, Alex Baranosky wrote: Hello Alexandre, This code makes my tests pass: (defn distances [origin & locations] (map #(dist-in-miles origin %) locations)) (defn map-of-distances [origin & locations] (apply hash-map (interleave locations (apply distances origin locations Glad it helped :) Alex -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: How can I avoid needing this other function?
Hello Alexandre, This code makes my tests pass: (defn distances [origin & locations] (map #(dist-in-miles origin %) locations)) (defn map-of-distances [origin & locations] (apply hash-map (interleave locations (apply distances origin locations Thanks for the inspiration! -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: math utilities question
On Tue, Dec 7, 2010 at 12:58 AM, Konrad Hinsen wrote: > On 06.12.2010, at 22:35, Ken Wesson wrote: > >>> I'd say what Java needs is not complex numbers as a value type, but a way >>> to define additional value types. Complex numbers are just one >>> applications. Another one is points (2D or 3D) for geometry and graphics. >>> >>> Unfortunately the problem is not just Java, but the JVM, meaning that >>> Clojure inherits the problem. >> >> Clojure does not inherit the problem, if you use macros cleverly. You >> can stack allocate individual primitives, separately, e.g. >> >> (let [x (int 3) y (double 4.2)] >> ...) >> >> And with macros you can wrap that in an abstraction that looks like a >> single object, such as a point or a complex number. Passing it to a >> function would require a bit of magic, though -- say, bundling the > > That's exactly the problem. An abstraction that doesn't pass a function > boundary is of little use in a functional language. Decomposing complex > numbers or points into primitives can be used as a local optimization > technique, but not in a larger-scale design for software systems. First of all, the abstraction does pass the function boundary if the function's a closure and you get it from the lexical scope rather than passing it as an argument. Second, macros can probably be used to make passing them as arguments and returning them transparent to the coder, in a way that boils away to nothing when the -server JIT goes to work on it. I can try to code a rough draft of such a facility and post it later. -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: mapmap?
On Tue, Dec 7, 2010 at 12:04 AM, Alex Baranosky
wrote:
> I think it will be fun to come up with a solution that will work with n
> maps:
> (defn multi-fmap [f &maps]
> ...)
> i.e.
> (multi-fmap #(+ %1 %1 %2 ) {:a 1 :b 2} {:a 3 :b 4}) => {:a 5 :b 8}
> (multi-fmap #(+ %1 %2 %3 ) {:a 1 :b 2} {:a 3 :b 4} {:a 5 :b 6}) => {:a 9 :b
> 12}
(defn multi-fmap [f & maps]
(into {}
(for [k (keys (first maps))]
[k (apply f (map #(get % k) maps))])))
works for your two test-cases. It assumes that the keys you're
interested in are exactly the keys of the first map; if any map is
missing a key the function will get a nil argument in the position
corresponding to that map when computing the result's value for that
key.
--
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 from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: How can I avoid needing this other function?
On 10-12-07 12:44 AM, Alex Baranosky wrote:
Here is the code I'm working on. The first function is wanted. The
second is not. (and the duplication is waiting to be factored out
somehow...)
Is there an idiomatic Clojure way to use map-of-distances on the "Line
of Note" below, instead of map-of-distances* ?
you could use (apply map-of-distances origin (take-nth 2
locations-n-frequencies)), but I would also rewrite map-of-distances to
something like:
(defn distances
[origin & locations]
(map (fn [l] [l (dist-in-miles origin l)]) locations))
(defn map-of-distances
[origin & locations]
(into {} (distances origin & locations))
Alex
Thanks for all your help.
(defn map-of-distances [origin & locations]
(loop [dists {} locs locations]
(if (seq locs)
(let [[loc & more] locs
dist (dist-in-miles origin loc)
dists (assoc dists loc dist)]
(recur dists more))
dists)))
(defn map-of-distances* [origin locations]
(loop [dists {} locs locations]
(if (seq locs)
(let [[loc & more] locs
dist (dist-in-miles origin loc)
dists (assoc dists loc dist)]
(recur dists more))
dists)))
(defn relative-distance
"Gives distance * frequency.
frequencies are in days out of 365"
[origin & locations-n-frequencies]
(let [loc-w-dists (map-of-distances* origin (take-nth 2
locations-n-frequencies)) ; <-- Line of Note
loc-w-freqs (apply hash-map locations-n-frequencies)]
(multi-fmap (fn [d f] (* d f)) loc-w-dists loc-w-freqs)))
--
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 from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
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 from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: How can I avoid needing this other function?
On Tue, 7 Dec 2010 00:44:52 -0500
Alex Baranosky wrote:
> Here is the code I'm working on. The first function is wanted. The second
> is not. (and the duplication is waiting to be factored out somehow...)
>
> Is there an idiomatic Clojure way to use map-of-distances on the "Line of
> Note" below, instead of map-of-distances* ?
>
> Thanks for all your help.
>
> (defn map-of-distances [origin & locations]
> (loop [dists {} locs locations]
> (if (seq locs)
> (let [[loc & more] locs
> dist (dist-in-miles origin loc)
> dists (assoc dists loc dist)]
> (recur dists more))
> dists)))
>
> (defn map-of-distances* [origin locations]
> (loop [dists {} locs locations]
> (if (seq locs)
> (let [[loc & more] locs
> dist (dist-in-miles origin loc)
> dists (assoc dists loc dist)]
> (recur dists more))
> dists)))
>
> (defn relative-distance
> "Gives distance * frequency.
> frequencies are in days out of 365"
> [origin & locations-n-frequencies]
> (let [loc-w-dists (map-of-distances* origin (take-nth 2
> locations-n-frequencies)) ; <-- Line of Note
> loc-w-freqs (apply hash-map locations-n-frequencies)]
> (multi-fmap (fn [d f] (* d f)) loc-w-dists loc-w-freqs)))
I haven't verified it, but based on the two interfaces, you want to
use apply again:
(map-of-distances* origin (take-nth 2 locations-n-frequencies))
can be written as:
(apply map-of-distances origin (take-nth 2 locations-n-frequencies))
FWIW, if you really needed them both, it'd be idiomatic to write one
in terms of the other:
(defn map-of-distances [origin & locations]
(map-of-distances* origin locations))
or (going the other way):
(defn map-of-distances* [origin locations]
(apply map-of-distances origin locations))
though this one you might not bother to write out, and just use the
apply inline as above.
http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
--
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 from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: math utilities question
On 06.12.2010, at 22:35, Ken Wesson wrote: >> I'd say what Java needs is not complex numbers as a value type, but a way to >> define additional value types. Complex numbers are just one applications. >> Another one is points (2D or 3D) for geometry and graphics. >> >> Unfortunately the problem is not just Java, but the JVM, meaning that >> Clojure inherits the problem. > > Clojure does not inherit the problem, if you use macros cleverly. You > can stack allocate individual primitives, separately, e.g. > > (let [x (int 3) y (double 4.2)] > ...) > > And with macros you can wrap that in an abstraction that looks like a > single object, such as a point or a complex number. Passing it to a > function would require a bit of magic, though -- say, bundling the That's exactly the problem. An abstraction that doesn't pass a function boundary is of little use in a functional language. Decomposing complex numbers or points into primitives can be used as a local optimization technique, but not in a larger-scale design for software systems. Konrad. -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
How can I avoid needing this other function?
Here is the code I'm working on. The first function is wanted. The second
is not. (and the duplication is waiting to be factored out somehow...)
Is there an idiomatic Clojure way to use map-of-distances on the "Line of
Note" below, instead of map-of-distances* ?
Thanks for all your help.
(defn map-of-distances [origin & locations]
(loop [dists {} locs locations]
(if (seq locs)
(let [[loc & more] locs
dist (dist-in-miles origin loc)
dists (assoc dists loc dist)]
(recur dists more))
dists)))
(defn map-of-distances* [origin locations]
(loop [dists {} locs locations]
(if (seq locs)
(let [[loc & more] locs
dist (dist-in-miles origin loc)
dists (assoc dists loc dist)]
(recur dists more))
dists)))
(defn relative-distance
"Gives distance * frequency.
frequencies are in days out of 365"
[origin & locations-n-frequencies]
(let [loc-w-dists (map-of-distances* origin (take-nth 2
locations-n-frequencies)) ; <-- Line of Note
loc-w-freqs (apply hash-map locations-n-frequencies)]
(multi-fmap (fn [d f] (* d f)) loc-w-dists loc-w-freqs)))
--
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 from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Moderately off-topic: installing emacs on OSX
On Mon, Dec 6, 2010 at 9:00 PM, javajosh wrote: > Sorry for asking here, but I think it's at least a little relevant to > Clojure since I for one wouldn't be installing emacs if it wasn't for > Clojure and Slime. Getting prompts about what the function arguments > are seems like a HUGE benefit when learning this langauge. I imagine > other non-emacs people might have a related question, so I'll give > asking this question a shot. > >>sudo ports install slime Swank Clojure (the Clojure adapter for SLIME) depends on a particular version of Slime; the one in Macports is probably not it. I recommend installing via package.el instead as the swank-clojure readme suggests: https://github.com/technomancy/swank-clojure#readme -Phil -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: easiest way to make a map out of a list?
ah, I had tried hash-map without apply, but yours actually works. :)
Thanks.
On Tue, Dec 7, 2010 at 12:06 AM, Sunil S Nandihalli <
sunil.nandiha...@gmail.com> wrote:
>
>
> On Tue, Dec 7, 2010 at 10:31 AM, Alex Baranosky <
> alexander.barano...@gmail.com> wrote:
>
>> Way I have
>
>
>
>
>> (apply hash-map [:a 1:b 2])
>
>
>
>
>> and I want to convert it to {:a 1 :b 2}
>>
>> What's the idiomatic way to do this in Clojure?
>>
>> Thanks for the help,
>> Alex
>>
>> --
>> 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 from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>
>
> --
> 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 from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
--
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 from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: easiest way to make a map out of a list?
On Tue, Dec 7, 2010 at 10:31 AM, Alex Baranosky <
alexander.barano...@gmail.com> wrote:
> Way I have
> (apply hash-map [:a 1:b 2])
> and I want to convert it to {:a 1 :b 2}
>
> What's the idiomatic way to do this in Clojure?
>
> Thanks for the help,
> Alex
>
> --
> 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 from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
--
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 from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Swank-clojure: "unreadable message"
On Mon, Dec 6, 2010 at 2:13 PM, Philip Hudson wrote:
> Now, in emacs, after doing `M-x slime-connect' and accepting the default
> prompt values, I get the fancy slime animation, but swank-clojure
> 1.3.0-SNAPSHOT immediately throws:
>
>> unreadable message: (:emacs-rex (swank:autodoc (quote ("+"
>> swank::%cursor-marker%)) :print-right-margin 106) "user" :repl-thread 4)
>
> CVS SLIME 04-Dec-2010
Swank Clojure needs the "stable" version of SLIME; CVS is highly
unstable. The easiest way to install is under "Connecting with SLIME"
in swank's readme, though you can use my fork on github if you want to
install from source for some reason:
https://github.com/technomancy/slime/tree/elpa-2010
-Phil
--
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 from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: mapmap?
I think it will be fun to come up with a solution that will work with n
maps:
(defn multi-fmap [f &maps]
...)
i.e.
(multi-fmap #(+ %1 %1 %2 ) {:a 1 :b 2} {:a 3 :b 4}) => {:a 5 :b 8}
(multi-fmap #(+ %1 %2 %3 ) {:a 1 :b 2} {:a 3 :b 4} {:a 5 :b 6}) => {:a 9 :b
12}
--
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 from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
easiest way to make a map out of a list?
Way I have [:a 1:b 2] and I want to convert it to {:a 1 :b 2}
What's the idiomatic way to do this in Clojure?
Thanks for the help,
Alex
--
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 from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Moderately off-topic: installing emacs on OSX
Sorry for asking here, but I think it's at least a little relevant to Clojure since I for one wouldn't be installing emacs if it wasn't for Clojure and Slime. Getting prompts about what the function arguments are seems like a HUGE benefit when learning this langauge. I imagine other non-emacs people might have a related question, so I'll give asking this question a shot. >sudo ports install slime ... "_dbus_message_set_error_name", referenced from: _Fdbus_method_error_internal in dbusbind.o "_dbus_message_set_destination", referenced from: _Fdbus_method_error_internal in dbusbind.o _Fdbus_method_return_internal in dbusbind.o "_dbus_message_iter_recurse", referenced from: _xd_retrieve_arg in dbusbind.o "_dbus_message_iter_init", referenced from: _xd_read_message in dbusbind.o _Fdbus_call_method in dbusbind.o "_dbus_error_is_set", referenced from: _xd_initialize in dbusbind.o _Fdbus_register_method in dbusbind.o _Fdbus_register_signal in dbusbind.o _Fdbus_call_method in dbusbind.o ld: symbol(s) not found collect2: ld returned 1 exit status make[1]: *** [temacs] Error 1 make: *** [src] Error 2 shell command " cd "/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_editors_emacs/ work/emacs-23.2" && /usr/bin/make -j2 all " returned error 2 Error: Target org.macports.build returned: shell command failed (see log for details) Warning: the following items did not execute (for emacs): org.macports.activate org.macports.build org.macports.destroot org.macports.install Error: Failed to install emacs Log for emacs is at: /opt/local/var/macports/logs/ _opt_local_var_macports_sources_rsync.macports.org_release_ports_editors_emacs/ main.log Error: The following dependencies were not installed: emacs Error: Status 1 encountered during processing. >system_profiler SPSoftwareDataType System Version: Mac OS X 10.6.5 (10H574) Kernel Version: Darwin 10.5.0 ... Thanks in advance. It -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: parameters destructuring & sets?
On Mon, Dec 6, 2010 at 10:45 PM, Michael Gardner wrote: > On Dec 6, 2010, at 9:02 PM, Ken Wesson wrote: > >> I'll try this one more time. You suggested the innards, and with them >> the seq order of the elements, might get rearranged. > > I suggested no such thing; perhaps you are confusing me with Mike Meyer? Actually, the "you" in my post was a generic "you", meaning "whoever's arguing against this". > I referred more generally to the possibility of two different calls to (seq) > on > the same collection returning the items in different orders. The only plausible reason I can think of for this to happen IS if the innards get rearranged "behind the scenes" to, say, better support structure-sharing. This is why I considered yours and Meyer's positions to be equivalent enough to address them both with a single argument containing a generic "you". -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: mapmap?
This is also very easy to implement:
(into {}
(for [[k v] the-map]
[k (f v)]))
e.g.
user=> (into {}
(for [[k v] {:a 3 :b 7}]
[k (inc v)]))
{:a 4, :b 8}
user=>
and to encapsulate as a function:
(defn fmap [f m]
(into {}
(for [[k v] m]
[k (f v)])))
--
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 from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Bug in clojure.contrib.core/-?> (improper quoting?)
On Mon, Dec 6, 2010 at 10:27 PM, Jason Wolfe wrote: > This happens in both Clojure 1.2 and 1.3-latest: > > user=> (require 'clojure.contrib.core) > nil > user=> (clojure.contrib.core/-?> 1 inc) > 2 > user=> (clojure.contrib.core/-?> 1 inc inc) > CompilerException java.lang.Exception: Unable to resolve symbol: -?> > in this context, compiling:(NO_SOURCE_PATH:3) Sure looks like a quoting problem: user=> (require 'clojure.contrib.core) nil user=> (clojure.contrib.core/-?> 1 inc) 2 user=> (clojure.contrib.core/-?> 1 inc inc) # in this context (NO_SOURCE_FILE:214)> user=> (use 'clojure.contrib.core) nil user=> (clojure.contrib.core/-?> 1 inc) 2 user=> (clojure.contrib.core/-?> 1 inc inc) 3 user=> It's obviously calling -?> recursively when there's additional args, and when it does, it's obviously looking for -?> in the current ns instead of for clojure.contrib.core/-?>. Which wouldn't happen with `(-?> ~foo ~bar). Someone used something like (list '-?> foo bar) instead, or something. Someone ought to open an Assembla ticket for this. -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: mapmap?
Thanks Sunil.
On Mon, Dec 6, 2010 at 11:00 PM, Sunil S Nandihalli <
sunil.nandiha...@gmail.com> wrote:
> Hi Alex,
>
> (clojure.contrib.generic.functor/fmap inc {:a 1 :b 2}) => {:a 2 :b 3}
>
> The above is probably what you want.
> HTH
> Sunil.
>
> On Tue, Dec 7, 2010 at 9:26 AM, Alex Baranosky <
> alexander.barano...@gmail.com> wrote:
>
>> Oops. I meant:
>>
>> (mapmap inc {:a 1 :b 2}) => { :a 2 :b 3)
>>
>> Sorry about that.
>>
>> Alex
>>
>> --
>> 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 from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>>
>
> --
> 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 from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
--
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 from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: mapmap?
Hi Alex,
(clojure.contrib.generic.functor/fmap inc {:a 1 :b 2}) => {:a 2 :b 3}
The above is probably what you want.
HTH
Sunil.
On Tue, Dec 7, 2010 at 9:26 AM, Alex Baranosky <
alexander.barano...@gmail.com> wrote:
> Oops. I meant:
>
> (mapmap inc {:a 1 :b 2}) => { :a 2 :b 3)
>
> Sorry about that.
>
> Alex
>
> --
> 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 from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>
--
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 from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: mapmap?
Oops. I meant:
(mapmap inc {:a 1 :b 2}) => { :a 2 :b 3)
Sorry about that.
Alex
--
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 from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
mapmap?
Do the standard libraries contain a function to map a function over a map?
(mapmap inc {:a 1 :b 2}) => (2, 3)
--
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 from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: parameters destructuring & sets?
On Dec 6, 2010, at 9:02 PM, Ken Wesson wrote: > I'll try this one more time. You suggested the innards, and with them > the seq order of the elements, might get rearranged. I suggested no such thing; perhaps you are confusing me with Mike Meyer? I referred more generally to the possibility of two different calls to (seq) on the same collection returning the items in different orders. This might happen if e.g. the underlying collection picks a starting point for the iterators it returns non-deterministically. I'm not saying this is likely to be done in practice, mind you, just that there are conceivable cases where an immutable collection would not want to provide that kind of ordering guarantee. >> It's not just about (nth) giving consistent results. It's also about forcing >> the programmer to make his intentions explicit, per Rich's quote. > > We may just have to agree to disagree about that. It seems to me that > calling nth, or first, or seq, or anything like that makes the > programmer's intentions explicit, as those are all clearly treating > the structure as a sequence. It's calling (foo coll) where foo calls > (nth (seq coll)) or somesuch under the hood that doesn't make the > programmer's intentions (as) explicit; they're calling some function > on, say, a map and it may not be especially obvious that that function > treats the map (and anything else passed to it) as a sequence. > > Anyway, you can't legislate code clarity at the language level. They > tried that with Java and look where it got them. Annotations, > generics, and checked exceptions, oh my! I don't actually have a strong opinion one way or the other on this, though I can see how it would appear otherwise from what I wrote. I was just giving what I understood to be one of the "official" reasons for the decision. -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Bug in clojure.contrib.core/-?> (improper quoting?)
This happens in both Clojure 1.2 and 1.3-latest: user=> (require 'clojure.contrib.core) nil user=> (clojure.contrib.core/-?> 1 inc) 2 user=> (clojure.contrib.core/-?> 1 inc inc) CompilerException java.lang.Exception: Unable to resolve symbol: -?> in this context, compiling:(NO_SOURCE_PATH:3) I assume the other nil-safe operators are affected as well. -Jason -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: parameters destructuring & sets?
On Mon, Dec 6, 2010 at 7:10 PM, Michael Gardner wrote:
> On Dec 6, 2010, at 5:35 PM, Ken Wesson wrote:
>
>> Who was relying on the order? If you merely relied on seeing 5 or 6,
>> or on not seeing 3 or 4 twice, you were screwed.
>
> Ah, I misunderstood what you wrote. Obviously (seq) should hand you each item
> in the collection exactly once, but that's at a weaker guarantee than that
> different calls to (seq) on the same collection should always hand them to
> you in the same order.
>
>> The point was that you can't even rely on seeing all of the elements,
>> once each, in *some* order, unless the seq is a copy instead of a view
>> backed by the other data structure.
>
> I don't see how this follows. It seems like you're making some unstated
> assumptions about how (seq) gets items from the underlying collection.
I'll try this one more time. You suggested the innards, and with them
the seq order of the elements, might get rearranged. If (seq c)
produces a lazy seq that is backed by some kind of iterator traversing
some data structure underlying c and such a rearrangement happens
during said traversal, then there are two branching possibilities.
1. The iterator just keeps traversing even though it's now on
quicksand. (Or worse, it stops with a ConcurrentModificationException
or something.) In that event, the seq contract is broken. At best
you'll get traversals like (1 3 4 2 4 3) sometimes from traversing
things like #{1 2 3 4 5 6}; more likely you'll get things like (1 3 4
2) that simply stop short and omit items; at worst, exception throws.
2. There is some way in which the seq "holds onto" a particular
ordering of the elements, even through rearrangements. The seq may be
non-lazy, created as a PersistentList of the elements when seq was
called; or the structure may include a (stable!) linking system for
traversing the elements (ala java.util.LinkedHashMap), or something.
In case #2, seq meets its contract, but nth can also be made to work
easily enough; in the linking-system case nth "naturally" works
stably, whereas in the non-lazy case the seq version once created can
be cached, both making repeated calls to seq cheaper and making nth
work in a consistent way on that instance.
In case #1, on the other hand, though nth can't be made to work *seq
can't be made to work either* even though it is supported -- it's
supported, and yet *it'll break and needs to be fixed* if the
structure is rewritten to rearrange its innards. And fixing it will
necessarily also fix nth.
>> And if it's a copy, it is
>> expensive to produce. And if it is expensive to produce, it can be
>> cached once produced. And if it can be cached once produced, nth can
>> give consistent results by consulting the cached seq.
>
> It's not just about (nth) giving consistent results. It's also about forcing
> the programmer to make his intentions explicit, per Rich's quote.
We may just have to agree to disagree about that. It seems to me that
calling nth, or first, or seq, or anything like that makes the
programmer's intentions explicit, as those are all clearly treating
the structure as a sequence. It's calling (foo coll) where foo calls
(nth (seq coll)) or somesuch under the hood that doesn't make the
programmer's intentions (as) explicit; they're calling some function
on, say, a map and it may not be especially obvious that that function
treats the map (and anything else passed to it) as a sequence.
Anyway, you can't legislate code clarity at the language level. They
tried that with Java and look where it got them. Annotations,
generics, and checked exceptions, oh my!
--
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 from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: ANN: Dr. Evil - the evil web debugger
It's working! I'm using load-string instead of read-string. Sorry about the noise. 2010/12/7 Vilson Vieira : > Hello Miki, > > I'm writing a simple Clojure editor based on jSyntaxPane. I'm trying > to intern a function (it's defined on live-processing.editor, and I > want to redefine it with (eval (read-string ...))). Any help? > > Thanks. > > 2010/12/6 Miki : >> I've played a bit with the code and now namespaces behave. There's >> even a set-ns! function to set the current namespace to what you want. >> >> On Nov 30, 9:07 am, Constantine Vetoshev wrote: >>> On Nov 29, 2:25 pm, Miki wrote: >>> >>> > Yeah, it uses "load-string" which IMO default to clojure.core >>> > namespace. >>> > I've tried some namespace hacking to allow the user to define the >>> > namespace, but couldn't make it work >>> > (there's a FIXME in the code about that). >>> >>> > Currently I using names with namespace - (cv-test-1.core/some-func >>> > arg1 arg2). Will try to fix that soon. >>> >>> Could (eval (read-string ...)) work? >> >> -- >> 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 from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> > > > > -- > Vilson Vieira > > vil...@void.cc > > ((( http://automata.cc ))) > > ((( http://musa.cc ))) > -- Vilson Vieira vil...@void.cc ((( http://automata.cc ))) ((( http://musa.cc ))) -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Lots of newbie clojure questions
@javajosh You're speaking of the Turing description of computation, you might be interested in Church's lambda calculus description which works just as well and doesn't use mutability to describe computation, --Robert McIntyre On Mon, Dec 6, 2010 at 9:08 PM, javajosh wrote: > On Dec 6, 5:40 pm, Stuart Halloway wrote: >> The world is a series of immutable states, and the future is a function of >> the past. >> See http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey. > > My philosophy questions are the most interesting to people, ha! > > Neat link. It appears that Hickey is something of a Alfred North > Whitehead apostle. Not that there's anything wrong with that. But it's > interesting. > > I question the truth of the general view, even as I enthusiastically > endorse the utility of immutability in computer programs. At the > lowest level, a computer program can be visualized as a two > dimensional bitmap of ones and zeroes. These bits are interpreted by > the CPU starting at the "upper left", say, and they instruct the CPU > what to do. The CPU in turn mutates the bitmap and proceeds, > generally, across and down, unless it's instructed to move > differently. Convention separates "instruction" from "data" but this > is by no means written in stone. In any event, the *physical process* > underlying computation, a bitmap modifying itself, appears imperative > and mutable. One must jump through a lot of hoops (as Hickey can > attest, I'm sure) to simulate immutability of value. > > Or perhaps the CPU designers are laboring under some false assumptions > about reality, and CPU design itself needs to change? > > -- > 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 from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ANN: Dr. Evil - the evil web debugger
On 21 November 2010 22:57, Miki wrote: > Usage is simple - add "EVIL" definition to your application > "defroutes": > > (defroutes app > (GET "/" [] "Nothing here! (try /evil)") > (EVIL "/evil") > (route/not-found "Dude! I can't find it.")) > > Comments/criticism/improvements welcomed. "EVIL" doesn't have to be a macro. You could just make it a function: (defn EVIL [path] (GET path [expr] (if (nil? expr) (html path) (json-str (eval-expr expr - James -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Lots of newbie clojure questions
1. What is the justification for using a map as a function? I find this to be very confusing. In math, a function is a mapping from one set to another, so from that perspective it makes good sense for a clojure-map to be a function from its set of keys to its set of values. The justification here is mathematical convention. Same thing with vectors being functions. 2. In practice, I find myself wincing when needing to decide whether or not to type an open-paren. Is that a common thing? Normally this isn't a problem for me because I always look at the bottom of my emacs window and am able to see the arguments whatever function I'm working with requires. 3. Is there a compendium of recursive idioms, ideally expressed in clojure? Including indentation conventions! (Is there an opportunity for a python inspired pre-processor that interprets indentation as parens?) You might try SICP (http://mitpress.mit.edu/sicp/) because Professor Sussman is awesome. Also try the clojure cookbook (http://en.wikibooks.org/wiki/Clojure_Programming/Examples/Cookbook) 4. Why don't long-running clojure programs monotonically increase in heap usage if all data-structures are immutable? If every reference to an immutable structure disappears than that structure can be garbage collected. Therefore, loops that create intermittent structures aren't that much of a memory hog since java garbage collects the structures every turn of the loop. ;;Memory : 0 (let [a (range 5)]) ;; Memory: "big" while the let is "executing" ;;Memory : 0 -- no reference to a anymore ! 5. In the REPL, isn't it redundant to always have to type the top- level parens? not for (let:) 6. Is there a place to get guidlines on macro idioms? The feature is so powerful that it seems like it would be easy to misuse it and crack a programmers head like a nut with a badly structured macro. Try Stuart Halloway's book, Programming Clojure. I liked it, at least. 1. Isn't the world actually imperative? And mutable? Collaboration *is* a messy proposition in real life. It's hard to fix your car, and even harder to have lots of people fix your car. I find the "it models the real world better" justification for functional programming rather confusing. (Indeed, the CPU and physical memory also have an imperative relationship!) The amount of mutability depends on your level of granularity. Let's say you want to add two numbers --- if you consider all the robotic actions the arm in your hard disk must do to load the memory into the CPU, the flow of electrons in the wires, etc, then there does seem to be mutable state everywhere. But, addition itself is a pure function, so the mutable state is incidental complexity that doesn't really matter in the long run. You can tell it doesn't matter because you can change all the mutable physical stuff and it won't affect the computation. You might use an abacus, a hydraulic computer, your brain, etc, but 2 + 2 is still 4 no matter how you get there. Just as Greens Theorem can transform a surface integral into a line integral and save a lot of work, it's important to circumscribe as much mutable state as possible with abstraction barriers to make our lives simpler. 2. 'Side-effects' are treated almost as a bad word by most functional programming advocates. And yet, aren't ALL programs executed for their side-effects? Does "side effect" perhaps then require a qualification or a tighter definition? Or perhaps side-effects "aren't that bad"? What is a side effect and what isn't depends again on your level of granularity. Too many side effects is a warning of "badness" because it means that you might be working at the wrong abstraction level. Incidental mutability should be removed because it just clutters everything up, but truly necessary mutability is just fine. 3. What is the relationship between the "shape" of a clojure program and the runtime call stack? (I ask because a clojure program looks strikingly similar to the callstack of an ordinary program when you 'pause' a thread.) 4. Is it possible (and/or advisable) to introduce a typing system on top of clojure? E.g. a macro-form along the lines of (fnif type_function function args) Try out defrecord to make your own java objects. Hope you have fun, --Robert McIntyre On Mon, Dec 6, 2010 at 8:40 PM, Stuart Halloway wrote: > 1. Isn't the world actually imperative? And mutable? Collaboration > *is* a messy proposition in real life. It's hard to fix your car, and > even harder to have lots of people fix your car. I find the "it models > the real world better" justification for functional programming rather > confusing. (Indeed, the CPU and physical memory also have an > imperative relationship!) > > I think it is important not to conflate Clojure with functional programming, > since the latter is very broad. > The world is a series of immutable states, and the future is a function of > the past. > See http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey. >
Re: ANN: Dr. Evil - the evil web debugger
Hello Miki, I'm writing a simple Clojure editor based on jSyntaxPane. I'm trying to intern a function (it's defined on live-processing.editor, and I want to redefine it with (eval (read-string ...))). Any help? Thanks. 2010/12/6 Miki : > I've played a bit with the code and now namespaces behave. There's > even a set-ns! function to set the current namespace to what you want. > > On Nov 30, 9:07 am, Constantine Vetoshev wrote: >> On Nov 29, 2:25 pm, Miki wrote: >> >> > Yeah, it uses "load-string" which IMO default to clojure.core >> > namespace. >> > I've tried some namespace hacking to allow the user to define the >> > namespace, but couldn't make it work >> > (there's a FIXME in the code about that). >> >> > Currently I using names with namespace - (cv-test-1.core/some-func >> > arg1 arg2). Will try to fix that soon. >> >> Could (eval (read-string ...)) work? > > -- > 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 from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- Vilson Vieira vil...@void.cc ((( http://automata.cc ))) ((( http://musa.cc ))) -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Lots of newbie clojure questions
On Dec 6, 5:40 pm, Stuart Halloway wrote: > The world is a series of immutable states, and the future is a function of > the past. > See http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey. My philosophy questions are the most interesting to people, ha! Neat link. It appears that Hickey is something of a Alfred North Whitehead apostle. Not that there's anything wrong with that. But it's interesting. I question the truth of the general view, even as I enthusiastically endorse the utility of immutability in computer programs. At the lowest level, a computer program can be visualized as a two dimensional bitmap of ones and zeroes. These bits are interpreted by the CPU starting at the "upper left", say, and they instruct the CPU what to do. The CPU in turn mutates the bitmap and proceeds, generally, across and down, unless it's instructed to move differently. Convention separates "instruction" from "data" but this is by no means written in stone. In any event, the *physical process* underlying computation, a bitmap modifying itself, appears imperative and mutable. One must jump through a lot of hoops (as Hickey can attest, I'm sure) to simulate immutability of value. Or perhaps the CPU designers are laboring under some false assumptions about reality, and CPU design itself needs to change? -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: resultset-seq improvement: mapping column names
+1 On Fri, Dec 3, 2010 at 10:25 PM, ka wrote: > I'm also stuck with the same issues: 1. no option to get string keys > 2. I don't understand, why do libs go through the trouble of > downcasing ? > > Having said that I totally agree with the point Ryan makes: >> A > greater feature of clojure is its extensibility. What I am after is a > generalization of the function in question, for greater > interoperability with Java's SQL libraries. > > -- > 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 from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Lots of newbie clojure questions
On Mon, 6 Dec 2010 16:50:40 -0800 (PST) javajosh wrote: > 1. What is the justification for using a map as a function? I find > this to be very confusing. The same as using a keyword for a function - it lets you write shorter code. > 2. In practice, I find myself wincing when needing to decide whether > or not to type an open-paren. Is that a common thing? I don't believe so. Hopefully it will go away soon. > 3. Is there a compendium of recursive idioms, ideally expressed in > clojure? Including indentation conventions! (Is there an opportunity > for a python inspired pre-processor that interprets indentation as > parens?) Well, I've always liked D.W. Barron's "Recursive Techniques in Programming", and found Eric S. Robert's "Thinking Recursively" to be worth reading, but neither are in LISP. On the other hand, I'm not sure that a LISP programmer would see the value in a compendium of recursive idioms. > 4. Why don't long-running clojure programs monotonically increase in > heap usage if all data-structures are immutable? For the same reason that Java programs don't monotonically increase in heap usage: the Java garbage collector recycles storage that's no longer in use. > 5. In the REPL, isn't it redundant to always have to type the top- > level parens? Not really. If you don't do that, the REPL has to figure out what a naked token on the command line is, and then decide whether or not to add the parens to it. That said, what you're asking about has been used in various LISP systems dating back to the last century, and is known as an evalquote REPL (as opposed to the more common eval REPL used by Clojure). There are a number of CL implementations floating around the web, but I haven't seen one for clojure. > 6. Is there a place to get guidlines on macro idioms? The feature is > so powerful that it seems like it would be easy to misuse it and crack > a programmers head like a nut with a badly structured macro. Halloway's "Programming Clojure" has a good chapter on macros, but it's not as comprehensive as a good CL book's coverage (ask if you want references, but I wouldn't recommend learning CL just to help with clojure). In particular, he doesn't talk about using macros as an optimization technique. It does give a good set of rules for writing macros: 1) Don't write macros. 2) Only write macros if that's the only way to encapsulate a pattern. 3) You can write a macro if it makes life easier for your callers than the equivalent function (my aside: write the function, then have the macro invoke it). > I also have some philosophical questions: Given that I have to live in the poor physical approximation to the real world described by mathematics, I'm going to skip most of these. > 1. Isn't the world actually imperative? And mutable? Collaboration > *is* a messy proposition in real life. It's hard to fix your car, and > even harder to have lots of people fix your car. I find the "it models > the real world better" justification for functional programming rather > confusing. (Indeed, the CPU and physical memory also have an > imperative relationship!) > 2. 'Side-effects' are treated almost as a bad word by most functional > programming advocates. And yet, aren't ALL programs executed for their > side-effects? Does "side effect" perhaps then require a qualification > or a tighter definition? Or perhaps side-effects "aren't that bad"? > 3. What is the relationship between the "shape" of a clojure program > and the runtime call stack? (I ask because a clojure program looks > strikingly similar to the callstack of an ordinary program when you > 'pause' a thread.) > 4. Is it possible (and/or advisable) to introduce a typing system on > top of clojure? E.g. a macro-form along the lines of (fnif > type_function function args) http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ANN: Dr. Evil - the evil web debugger
I've played a bit with the code and now namespaces behave. There's even a set-ns! function to set the current namespace to what you want. On Nov 30, 9:07 am, Constantine Vetoshev wrote: > On Nov 29, 2:25 pm, Miki wrote: > > > Yeah, it uses "load-string" which IMO default to clojure.core > > namespace. > > I've tried some namespace hacking to allow the user to define the > > namespace, but couldn't make it work > > (there's a FIXME in the code about that). > > > Currently I using names with namespace - (cv-test-1.core/some-func > > arg1 arg2). Will try to fix that soon. > > Could (eval (read-string ...)) work? -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Lots of newbie clojure questions
> 1. Isn't the world actually imperative? And mutable? Collaboration > *is* a messy proposition in real life. It's hard to fix your car, and > even harder to have lots of people fix your car. I find the "it models > the real world better" justification for functional programming rather > confusing. (Indeed, the CPU and physical memory also have an > imperative relationship!) I think it is important not to conflate Clojure with functional programming, since the latter is very broad. The world is a series of immutable states, and the future is a function of the past. See http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey. Cheers, Stu -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Lots of newbie clojure questions
> > 1. Isn't the world actually imperative? And mutable? If you're a determinist, then no. Life is a function (albeit a multivariable function), just like sine. > 2. 'Side-effects' are treated almost as a bad word by most functional > programming advocates. And yet, aren't ALL programs executed for their > side-effects? > Not pure functions. But obviously most programs require IO and user interaction, which is why Rich created this kindof two-fold story with "safe" mutability and side-effects. -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Lots of newbie clojure questions
Hello, I'm a long-time Java programmer who's tired of mutability getting in my way. I've been largely enjoying the pervasive use of closures in JavaScript, and though I'd check out Clojure. So far so good. It installed easily and the REPL is easy to use. I've watched the screencasts and have written a few very simple programs. But I have some general questions: 1. What is the justification for using a map as a function? I find this to be very confusing. 2. In practice, I find myself wincing when needing to decide whether or not to type an open-paren. Is that a common thing? 3. Is there a compendium of recursive idioms, ideally expressed in clojure? Including indentation conventions! (Is there an opportunity for a python inspired pre-processor that interprets indentation as parens?) 4. Why don't long-running clojure programs monotonically increase in heap usage if all data-structures are immutable? 5. In the REPL, isn't it redundant to always have to type the top- level parens? 6. Is there a place to get guidlines on macro idioms? The feature is so powerful that it seems like it would be easy to misuse it and crack a programmers head like a nut with a badly structured macro. I also have some philosophical questions: 1. Isn't the world actually imperative? And mutable? Collaboration *is* a messy proposition in real life. It's hard to fix your car, and even harder to have lots of people fix your car. I find the "it models the real world better" justification for functional programming rather confusing. (Indeed, the CPU and physical memory also have an imperative relationship!) 2. 'Side-effects' are treated almost as a bad word by most functional programming advocates. And yet, aren't ALL programs executed for their side-effects? Does "side effect" perhaps then require a qualification or a tighter definition? Or perhaps side-effects "aren't that bad"? 3. What is the relationship between the "shape" of a clojure program and the runtime call stack? (I ask because a clojure program looks strikingly similar to the callstack of an ordinary program when you 'pause' a thread.) 4. Is it possible (and/or advisable) to introduce a typing system on top of clojure? E.g. a macro-form along the lines of (fnif type_function function args) -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: parameters destructuring & sets?
On Dec 6, 2010, at 5:35 PM, Ken Wesson wrote: > Who was relying on the order? If you merely relied on seeing 5 or 6, > or on not seeing 3 or 4 twice, you were screwed. Ah, I misunderstood what you wrote. Obviously (seq) should hand you each item in the collection exactly once, but that's at a weaker guarantee than that different calls to (seq) on the same collection should always hand them to you in the same order. > The point was that you can't even rely on seeing all of the elements, > once each, in *some* order, unless the seq is a copy instead of a view > backed by the other data structure. I don't see how this follows. It seems like you're making some unstated assumptions about how (seq) gets items from the underlying collection. > And if it's a copy, it is > expensive to produce. And if it is expensive to produce, it can be > cached once produced. And if it can be cached once produced, nth can > give consistent results by consulting the cached seq. It's not just about (nth) giving consistent results. It's also about forcing the programmer to make his intentions explicit, per Rich's quote. -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: parameters destructuring & sets?
sorry to jump in this weird conversation, but it seems to me that you are on
parallel discussion without acknowleding it.
To me, the only thing which makes sense is that saying that seq promises no
deterministic ordering on sets and maps is not about calling seq on the same
java instance of a set or map twice.
It's just about acknowledging that, for example :
(not= (seq m) (rest (seq (assoc m :key :value ;; silly example
or that two sets or maps appearing to be = , but not constructed via the
same assoc(iations) in the same order will not provide items in the same
order when seq is called on them:
user=> (def m1 {:k1 :v1 :k2 :v2})
#'user/m1
user=> (def m2 {:k2 :v2 :k1 :v1})
#'user/m2
user=> (into () (seq m1))
([:k2 :v2] [:k1 :v1])
user=> (into () (seq m2))
([:k1 :v1] [:k2 :v2])
user=> (= m1 m2)
true
user=>
2010/12/7 Ken Wesson
> On Mon, Dec 6, 2010 at 5:43 PM, Michael Gardner
> wrote:
> > On Dec 6, 2010, at 4:07 PM, Ken Wesson wrote:
> >
> >> Perhaps. But under those circumstances seq itself has the same problem
> >> you're using to excuse not supporting nth, yet seq is supported. And
> >> so is (nth (seq x)) on these things; if the implementation changed its
> >> innards while you were walking the seq (even with map! Nevermind using
> >> nth) this could trip up. You might have a set #{1 2 3 4 5 6} and seq
> >> would produce (1 3 4 5 2 6) and then someone makes another set from it
> >> with disj and the structure rearranges, so seq would now produce (1 5
> >> 6 2 4 3). Meanwhile, another thread has produced a seq and is
> >> traversing it at the time and gets (1 3 4 2 4 3). Oops.
> >
> >
> > Why is this a problem? Why would you rely on the order in which (seq)
> hands you items from an unordered collection in the first place?
>
> Who was relying on the order? If you merely relied on seeing 5 or 6,
> or on not seeing 3 or 4 twice, you were screwed.
>
> The point was that you can't even rely on seeing all of the elements,
> once each, in *some* order, unless the seq is a copy instead of a view
> backed by the other data structure. And if it's a copy, it is
> expensive to produce. And if it is expensive to produce, it can be
> cached once produced. And if it can be cached once produced, nth can
> give consistent results by consulting the cached seq.
>
> Or, put another way: *either* there is a seq version of the collection
> that has a stable, if effectively random, order (and nth can be made
> to work) *or* simply walking (seq the-coll) will potentially produce
> inconsistent behavior, such as walking (seq a-set) and seeing
> duplicates, or walking almost anything and missing an element that was
> in there.
>
> The latter is clearly undesirable behavior when calling seq on a
> nominally-immutable collection, so I do hope any collections whose
> innards do rearrange have seq produce a seq-copy rather than a
> seq-view. But if the collection either does not rearrange *or*
> produces a seq-copy when seq'd, then nth can be made to work on it in
> a consistent way.
>
> And, of course, none of this affects the obviously ordered *sorted*
> set or the obviously ordered *sorted* map, which was the case
> originally under discussion.
>
> --
> 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 from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>
--
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 from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: parameters destructuring & sets?
On Mon, Dec 6, 2010 at 5:43 PM, Michael Gardner wrote:
> On Dec 6, 2010, at 4:07 PM, Ken Wesson wrote:
>
>> Perhaps. But under those circumstances seq itself has the same problem
>> you're using to excuse not supporting nth, yet seq is supported. And
>> so is (nth (seq x)) on these things; if the implementation changed its
>> innards while you were walking the seq (even with map! Nevermind using
>> nth) this could trip up. You might have a set #{1 2 3 4 5 6} and seq
>> would produce (1 3 4 5 2 6) and then someone makes another set from it
>> with disj and the structure rearranges, so seq would now produce (1 5
>> 6 2 4 3). Meanwhile, another thread has produced a seq and is
>> traversing it at the time and gets (1 3 4 2 4 3). Oops.
>
>
> Why is this a problem? Why would you rely on the order in which (seq) hands
> you items from an unordered collection in the first place?
Who was relying on the order? If you merely relied on seeing 5 or 6,
or on not seeing 3 or 4 twice, you were screwed.
The point was that you can't even rely on seeing all of the elements,
once each, in *some* order, unless the seq is a copy instead of a view
backed by the other data structure. And if it's a copy, it is
expensive to produce. And if it is expensive to produce, it can be
cached once produced. And if it can be cached once produced, nth can
give consistent results by consulting the cached seq.
Or, put another way: *either* there is a seq version of the collection
that has a stable, if effectively random, order (and nth can be made
to work) *or* simply walking (seq the-coll) will potentially produce
inconsistent behavior, such as walking (seq a-set) and seeing
duplicates, or walking almost anything and missing an element that was
in there.
The latter is clearly undesirable behavior when calling seq on a
nominally-immutable collection, so I do hope any collections whose
innards do rearrange have seq produce a seq-copy rather than a
seq-view. But if the collection either does not rearrange *or*
produces a seq-copy when seq'd, then nth can be made to work on it in
a consistent way.
And, of course, none of this affects the obviously ordered *sorted*
set or the obviously ordered *sorted* map, which was the case
originally under discussion.
--
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 from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: parameters destructuring & sets?
On Dec 6, 2010, at 4:07 PM, Ken Wesson wrote:
> Perhaps. But under those circumstances seq itself has the same problem
> you're using to excuse not supporting nth, yet seq is supported. And
> so is (nth (seq x)) on these things; if the implementation changed its
> innards while you were walking the seq (even with map! Nevermind using
> nth) this could trip up. You might have a set #{1 2 3 4 5 6} and seq
> would produce (1 3 4 5 2 6) and then someone makes another set from it
> with disj and the structure rearranges, so seq would now produce (1 5
> 6 2 4 3). Meanwhile, another thread has produced a seq and is
> traversing it at the time and gets (1 3 4 2 4 3). Oops.
Why is this a problem? Why would you rely on the order in which (seq) hands you
items from an unordered collection in the first place? If you care about order,
use an ordered collection. Besides that, it's really uncommon in my experience
to traverse the same collection twice while caring about the ordering.
The point of requiring a manual call to (seq) is to make it explicit that you
are viewing this thing as a seq, with all that implies. To quote Rich from the
previously-referenced thread:
"If in some situation it makes sense to treat a map as sequential (it might
make some sense with array maps or sorted maps), just use (seq m), which will
serve as an indicator of that special point of view."
Given the reasoning above, I'd argue that the fact that (first), (rest), and
(next) work on unordered collections is actually a bug.
--
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 from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: parameters destructuring & sets?
On Mon, 6 Dec 2010 17:07:15 -0500
Ken Wesson wrote:
> On Mon, Dec 6, 2010 at 4:44 PM, Mike Meyer
> wrote:
> > On Mon, 6 Dec 2010 16:30:10 -0500
> > Ken Wesson wrote:
> >
> >> On Mon, Dec 6, 2010 at 1:05 PM, Stuart Sierra
> >> wrote:
> >> > On Dec 6, 8:36 am, Ken Wesson wrote:
> >> >> Furthermore, the comment (not made by Hickey) that map order "may be
> >> >> unstable" is more than a little puzzling in light of the fact that the
> >> >> maps in question are immutable. :)
> >> >
> >> > In general, Rich has been careful not to promise things that might
> >> > limit changes he can make in the future. Sets and maps are unordered.
> >> > `seq` happens to be deterministic on ArrayMap and HashMap, but there
> >> > might some day be some other kind of map or set for which `seq` cannot
> >> > be deterministic. Therefore, Clojure does not promise anything about
> >> > `seq` on maps, other than that it will return the key-value pairs.
> >>
> >> I confess I can't see any obvious reason ever to make seq
> >> nondeterministic on an immutable data structure.
> >
> > I suspect you're applying "immutable" to everything about the data
> > structure, whereas it can also be applied the value without including
> > the implementation. I can see wanting to change the implementation in
> > ways that don't change the value - triggered by something like wanting
> > to share parts of the value with another structure, or a garbage
> > collection, or ... - which could easily change the results of calling
> > seq on the structure.
>
> Perhaps. But under those circumstances seq itself has the same problem
> you're using to excuse not supporting nth, yet seq is supported.
I had some trouble figuring out what you're saying here, so let me
know if I got this wrong: I'm providing reasons for seq to not have a
guarantee of determinism when called on some structures, and that
non-determinism is the justification for nth not being supported, so
why is seq supported?
A non-deterministic nth has no value - you might as well just use
first (and in fact, you can). A non-deterministic seq, on the other
hand, *does* have a value: it provides representation of the value for
which nth (and friends) have a deterministic value.
Having nth call seq on structures for which seq is non-deterministic
would slow down nth, and possibly hide buggy code. Forcing the call to
seq be explicit means there's a chance they'll notice the
non-deterministic result, and fix the bug.
> And so is (nth (seq x)) on these things; if the implementation
> changed its innards while you were walking the seq (even with map!
> Nevermind using nth) this could trip up. You might have a set #{1 2
> 3 4 5 6} and seq would produce (1 3 4 5 2 6) and then someone makes
> another set from it with disj and the structure rearranges, so seq
> would now produce (1 5 6 2 4 3). Meanwhile, another thread has
> produced a seq and is traversing it at the time and gets (1 3 4 2 4
> 3). Oops.
There are a number of ways to avoid this bug. You found at least one
of them here:
> If that kind of internal rearrangement is to be done, seq will have to
> copy the structure's contents (by realizing the seq promptly; so there
> goes laziness) in order to avoid that kind of error. And once you have
> that, you will want to create AND CACHE the (immutable!) structure's
> seq-representation when it's first needed. And you can do so when nth
> is called, as well as seq. And then due to the caching both nth and
> seq will obey (if (identical? s1 s2) (identical? (f s1) (f s2))) when
> substituted for f.
>
> Even then, I'd expect internal rearrangement to be a thread-safety
> nightmare; in all likelihood a) rearranging operations, and b)
> operations like realizing the seq that will be b0rked by concurrent
> rearrangements, will require locking the structure. Locking is
> supposed to be kept to a minimum as one of Clojure's design goals,
> IIRC.
>
> This gets worse when you note that seq realization can cause the
> execution of user-supplied code (e.g. the body of a lazy-seq macro)
> during realization. If user-supplied code can end up executing with
> user-invisible monitors locked, and can in turn cause more monitors to
> be locked (say, by disjing a set thus causing one of your hypothetical
> internal rearrangements), then it can cause deadlocks that would be
> fiendishly difficult to track down and fix. And deadlock avoidance is
> *emphatically* one of Clojure's design goals.
All true. As far as I'm concerned, it's also all irrelevant. Just
because doing a thing is hard in all known examples doesn't mean you
want to give up the right to do it should you decide you need to.
http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to c
Swank-clojure: "unreadable message"
Thanks for earlier help on (not) using MacPorts leiningen.
Having installed leiningen as per site instructions, I also followed
site instructions for installing swank-clojure using leiningen. These
instructions reference a SNAPSHOT build of swank-clojure.
After install, `lein ~/.lein/bin/swank-clojure' starts up apparently OK.
Now, in emacs, after doing `M-x slime-connect' and accepting the
default prompt values, I get the fancy slime animation, but swank-
clojure 1.3.0-SNAPSHOT immediately throws:
unreadable message: (:emacs-rex (swank:autodoc (quote ("+" swank::
%cursor-marker%)) :print-right-margin 106) "user" :repl-thread 4)
This does not appear to be fatal; swank-clojure does not exit.
On the emacs side, slime breaks into the debugger:
Debugger entered--Lisp error: (error "No inferior lisp process")
As you'd expect, after that, input at the slime prompt does not eval.
Configuration in use:
% lein install swank-clojure 1.3.0-SNAPSHOT
[INFO] snapshot swank-clojure:swank-clojure:1.3.0-SNAPSHOT: checking
for updates from central
[INFO] snapshot swank-clojure:swank-clojure:1.3.0-SNAPSHOT: checking
for updates from clojure
[INFO] snapshot swank-clojure:swank-clojure:1.3.0-SNAPSHOT: checking
for updates from clojure-snapshots
[INFO] snapshot swank-clojure:swank-clojure:1.3.0-SNAPSHOT: checking
for updates from clojars
Installing shell wrapper to /Users/phil/.lein/bin/swank-clojure
Downloading: org/clojure/clojure/1.2.0/clojure-1.2.0.pom from central
Downloading: org/clojure/clojure/1.2.0/clojure-1.2.0.jar from central
CVS SLIME 04-Dec-2010
MacPorts emacs 23.2.1, X11 emacsclient frame
Mac OS X 10.5.8
Should I downgrade to swank-clojure 1.2.x?
--
Phil Hudson PGP/GnuPG ID: 0x887DCA63
--
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 from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: parameters destructuring & sets?
On Mon, Dec 6, 2010 at 4:44 PM, Mike Meyer
wrote:
> On Mon, 6 Dec 2010 16:30:10 -0500
> Ken Wesson wrote:
>
>> On Mon, Dec 6, 2010 at 1:05 PM, Stuart Sierra
>> wrote:
>> > On Dec 6, 8:36 am, Ken Wesson wrote:
>> >> Furthermore, the comment (not made by Hickey) that map order "may be
>> >> unstable" is more than a little puzzling in light of the fact that the
>> >> maps in question are immutable. :)
>> >
>> > In general, Rich has been careful not to promise things that might
>> > limit changes he can make in the future. Sets and maps are unordered.
>> > `seq` happens to be deterministic on ArrayMap and HashMap, but there
>> > might some day be some other kind of map or set for which `seq` cannot
>> > be deterministic. Therefore, Clojure does not promise anything about
>> > `seq` on maps, other than that it will return the key-value pairs.
>>
>> I confess I can't see any obvious reason ever to make seq
>> nondeterministic on an immutable data structure.
>
> I suspect you're applying "immutable" to everything about the data
> structure, whereas it can also be applied the value without including
> the implementation. I can see wanting to change the implementation in
> ways that don't change the value - triggered by something like wanting
> to share parts of the value with another structure, or a garbage
> collection, or ... - which could easily change the results of calling
> seq on the structure.
Perhaps. But under those circumstances seq itself has the same problem
you're using to excuse not supporting nth, yet seq is supported. And
so is (nth (seq x)) on these things; if the implementation changed its
innards while you were walking the seq (even with map! Nevermind using
nth) this could trip up. You might have a set #{1 2 3 4 5 6} and seq
would produce (1 3 4 5 2 6) and then someone makes another set from it
with disj and the structure rearranges, so seq would now produce (1 5
6 2 4 3). Meanwhile, another thread has produced a seq and is
traversing it at the time and gets (1 3 4 2 4 3). Oops.
If that kind of internal rearrangement is to be done, seq will have to
copy the structure's contents (by realizing the seq promptly; so there
goes laziness) in order to avoid that kind of error. And once you have
that, you will want to create AND CACHE the (immutable!) structure's
seq-representation when it's first needed. And you can do so when nth
is called, as well as seq. And then due to the caching both nth and
seq will obey (if (identical? s1 s2) (identical? (f s1) (f s2))) when
substituted for f.
Even then, I'd expect internal rearrangement to be a thread-safety
nightmare; in all likelihood a) rearranging operations, and b)
operations like realizing the seq that will be b0rked by concurrent
rearrangements, will require locking the structure. Locking is
supposed to be kept to a minimum as one of Clojure's design goals,
IIRC.
This gets worse when you note that seq realization can cause the
execution of user-supplied code (e.g. the body of a lazy-seq macro)
during realization. If user-supplied code can end up executing with
user-invisible monitors locked, and can in turn cause more monitors to
be locked (say, by disjing a set thus causing one of your hypothetical
internal rearrangements), then it can cause deadlocks that would be
fiendishly difficult to track down and fix. And deadlock avoidance is
*emphatically* one of Clojure's design goals.
--
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 from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Apache ws-xmlrpc
Great! I'll give it a try for sure :) On Dec 6, 4:55 pm, Rayne wrote: > Clojure's Java interop is extremely impressive and straightforward -- > to someone who is somewhat familiar with Java. I don't know Java, but > I've learned to work with it pretty well just by using Clojure. When I > started out, it was extremely difficult, because I couldn't read > javadocs and didn't understand how Java worked. > > This isn't to say that you need to know Java to use Java from Clojure, > but it seems less straightforward than it actually is when you don't > really understand Java. > > In any case, I'm actually working on a pure-Clojure XML-RPC > library:http://github.com/Raynes/clj-xmlrpcnot sure if it would be helpful to > you, but it's worth taking a look at I suppose. It's very early in > development though -- just started the project yesterday. It appears > to work, but until I've done some testing, I can't promise it wont eat > your laundry. -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: parameters destructuring & sets?
On Mon, 6 Dec 2010 16:30:10 -0500 Ken Wesson wrote: > On Mon, Dec 6, 2010 at 1:05 PM, Stuart Sierra > wrote: > > On Dec 6, 8:36 am, Ken Wesson wrote: > >> Furthermore, the comment (not made by Hickey) that map order "may be > >> unstable" is more than a little puzzling in light of the fact that the > >> maps in question are immutable. :) > > > > In general, Rich has been careful not to promise things that might > > limit changes he can make in the future. Sets and maps are unordered. > > `seq` happens to be deterministic on ArrayMap and HashMap, but there > > might some day be some other kind of map or set for which `seq` cannot > > be deterministic. Therefore, Clojure does not promise anything about > > `seq` on maps, other than that it will return the key-value pairs. > > I confess I can't see any obvious reason ever to make seq > nondeterministic on an immutable data structure. I suspect you're applying "immutable" to everything about the data structure, whereas it can also be applied the value without including the implementation. I can see wanting to change the implementation in ways that don't change the value - triggered by something like wanting to share parts of the value with another structure, or a garbage collection, or ... - which could easily change the results of calling seq on the structure. Not that I know that anything in clojure does that, just that I can see conditions where you might want to. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Why I'm getting StackoverflowError?
On Mon, Dec 6, 2010 at 11:36 AM, Meikel Brandmeyer wrote: > Hi, > > Am 06.12.2010 um 11:40 schrieb Ken Wesson: > >> Won't that make the internal recursive call fail though? > > No. Because the metadata is just documentation. > >> And even if not -- ugly IMO. :) > > Tastes vary. I prefer this over a second toplevel function named foo-aux or > the like. I also prefer it over a nested let. That said, I hardly ever run > into this pattern. Maybe because I use reduce in 95% of such cases. A reduce that discards one of its arguments (e.g. (reduce (fn [n _] (inc n)) coll)) also strikes me as slightly icky. :) -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: math utilities question
On Mon, Dec 6, 2010 at 11:45 AM, Konrad Hinsen wrote: > On 06.12.2010, at 16:02, Johann Hibschman wrote: >> Maybe I'm not reading the right news, but I've not seen all that much on >> using Java for scientific work for a while now. The NIST JavaNumerics >> guys seem to have given up, but if I remember correctly their >> conclusions were that Java really needed complex numbers as a >> value/stack-allocated type. > > I'd say what Java needs is not complex numbers as a value type, but a way to > define additional value types. Complex numbers are just one applications. > Another one is points (2D or 3D) for geometry and graphics. > > Unfortunately the problem is not just Java, but the JVM, meaning that Clojure > inherits the problem. Clojure does not inherit the problem, if you use macros cleverly. You can stack allocate individual primitives, separately, e.g. (let [x (int 3) y (double 4.2)] ...) And with macros you can wrap that in an abstraction that looks like a single object, such as a point or a complex number. Passing it to a function would require a bit of magic, though -- say, bundling the components into a vector and passing that as the fn arg, and unbundling again on the inside. If the call gets inlined the JIT should hopefully be able to optimize away this boxing. -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: parameters destructuring & sets?
On Mon, Dec 6, 2010 at 1:05 PM, Stuart Sierra wrote: > On Dec 6, 8:36 am, Ken Wesson wrote: >> Furthermore, the comment (not made by Hickey) that map order "may be >> unstable" is more than a little puzzling in light of the fact that the >> maps in question are immutable. :) > > In general, Rich has been careful not to promise things that might > limit changes he can make in the future. Sets and maps are unordered. > `seq` happens to be deterministic on ArrayMap and HashMap, but there > might some day be some other kind of map or set for which `seq` cannot > be deterministic. Therefore, Clojure does not promise anything about > `seq` on maps, other than that it will return the key-value pairs. I confess I can't see any obvious reason ever to make seq nondeterministic on an immutable data structure. -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ANN: Durable Clojure - Functions and Closures
On Mon, Dec 6, 2010 at 1:09 PM, Alyssa Kwan wrote: > Yes, but why isn't persistence of closures generating more > interest. ;) > > Persistence is "solved", if you're OK with not being truly ACID... > > Seriously though, everyone has their own backends. I don't think > anyone wants to be tied to BDB JE. > > Would there be interest in lazy-loading and -unloading data > structures? That code I wrote does sort of do lazy loading and unloading data structures. That is, it can be used to make structures that are loaded in pieces, on demand, as an algorithm reaches a particular piece, and that can be referenced without loading them just from hanging onto the thing's address somewhere. -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ANN: Durable Clojure - Functions and Closures
Yes, but why isn't persistence of closures generating more interest. ;) Persistence is "solved", if you're OK with not being truly ACID... Seriously though, everyone has their own backends. I don't think anyone wants to be tied to BDB JE. Would there be interest in lazy-loading and -unloading data structures? On Nov 27, 7:35 pm, Ken Wesson wrote: > On Sat, Nov 27, 2010 at 1:10 PM, Mark wrote: > > Hi - > > > I'm surprised your work doesn't generate more interest from folks. I > > wish I had more time, I would definitely jump in and help. > > Persistence doesn't seem to generate much interest in general. I > posted my own stab at a way of persisting the ref world > near-transparently a few weeks ago and it sank without a ripple. -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: There is no such thing as IAtom
+1 There is no STM integration with atoms. That's not a concern. Just write your own Clojure core with your change. I did for durable identities. git://github.com/kwanalyssa/clojure.git Seriously though, just use protocols. Thanks, Alyssa On Dec 6, 5:24 am, Benjamin Teuber wrote: > I guess it was Rich's intention to have swap! be used for real atoms > only so your code remains understandable - that's why it's called > swap! for atoms, alter for refs and alter-var-root for vars. > > So why not define your own protocol for updating documents? If you > really want (usually bad idea, I guess) you could still extend atoms > or even refs to support this protocol, too. > > Regards, > Benjamin > > On 5 Dez., 23:29, Pepijn de Vos wrote: > > > > > tl;dr: Please add an interface to clojure.lang.Atom. kthxbye > > > I had the brilliant idea of using CouchDB for something equally brilliant, > > and if possible implement a Clojure view server. Turns out Clutch fits the > > bill perfectly, except that I would like to use Aleph, and Couch is using > > something called MVCC. > > > I haven't looked into the libs to deep, but I know the REST API, and what > > it does for updating is that you need to supply the current revision and if > > it doesn't match (i.e. there has been another update), the update fails. So > > then you need to get the new _rev and try again. Much the same way > > compare-and-set! works. > > > I thought it would be perfect to implement IAtom and IDeref to get the > > latest value and to swap! documents in a spin loop with a side-effect-free > > function, like atoms do. > > > But it turns out there is no interface for Atom and it is marked final. The > > same is true for Ref and Agent, but raek suggested this might be because > > they are more complex and integrated with the STM. > > > Is there a good reason why I'm not allowed to implement my own atom? If > > not, can it be added? Thanks. > > > Groeten, > > Pepijn de Vos > > -- > > Sent from my iPod Shufflehttp://pepijndevos.nl- Hide quoted text - > > - Show quoted text - -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: parameters destructuring & sets?
On Dec 6, 8:36 am, Ken Wesson wrote: > Furthermore, the comment (not made by Hickey) that map order "may be > unstable" is more than a little puzzling in light of the fact that the > maps in question are immutable. :) In general, Rich has been careful not to promise things that might limit changes he can make in the future. Sets and maps are unordered. `seq` happens to be deterministic on ArrayMap and HashMap, but there might some day be some other kind of map or set for which `seq` cannot be deterministic. Therefore, Clojure does not promise anything about `seq` on maps, other than that it will return the key-value pairs. -S -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: There is no such thing as IAtom
On Dec 6, 11:52 am, "pepijn (aka fliebel)" wrote: > You can not extend them, as they are marked final. You can extend Clojure protocols to final classes. > Another point to consider is clojure-in-clojure. If that is ever going > to happen, one needs to be able to implement Atom as well. clojure-in-clojure will probably be defined in terms of protocols. Whether or not "IAtom" is one of those I can't say. -S -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: There is no such thing as IAtom
You can not extend them, as they are marked final. Another point to consider is clojure-in-clojure. If that is ever going to happen, one needs to be able to implement Atom as well. It is also generally better to code to an interface rather than to an implementation. Alter and send also work differently from swap!, so I think it makes sense to have separate functions for them. But CouchDB also exhibits shared, synchronous, independent state, so I don't see the point in prohibiting the use of the same interface. On Dec 6, 11:24 am, Benjamin Teuber wrote: > I guess it was Rich's intention to have swap! be used for real atoms > only so your code remains understandable - that's why it's called > swap! for atoms, alter for refs and alter-var-root for vars. > > So why not define your own protocol for updating documents? If you > really want (usually bad idea, I guess) you could still extend atoms > or even refs to support this protocol, too. > > Regards, > Benjamin > > On 5 Dez., 23:29, Pepijn de Vos wrote: > > > > > > > > > tl;dr: Please add an interface to clojure.lang.Atom. kthxbye > > > I had the brilliant idea of using CouchDB for something equally brilliant, > > and if possible implement a Clojure view server. Turns out Clutch fits the > > bill perfectly, except that I would like to use Aleph, and Couch is using > > something called MVCC. > > > I haven't looked into the libs to deep, but I know the REST API, and what > > it does for updating is that you need to supply the current revision and if > > it doesn't match (i.e. there has been another update), the update fails. So > > then you need to get the new _rev and try again. Much the same way > > compare-and-set! works. > > > I thought it would be perfect to implement IAtom and IDeref to get the > > latest value and to swap! documents in a spin loop with a side-effect-free > > function, like atoms do. > > > But it turns out there is no interface for Atom and it is marked final. The > > same is true for Ref and Agent, but raek suggested this might be because > > they are more complex and integrated with the STM. > > > Is there a good reason why I'm not allowed to implement my own atom? If > > not, can it be added? Thanks. > > > Groeten, > > Pepijn de Vos > > -- > > Sent from my iPod Shufflehttp://pepijndevos.nl -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: math utilities question
On 06.12.2010, at 16:02, Johann Hibschman wrote: > (Konrad Hinsen had started some work on multiarrays in Clojure, but I've > not been following his progress.) There hasn't been much, unfortunately. I haven't found much time for serious Clojure hacking for a few months. But the project is not abandoned, just slowed down. > I've built the Java interface to HDF5, and I've been using that for > data storage. I would prefer to use a pure-Java solution, but I can't > find anything that's nearly as good. netCDF has a Java library that also reads HDF5, but it's read-only. > Maybe I'm not reading the right news, but I've not seen all that much on > using Java for scientific work for a while now. The NIST JavaNumerics > guys seem to have given up, but if I remember correctly their > conclusions were that Java really needed complex numbers as a > value/stack-allocated type. I'd say what Java needs is not complex numbers as a value type, but a way to define additional value types. Complex numbers are just one applications. Another one is points (2D or 3D) for geometry and graphics. Unfortunately the problem is not just Java, but the JVM, meaning that Clojure inherits the problem. Konrad. -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Why I'm getting StackoverflowError?
Hi, Am 06.12.2010 um 11:40 schrieb Ken Wesson: > Won't that make the internal recursive call fail though? No. Because the metadata is just documentation. > And even if not -- ugly IMO. :) Tastes vary. I prefer this over a second toplevel function named foo-aux or the like. I also prefer it over a nested let. That said, I hardly ever run into this pattern. Maybe because I use reduce in 95% of such cases. Sincerely Meikel -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Get sequence of values in arbitrarily nested collection
Nice! I knew there had to be a nicer way of traversing nested collections :) Thank you for this. On Dec 6, 8:30 am, Justin Kramer wrote: > tree-seq makes this pretty simple: > > (defn nested-vals [key coll] > (for [x (tree-seq coll? seq coll) :when (contains? x key)] > (get x key))) > > This works with any type of key and all associative Clojure > structures. It could be made compatible with Java structures by > swapping out the 'coll?' predicate for something more general. > > Justin > > On Dec 5, 9:12 pm, Alex Baranosky > wrote: > > > > > > > > > Hi guys, > > > I would like a function to be able to take an arbitrarily nested collection > > and return a sequence of all values of a given key, such as :name, that > > appears anywhere in the nested collection. > > > Does anything like this already exist? > > > Thanks for the help, > > Alex -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Get sequence of values in arbitrarily nested collection
+1 Lazy is better. Personally, I would have used filter and map instead of for, but this is probably clearer. Thanks, Alyssa On Dec 6, 10:30 am, Justin Kramer wrote: > tree-seq makes this pretty simple: > > (defn nested-vals [key coll] > (for [x (tree-seq coll? seq coll) :when (contains? x key)] > (get x key))) > > This works with any type of key and all associative Clojure > structures. It could be made compatible with Java structures by > swapping out the 'coll?' predicate for something more general. > > Justin > > On Dec 5, 9:12 pm, Alex Baranosky > wrote: > > > > > Hi guys, > > > I would like a function to be able to take an arbitrarily nested collection > > and return a sequence of all values of a given key, such as :name, that > > appears anywhere in the nested collection. > > > Does anything like this already exist? > > > Thanks for the help, > > Alex- Hide quoted text - > > - Show quoted text - -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Apache ws-xmlrpc
Clojure's Java interop is extremely impressive and straightforward -- to someone who is somewhat familiar with Java. I don't know Java, but I've learned to work with it pretty well just by using Clojure. When I started out, it was extremely difficult, because I couldn't read javadocs and didn't understand how Java worked. This isn't to say that you need to know Java to use Java from Clojure, but it seems less straightforward than it actually is when you don't really understand Java. In any case, I'm actually working on a pure-Clojure XML-RPC library: http://github.com/Raynes/clj-xmlrpc not sure if it would be helpful to you, but it's worth taking a look at I suppose. It's very early in development though -- just started the project yesterday. It appears to work, but until I've done some testing, I can't promise it wont eat your laundry. -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Get sequence of values in arbitrarily nested collection
tree-seq makes this pretty simple: (defn nested-vals [key coll] (for [x (tree-seq coll? seq coll) :when (contains? x key)] (get x key))) This works with any type of key and all associative Clojure structures. It could be made compatible with Java structures by swapping out the 'coll?' predicate for something more general. Justin On Dec 5, 9:12 pm, Alex Baranosky wrote: > Hi guys, > > I would like a function to be able to take an arbitrarily nested collection > and return a sequence of all values of a given key, such as :name, that > appears anywhere in the nested collection. > > Does anything like this already exist? > > Thanks for the help, > Alex -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: math utilities question
Robert McIntyre writes: > I'm wondering if people have had experience with java libraries of > that sort and might have some recommendations. > > Anyone use clojure for scientific data analysis? What do you find > helpful to use? I'm still just evaluating clojure for scientific data analysis, but I can share what I've found so far. First of all, Incanter. I like the idea of Incanter, but I don't like its decision to have matrices be the fundamental data object. Matrices are great, but they not the be-all and end-all. Multidimensional arrays are better, like in numpy or APL or J. It's a pet peeve about R that it doesn't distinguish scalars from vectors of length 1. (Konrad Hinsen had started some work on multiarrays in Clojure, but I've not been following his progress.) Also, Incanter seems very tuned to a row-wise view of data sets, while I've spent enough time with R and kdb+/q to prefer a column-wise view of data. (This is just based on reading the Incanter docs quickly; I may be misrepresenting the package.) As far as matrix libraries go, I've settled on EJML, since it seems reasonably fast, and I can understand what it's doing. Bradford Cross blogged a comparison of different libraries at: http://measuringmeasures.com/blog/2010/3/28/matrix-benchmarks-fast-linear-algebra-on-the-jvm.html I can't seem to find a good Java multiarray library, but I have some hope that I could beat EJML into shape, since its representation is just a basic array of doubles. I've built the Java interface to HDF5, and I've been using that for data storage. I would prefer to use a pure-Java solution, but I can't find anything that's nearly as good. Maybe I'm not reading the right news, but I've not seen all that much on using Java for scientific work for a while now. The NIST JavaNumerics guys seem to have given up, but if I remember correctly their conclusions were that Java really needed complex numbers as a value/stack-allocated type. This is a bit of a disjointed ramble, but I'd love to hear what you settle on. Regards, Johann -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: parameters destructuring & sets?
On Mon, Dec 6, 2010 at 8:24 AM, Stuart Halloway wrote: > Archive search "nth seq hickey": > > http://groups.google.com/group/clojure/browse_thread/thread/ffa3f56c3bb32bc3/773b23a34e88acab?lnk=gst&q=nth+seq+hickey#773b23a34e88acab Interesting. But that was years ago, Hickey no longer seems to be active on the mailing list, and it certainly seems to me that at the very least sorted sets and sorted maps are sequential. Furthermore, the comment (not made by Hickey) that map order "may be unstable" is more than a little puzzling in light of the fact that the maps in question are immutable. :) -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: parameters destructuring & sets?
Archive search "nth seq hickey": http://groups.google.com/group/clojure/browse_thread/thread/ffa3f56c3bb32bc3/773b23a34e88acab?lnk=gst&q=nth+seq+hickey#773b23a34e88acab Stu > On Sun, Dec 5, 2010 at 4:14 PM, jweiss wrote: >> That's totally different than nth for a set being undefined. It's undefined >> on purpose. >> >> Now, if you are using a sorted-set, then you have a point there, I >> would expect that nth means something then. But yeah, clojure doesn't >> let you call nth on it directly, you have to make a seq out of it >> first. > > I vote to make nth work on sets and maps, in general, sorted and > otherwise, with the well-defined semantics of (identical? (nth > set-or-map) (nth (seq (set-or-map. More generally, let nth work on > anything that seq works on, by calling seq on its argument when > necessary. > > -- > 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 from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: outlining for clojure files in emacs+slime?
"Alan D. Salewski" writes: > On Sun, Dec 05, 2010 at 07:35:35AM -0700, Eric Schulte spake thus: >> Also, I often see ^L characters in lisp files inside of Emacs, I believe >> these characters are used for in-file navigation, but I don't know how, >> so that might be another avenue of investigation (I'd be interested to >> hear what you turn up in this direction). > > Hi Eric, > > The ^L characters allow navigation by pages. By default, `forward-page' > is bound to: > > C-x ] > > and `backward-page' is bound to: > > C-x [ > > You can try it out in the *scratch* buffer by inserting ^L chars with: > > C-q C-l > Thanks for the pointer, I'm going to start using this in my larger code files. -- Eric > > HTH, > -Al > > > -- > a l a n d. s a l e w s k i salew...@att.net > > My pants are my friends > they taunt their rivals - my shoes > Oh my clothes! Stop it! > > Generated from Haiku-O-Matic: www.smalltime.com/haiku.html -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Why I'm getting StackoverflowError?
On Dec 6, 11:40 am, Ken Wesson wrote: > Won't that make the internal recursive call fail though? > > And even if not -- ugly IMO. :) Agree. Why make something slower and more ugly? -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Why I'm getting StackoverflowError?
On Mon, Dec 6, 2010 at 5:19 AM, Meikel Brandmeyer wrote:
> Hi,
>
> Am 06.12.2010 um 10:14 schrieb Ken Wesson:
>
>>> Then we could use arity functions. (Alex Osborne)
>>>
>>> (defn list-length
>>> ([coll] (list-length coll 0))
>>> ([coll n] (if-let [s (seq coll)]
>>> (recur (rest s) (inc n))
>>> n)))
>>>
>>> This is nice style in my opinion
>>
>> Not in mine -- it exposes a public API of
>> list-length-plus-some-integer that a) doesn't make much sense and b)
>> is unlikely to be supported, since the implementation could be changed
>> to one that doesn't expose this.
>
> One can easily hide the second arity from the contract.
>
> (defn list-length
> {:arglists '([coll])}
> ...)
Won't that make the internal recursive call fail though?
And even if not -- ugly IMO. :)
--
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 from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Fixing minmax algorithm
On Mon, Dec 6, 2010 at 5:18 AM, zmyrgel wrote: > Then you didn't look close enough of my first message :) > Granted, I omitted large parts of the code in it but it showed my > evaluate function with pruning attached. Er, I saw min calling max and max calling min, without either doing anything to prune branches or otherwise skip stuff. > Here's my evaluate function, with debugging code cleaned: [snip] > Though I'm still having some issues with my minmax. > When I'm trying to evaluate single state it returns a nil in about 1 > msec. > Seems that there are some issues with laziness as the algorithm seemed > to work somehow when I printed the debug information. You may need to wrap a doall around something, though it shouldn't make a difference unless you're using binding or mutable state or I/O somewhere. -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: There is no such thing as IAtom
I guess it was Rich's intention to have swap! be used for real atoms only so your code remains understandable - that's why it's called swap! for atoms, alter for refs and alter-var-root for vars. So why not define your own protocol for updating documents? If you really want (usually bad idea, I guess) you could still extend atoms or even refs to support this protocol, too. Regards, Benjamin On 5 Dez., 23:29, Pepijn de Vos wrote: > tl;dr: Please add an interface to clojure.lang.Atom. kthxbye > > I had the brilliant idea of using CouchDB for something equally brilliant, > and if possible implement a Clojure view server. Turns out Clutch fits the > bill perfectly, except that I would like to use Aleph, and Couch is using > something called MVCC. > > I haven't looked into the libs to deep, but I know the REST API, and what it > does for updating is that you need to supply the current revision and if it > doesn't match (i.e. there has been another update), the update fails. So then > you need to get the new _rev and try again. Much the same way > compare-and-set! works. > > I thought it would be perfect to implement IAtom and IDeref to get the latest > value and to swap! documents in a spin loop with a side-effect-free function, > like atoms do. > > But it turns out there is no interface for Atom and it is marked final. The > same is true for Ref and Agent, but raek suggested this might be because they > are more complex and integrated with the STM. > > Is there a good reason why I'm not allowed to implement my own atom? If not, > can it be added? Thanks. > > Groeten, > Pepijn de Vos > -- > Sent from my iPod Shufflehttp://pepijndevos.nl -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Why I'm getting StackoverflowError?
Hi,
Am 06.12.2010 um 10:14 schrieb Ken Wesson:
>> Then we could use arity functions. (Alex Osborne)
>>
>>(defn list-length
>> ([coll] (list-length coll 0))
>> ([coll n] (if-let [s (seq coll)]
>> (recur (rest s) (inc n))
>> n)))
>>
>> This is nice style in my opinion
>
> Not in mine -- it exposes a public API of
> list-length-plus-some-integer that a) doesn't make much sense and b)
> is unlikely to be supported, since the implementation could be changed
> to one that doesn't expose this.
One can easily hide the second arity from the contract.
(defn list-length
{:arglists '([coll])}
...)
Sincerely
Meikel
--
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 from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Fixing minmax algorithm
Then you didn't look close enough of my first message :) Granted, I omitted large parts of the code in it but it showed my evaluate function with pruning attached. Here's my evaluate function, with debugging code cleaned: (defn- evaluate-with-minmax "Evaluates given game state with minmax-algorithm." [depth eval-fn state] (->> state gametree (prune depth) (maptree eval-fn) maximise)) In gametree I use my legal-states function to generate all resulting states achievable from given state. This takes should check draws etc. At least thats the idea. Pruning should limit the gametree to given depth and maptree should apply eval-fn to each node in the tree. Though I'm still having some issues with my minmax. When I'm trying to evaluate single state it returns a nil in about 1 msec. Seems that there are some issues with laziness as the algorithm seemed to work somehow when I printed the debug information. If I have understood the minmax presented in hughes's work the functions before maximise calls need to be lazy. This should guarantee that the algorithm will only evaluate the stuff it needs. This is not that important in minmax as it will visit every node anyway but is vital for the alphabeta version to work correctly. Is it correct way to just wrap the function' s mentioned above in lazy- seq calls and it should work or does it need something else? My current code can be found in https://github.com/zmyrgel/tursas/tree/master/src/tursas Any ideas on improving the search.clj or overall the engine would be appreciated. It's kinda hard work as I haven't done any chess engine before nor have I done any functional programming either. I know I could have used tree-seq to make the search.clj code more Clojure like but the Hughes's work was nicely explained and I didn't know how to implement it in more Clojure-like way. Timo On Dec 6, 12:40 am, Ken Wesson wrote: > On Sun, Dec 5, 2010 at 7:46 AM, Timo Myyrä wrote: > > Thank you, this solved the issues I was having as far as I can tell. > > > Now I can focus on getting rest of my chess engine working properly. > > Chess? Then you've got a problem. I didn't see any pruning or even > depth bounding in your algorithm. And not only is searching the entire > move tree in chess generally impractical, but making matters worse, > there are some endgames that admit infinite sequences of moves (e.g. > both players doing nothing but fiddling with their kings, forever). > Sure, nobody would actually play those endgames -- they'd go on the > attack, or one of the various rules that result in declaring the game > drawn would kick in, but your algorithm will consider them anyway, and > consider them, and consider them, and consid# > > Looking on the bright side, though, it should now work for > Tic-Tac-Toe. Or any other game that is guaranteed to run out of valid > moves in finite time. > > For chess, though, you're going to have to implement bounding the > depth of search and, if you want it to be really good, heuristic > pruning. -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Why I'm getting StackoverflowError?
I didn't expect my question would initiate such a wonderful discussion, I'm speechless. Thank you all guys, you are amazing. Alex, your posts killed in a very good way :) It was really helpful to morph the code and transform it. On Dec 6, 11:14 am, Ken Wesson wrote: > On Mon, Dec 6, 2010 at 4:02 AM, nickik wrote: > > The easy (and good) solution is to pass the running result onlong the > > way. This can be done in diffrent ways. > > > First the CL Style where you creat a new function in you function that > > then does all the work. (from > > Ken Wesson) > > > (defn list-length [coll] > > (let [ll (fn [n s] > > (if s > > (recur (inc n) (next s)) > > n))] > > (ll 0 (seq coll > > > I don't really like this because the core logic is somwhat hidden. > > ??? > > > Then we could use arity functions. (Alex Osborne) > > > (defn list-length > > ([coll] (list-length coll 0)) > > ([coll n] (if-let [s (seq coll)] > > (recur (rest s) (inc n)) > > n))) > > > This is nice style in my opinion > > Not in mine -- it exposes a public API of > list-length-plus-some-integer that a) doesn't make much sense and b) > is unlikely to be supported, since the implementation could be changed > to one that doesn't expose this. Of course sometimes a user wants to > add something to a length of a seq and then they could get a slight > speedup by using (list-length s n) instead of (+ n (list-length s)), > but that is c) premature optimization in the typical case. > > > > > > > but I would do it like this: > > > (defn list-lenght [coll] > > (loop [coll coll n 0] > > (if (empty? coll) > > n > > (recur (rest coll) (inc n) > > > or with seq instead of empty? > > > (defn list-lenght [coll] > > (loop [coll coll n 0] > > (if (seq coll) > > (recur (rest coll) (inc n)) > > n))) > > > Hope that helps a little. > > Why not > > (defn list-length [coll] > (let [s (seq coll)] > (loop [s s n 0] > (if s > (recur (next s) (inc n)) > n > > ? This may be slightly more efficient at no cost in clarity. -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: math utilities question
I have looked at incanter and like it very much, but these are all things that incanter can't currently do. --Robert McIntyre On Mon, Dec 6, 2010 at 3:15 AM, Saul Hazledine wrote: > On Dec 6, 12:27 am, Robert McIntyre wrote: >> I'm trying to use clojure for scientific data analysis but I keep >> running into lacunas of functionality. >> >> 6. symbolic manipulation as in sage > > This is something that would be awesome to have in Clojure because, > unlike most non-lisps, you can compile the result and use it. This > makes : > >> 7. minimizing non-linear functions > > much easier. > > Saul > > -- > 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 from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Why I'm getting StackoverflowError?
On Mon, Dec 6, 2010 at 4:02 AM, nickik wrote: > The easy (and good) solution is to pass the running result onlong the > way. This can be done in diffrent ways. > > First the CL Style where you creat a new function in you function that > then does all the work. (from > Ken Wesson) > > (defn list-length [coll] > (let [ll (fn [n s] > (if s > (recur (inc n) (next s)) > n))] > (ll 0 (seq coll > > I don't really like this because the core logic is somwhat hidden. ??? > Then we could use arity functions. (Alex Osborne) > > (defn list-length > ([coll] (list-length coll 0)) > ([coll n] (if-let [s (seq coll)] > (recur (rest s) (inc n)) > n))) > > This is nice style in my opinion Not in mine -- it exposes a public API of list-length-plus-some-integer that a) doesn't make much sense and b) is unlikely to be supported, since the implementation could be changed to one that doesn't expose this. Of course sometimes a user wants to add something to a length of a seq and then they could get a slight speedup by using (list-length s n) instead of (+ n (list-length s)), but that is c) premature optimization in the typical case. > but I would do it like this: > > (defn list-lenght [coll] > (loop [coll coll n 0] > (if (empty? coll) > n > (recur (rest coll) (inc n) > > or with seq instead of empty? > > (defn list-lenght [coll] > (loop [coll coll n 0] > (if (seq coll) > (recur (rest coll) (inc n)) > n))) > > Hope that helps a little. Why not (defn list-length [coll] (let [s (seq coll)] (loop [s s n 0] (if s (recur (next s) (inc n)) n ? This may be slightly more efficient at no cost in clarity. -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Why I'm getting StackoverflowError?
> What is the difference between rest and next? This has to do with lazyness. I wrote an answer to that on stackoverflow. http://stackoverflow.com/questions/4288476/clojure-rest-vs-next Should answer everthing. > I'm confused, should I use empty? or not? when to use it? > Why Clojure decided to handle an empty list as a not false? this is a > big (if not) departure from Common Lisp? The list is not nil because why should a empty list be nil but not en empty set/map/vector. To make all of them nil would probebly make other problems (100% sure we didn't do that would be intressting to know). So a common pattern is to just call seq or empty on the collection to be sure that the empty list dosn't pass as true. (On of the constant pain points when you work on books that are written in CL or Scheme) Next let my talk about the Stackoverflow: If you use empty? you don't have one on small list but if the get bigger you run in problems because you have to many nessted stacks. The easy (and good) solution is to pass the running result onlong the way. This can be done in diffrent ways. First the CL Style where you creat a new function in you function that then does all the work. (from Ken Wesson) (defn list-length [coll] (let [ll (fn [n s] (if s (recur (inc n) (next s)) n))] (ll 0 (seq coll I don't really like this because the core logic is somwhat hidden. Then we could use arity functions. (Alex Osborne) (defn list-length ([coll] (list-length coll 0)) ([coll n] (if-let [s (seq coll)] (recur (rest s) (inc n)) n))) This is nice style in my opinion but I would do it like this: (defn list-lenght [coll] (loop [coll coll n 0] (if (empty? coll) n (recur (rest coll) (inc n) or with seq instead of empty? (defn list-lenght [coll] (loop [coll coll n 0] (if (seq coll) (recur (rest coll) (inc n)) n))) Hope that helps a little. -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: math utilities question
On Dec 6, 12:27 am, Robert McIntyre wrote: > I'm trying to use clojure for scientific data analysis but I keep > running into lacunas of functionality. > > 6. symbolic manipulation as in sage This is something that would be awesome to have in Clojure because, unlike most non-lisps, you can compile the result and use it. This makes : > 7. minimizing non-linear functions much easier. Saul -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: math utilities question
On Mon, Dec 6, 2010 at 2:59 AM, Benny Tsai wrote: > Always nice to see a fellow Neal Stephenson fan! > > On Dec 5, 10:26 pm, Ken Wesson wrote: >> On Mon, Dec 6, 2010 at 12:14 AM, Miki wrote: >> > Have you looked at Incanter? (http://incanter.org/) >> >> Hmm, interesting. Is there a Rhetor too? Wow, that didn't take long. Less than three hours! Obviously it's true what they say about Lisp hackers. :) -- 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 from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Get sequence of values in arbitrarily nested collection
On Mon, Dec 6, 2010 at 2:57 AM, Benny Tsai wrote:
> When I saw the part about traversing an arbitrarily nested collection,
> I immediately thought of clojure.walk (http://clojure.github.com/
> clojure/clojure.walk-api.html). I ended up with this:
>
> (use 'clojure.walk)
>
> (defn all-vals [k coll]
> (let [vals (atom [])
> find-val (fn [form]
> (if-let [val (k form)] (swap! vals conj val))
> form)]
> (prewalk find-val coll)
> �...@vals))
>
> user=> (all-vals :distance {:goat "al" :distance 35})
> [35]
>
> user=> (all-vals :distance [{:goat "al" :distance 35}
> {:goat "paula" :distance 25}])
> [35 25]
>
> user=> (all-vals :distance [{:goat "al" :distance 35}
> {:goat "paula" :distance 25 :other {:distance 99}}])
> [35 25 99]
>
> I wanted to use walk in a purely functional manner (instead of the
> current approach of iteratively updating 'vals'). However, I was
> unable to do this, given that the function passed in to prewalk needs
> to preserve the structure of the nested collections. Hopefully
> someone can find a way to use walk in a purely functional way here.
I dunno. Seems kind of pointless, when
(defn values-of [k coll]
(if (instance? java.util.Map$Entry coll)
(recur k [(key coll) (val coll)])
(if-let [s (try (seq coll) (catch Exception _ nil))]
(let [not-found (Object.)
v (if (or (associative? coll) (instance? java.util.Map coll))
(get coll k not-found) not-found)
v (if-not (= v not-found) [v])
vs (map #(values-of k %) s)]
(apply concat v vs)
is only one line longer than what you have (counting the (use ...) and
following blank line), is pure functional, and uses only clojure.core.
And probably works on some of the java.util collections where the
clojure.walk version probably fails.
In fact, your code seems to require k to be a keyword, instead of
allowing it to be a string, or a number, or even nil.
--
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 from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
