Re: Will the JVM will always likely, remain the primary Clojure implementation ?

'Always' is not the right term to ask this question. I have the same question, but it could be asked with the better choice of words. Leon On Dec 27, 4:26 pm, Sukh Singh wrote: > Hi, > > I have noticed that this question is randomly appearing in many minds, and > it is frequently being asked, th

Searching for a picture

I'am preparing an introduce of clojure to my colleague. I remember that there's a picture showing that clojure = java + lisp, the picture must be a good example in my keynote, I think I should refer to it. In that picture, java is like a powful SUV with very big wheels, lisp is like a cool sedan wi

Re: Will the JVM will always likely, remain the primary Clojure implementation ?

Is there any chance of clojure community abandoning the JVM as the primary plaform in the future? On Dec 27, 4:41 pm, Michael Klishin wrote: > 2012/12/27 Sukh Singh > > > From the above statements, can I say that > > > *the JVM will always likely, remain the primary Clojure implementation* ? > >

Re: reduce-kv incompatible with subvec

I'm confused why we'd need to give up O(1) just to support something like reduce-kv on subvectors. Isn't the implementation of subvector just a wrapper around the original vector along with a start and end value? Current source here; https://github.com/clojure/clojure/blob/master/src/jvm/clojure/l

I'm curious if the development of native Clojurescript macros is in progress

Hello. I read about native clojurescript macros in this page( http://dev.clojure.org/display/design/Macros). It seems that Chris suggested his idea and implementationabout native macro about 8 months ago. So I'm curious if the adoption

Re: Parsing Clojure code in Clojure?

This may also help https://github.com/cgrand/sjacket On Thursday, December 27, 2012 9:32:10 PM UTC+1, Malcolm Sparks wrote: > > Thanks David, that was just the library I was looking for :) > On 27 Dec 2012 20:22, "David Nolen" > > wrote: > >> https://github.com/Bronsa/blind >> >> This library is

Re: list* not returning a list

On 27 December 2012 18:52, Ben Wolfson wrote: > On Thu, Dec 27, 2012 at 9:08 AM, Michał Marczyk > wrote: >> On 27 December 2012 03:28, Tom Jack wrote: >>> It looks like the only thing missing to make Cons implement IPersistentList >>> is IPersistentStack. Why not implement it? >> >> IPersistentS

Re: Parsing Clojure code in Clojure?

Thanks David, that was just the library I was looking for :) On 27 Dec 2012 20:22, "David Nolen" wrote: > https://github.com/Bronsa/blind > > This library is on its way to becoming a part of contrib as tools.reader > > David > > > On Thu, Dec 27, 2012 at 3:17 PM, Malcolm Sparks wrote: > >> Hi, >>

Parsing Clojure code in Clojure?

Hi, I need to parse Clojure code for purposes of code-insights, web presentation with hyperlinks between symbols, potential re-factoring, dead namespace illumination, visualization and inspection of increasingly large Clojure code-bases, code-style and compliance violation monitoring, that kin

Re: list* not returning a list

Making Cons implement IPersistentList will solve all cases except when list* gets only one argument. This is problematic. The source looks like this: (defn list* "Creates a new list containing the items prepended to the rest, the last of which will be treated as a sequence." {:added "1.0"

Re: [ANN] Slamhound 1.3.0

On Wed, Dec 26, 2012 at 11:52 AM, Phil Hagelberg wrote: > The Emacs integration has not been updated to work with nrepl.el yet > but should still work with slime. However, it's much easier to invoke > from the command line now. I just deployed a new slamhound.el that works with nrepl.el thanks to

Re: reduce-kv incompatible with subvec

Thanks a lot for this comment. It is probably a good idea to flag "subvec" in the docs as dangerous operation that does not really return a full vector. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@goo

Re: methods of a protocol

(defprotocol symbolicExpr (evalx [this args])) (deftype x [a]) (let [y #(+ 1 2)] (extend-type x symbolicExpr (evalx [this args] (y (evalx (x. 0) 0) On Wednesday, December 26, 2012 6:16:13 PM UTC-8, Sunil Nandihalli wrote: > > Hi Everybody, > It looks like the following way of definit

Re: reduce-kv incompatible with subvec

Clojure subvectors are "second class" data structures in terms of operations supported on them in several ways, partly because of the O(1) way that they are constructed and represented, and/or lack of implementations that work on the subvector data structure. The issue you raise is similar to t

reduce-kv incompatible with subvec

I am using Clojure 1.4.0. It seems that reduce-kv does not work together with subvec. For example: (reduce-kv (fn [v index u] (+ v (* index u))) [10 3 5]) results in 13, but (reduce-kv (fn [v index u] (+ v (* index u))) 0 (subvec [11 10 3 5] 1 3)) yields the following exception: No implemen

Re: list* not returning a list

On Thu, Dec 27, 2012 at 9:08 AM, Michał Marczyk wrote: > On 27 December 2012 03:28, Tom Jack wrote: >> It looks like the only thing missing to make Cons implement IPersistentList >> is IPersistentStack. Why not implement it? > > IPersistentStack extends IPersistentCollection, which includes > cou

ClojureCLR 1.5.0 RC 1

ClojureCLR is caught up with all changes to ClojureJVM up to 1.5.0-RC1. This includes all relevant bug fixes, the reducers library, reader literal improvements, new threading macros and other goodness. See changes.md. The only change not yet implemented is the new reliance on the test.generativ

Re: list* not returning a list

On 27 December 2012 03:28, Tom Jack wrote: > It looks like the only thing missing to make Cons implement IPersistentList > is IPersistentStack. Why not implement it? IPersistentStack extends IPersistentCollection, which includes count(), so that's no go for Cons (the rest part might be a lazy seq

Re: list* not returning a list

On Wed, Dec 26, 2012 at 6:28 PM, Tom Jack wrote: > A small bug in ClojureScript was related to this: > https://github.com/clojure/clojurescript/commit/88b36c177ebd1bb49dbd874a9d13652fd1de4027 > > It looks like the only thing missing to make Cons implement IPersistentList > is IPersistentStack. Why

Re: Will the JVM will always likely, remain the primary Clojure implementation ?

Maybe, Rich Hickey could answer this question... On Dec 27, 4:41 pm, Michael Klishin wrote: > 2012/12/27 Sukh Singh > > > From the above statements, can I say that > > > *the JVM will always likely, remain the primary Clojure implementation* ? > > The answer is: nobody will give you a definitive

Re: Will the JVM will always likely, remain the primary Clojure implementation ?

Maybe, Mr Rich Hickey could answer this On Dec 27, 4:41 pm, Michael Klishin wrote: > 2012/12/27 Sukh Singh > > > From the above statements, can I say that > > > *the JVM will always likely, remain the primary Clojure implementation* ? > > The answer is: nobody will give you a definitive answ

Re: New Clojurescript Project: browsing the web collectively.

Wow! It looks really cool! I was unable to install the Chrome extension from the site though. I wish you good luck! суббота, 1 декабря 2012 г., 10:45:24 UTC+7 пользователь Jeremy Kross написал: > > Hi all, > > I wrote a little thing in Clojurescript. Hopefully someone here will find > it inter

Re: Will the JVM will always likely, remain the primary Clojure implementation ?

Clojure is in many ways bound to the specifics of the Java platform: - no tail-call optimization; - adopts Java String and Java regex; - special handling of Java primitives and arrays; - and so on. All the libraries already depend on those specifics, so it's not just the language, bu

Will the JVM will always likely, remain the primary Clojure implementation ?

Hi, I have noticed that this question is randomly appearing in many minds, and it is frequently being asked, though there is no apparent reason on why it is asked :/ or maybe people are unable to pen down the exact reasons, and sad to say, even myself. There are reasons for which I ask t

Re: Writing a simple nrepl middleware and client

Tim, Your middleware never sends a response. Each request message can produce multiple response messages, sent at some later time (i.e. the request/response cycle is fundamentally asynchronous). Handler return values are ignored. So, assoc'ing the "result" into the request message as the retu

Re: Map vs Doseq on agents

Clojure's *map* is agnostic to whether the mapping function has side effects. The only thing to keep in mind is that *map* is not imperative, but declarative: it gives you a lazy sequence whose elements will be the results of the mapping function. As soon as you realize the sequence, for exampl

Re: methods of a protocol

This is exactly where "reify" is used for. There is a succinct piece of description in "The Joy of Clojure" on Page 198, from where I quote the following code example: (FIXO is a protocol like your symbolicExpr) (defn fixed-fixo ([limit] (fixed-fixo limit [])) ([limit vector] (

Re: Map vs Doseq on agents

Because unlike in CL, `map` in Clojure produces a lazy (and possibly infinite) sequence. If the mapping function is impure then laziness makes things harder to reason about. If you want `map` like behaviour but don't want laziness, you can check out `mapv` which returns a vector instead of a lazy

Map vs Doseq on agents

This code works: (doseq [q @draw-queue] > (draw-entity screen q))) This code does not: (map (fn [e] (draw-entity screen e)) @draw-queue) > The difference here is that `map` produces no side effects, while `doseq` expects side effects. In Common Lisp, `map` can take side effect creati