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 creating functions. I am interested why this is not the case in Clojure. Thank 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: 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 sequence and hence is not lazy. -BG On Thu, Dec 27, 2012 at 1:34 PM, Kruno Saho kruno.s...@gmail.com wrote: 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 creating functions. I am interested why this is not the case in Clojure. Thank 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 -- 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: 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] (reify FIXO (fixo-push [this value] (if ( (count vector) limit) (fixed-fixo limit (conj vector value)) this)) (fixo-peek [_] (peek vector)) (fixo-pop [_] (pop vector) -- 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: 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 example by printing it, the side effects will appear. On Thursday, December 27, 2012 9:04:20 AM UTC+1, Kruno Saho wrote: 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 creating functions. I am interested why this is not the case in Clojure. Thank 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: 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 return value of the
handler function won't do anything. You need to construct a response message
and send it on the transport hanging off of the request message; here's a
concise real-world example from ritz:
https://github.com/pallet/ritz/blob/develop/nrepl-middleware/src/ritz/nrepl/middleware/doc.clj
And, be a mensch, and send a done status in the response, too, so
message-scoped response seqs terminate properly without waiting for the read
timeout to expire. :-)
Cheers,
- Chas
On Dec 26, 2012, at 5:55 PM, Timothy Washington wrote:
Hi all,
I'm trying to put together some nrepl middleware. To get a basic
understanding, I thought I would implement some simple nrepl middleware in a
test project as seen in A). I can execute `M-x nrepl-jack-in`. But executing
the client, gives me an empty result (`repl/response-values` pulls nil out of
()). So I tried a bare bones communication example in the middleware page
(see B), but am still getting an error.
I like the example given in the leiningen sample project. But it seems I need
to get the basics working in A) and B), first.
Any insights here? Ultimately, I would like to create nrepl middleware for i)
Clojurescript compilation (cljsbuild auto (yes, I've already looked at
hiredman/nrepl-cljs-middleware)) and ii) a browser-connected repl (cljsbuild
repl-listen). I want to have these facilities in a `M-x nrepl-jack-in`
session.
A) basic nrepl middleware
project.clj (https://www.refheap.com/paste/7875)
middleware.clj (https://www.refheap.com/paste/7874)
client.clj (https://www.refheap.com/paste/7876)
B) lein repl
$ lein new thing
...
$ cd thing/
$ lein repl
nREPL server started on port 38789
...
user= (require '[clojure.tools.nrepl :as repl])
nil
user=
user= (with-open [conn (repl/connect :port 38789)]
#_= (- (repl/client conn 1000)
#_=(repl/message {:op eval :code (+ 2 3)})
#_=repl/response-values))
Exception in thread nREPL-worker-2 nil
user= java.net.SocketException: Broken pipe
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)
at clojure.tools.nrepl.transport$bencode$fn__214.invoke(transport.clj:81)
at clojure.tools.nrepl.transport.FnTransport.send(transport.clj:27)
at
clojure.tools.nrepl.middleware.pr_values$pr_values$fn$reify__479.send(pr_values.clj:23)
at
clojure.tools.nrepl.middleware.interruptible_eval$interruptible_eval$fn__536$fn__538.invoke(interruptible_eval.clj:171)
at clojure.core$comp$fn__4034.invoke(core.clj:2278)
at
clojure.tools.nrepl.middleware.interruptible_eval$run_next$fn__529.invoke(interruptible_eval.clj:137)
at clojure.lang.AFn.run(AFn.java:24)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Thanks in advance
Tim Washington
Interruptsoftware.ca
--
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
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 this question - - People (Majority) tend to stick with the primary implementations of certain multi-implementation software. And in the case of Clojure, the JVM implementation is the primary implementation now. - Having a primary implementation in case of BDFL lead software helps as a glue in the community. For example , CPython is the primary python implementation, even if there is an existance of IronPython or JPython. - The doubts of many, including me, will be cleared by an abstract answer... That 'many' also include the companies adopting something new, in this particular case, adopting clojure *QUESTION* Rich Hickey chose JVM as the platform of choice when he invented Clojure. It's community developed set of tools and documentation grew around the JVM (Leiningen, for example). From the above statements, can I say that *the JVM will always likely, remain the primary Clojure implementation* ? Thank 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: 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, but the whole ecosystem. Therefore, the underlying platform is nowhere near an abstracted-away implementation detail. Clojure on another platform is not the same language anymore; it's just a set of language features that share the spirit of Clojure. This means that the changing of the dominating platform will, if it ever happens, be a gradual process and not a sudden shift. There is a much higher chance of another language emerging on another platform, that may choose to adopt certain key features of Clojure, but is otherwise a completely different language. On Thursday, December 27, 2012 12:26:52 PM UTC+1, Sukh Singh wrote: 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 this question - - People (Majority) tend to stick with the primary implementations of certain multi-implementation software. And in the case of Clojure, the JVM implementation is the primary implementation now. - Having a primary implementation in case of BDFL lead software helps as a glue in the community. For example , CPython is the primary python implementation, even if there is an existance of IronPython or JPython. - The doubts of many, including me, will be cleared by an abstract answer... That 'many' also include the companies adopting something new, in this particular case, adopting clojure *QUESTION* Rich Hickey chose JVM as the platform of choice when he invented Clojure. It's community developed set of tools and documentation grew around the JVM (Leiningen, for example). From the above statements, can I say that *the JVM will always likely, remain the primary Clojure implementation* ? Thank 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: 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 interesting. Its a bookmarklet that lets users on a website see one another and interact. http://www.treklet.com You can click Try it Now to give it a run. Let me know if anyone has thoughts. Jeremy -- 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: 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 michael.s.klis...@gmail.com wrote: 2012/12/27 Sukh Singh suckhsi...@gmail.com 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 answer. This is open source software, primary implementations are not assigned, they are what people actually adopt. Seehttps://groups.google.com/d/topic/clojure/pEWgq1MGbYY/discussion -- MK http://github.com/michaelklishinhttp://twitter.com/michaelklishin -- 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: 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 michael.s.klis...@gmail.com wrote: 2012/12/27 Sukh Singh suckhsi...@gmail.com 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 answer. This is open source software, primary implementations are not assigned, they are what people actually adopt. Seehttps://groups.google.com/d/topic/clojure/pEWgq1MGbYY/discussion -- MK http://github.com/michaelklishinhttp://twitter.com/michaelklishin -- 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: list* not returning a list
On Wed, Dec 26, 2012 at 6:28 PM, Tom Jack t...@tomoj.la 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 not implement it? This seems very weird to me: (list? (cons 1 '())) false Especially since: (list? (empty (cons 1 '( true making list? true of cons cells would presumably also eliminate the need for those awkward (apply list ...)s in, e.g., clojure.walk/walk. -- Ben Wolfson Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure. [Larousse, Drink entry] -- 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: list* not returning a list
On 27 December 2012 03:28, Tom Jack t...@tomoj.la 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). Cheers, M. On Wednesday, December 26, 2012 4:13:38 PM UTC-6, Ben wrote: On Wed, Dec 26, 2012 at 2:07 PM, Stephen Compall stephen...@gmail.com wrote: On Wed, 2012-12-26 at 12:35 -0800, Marek Šrank wrote: ...however, its docstring says: Creates a new list containing the items prepended to the rest, the last of which will be treated as a sequence. List is almost always colloquial, not literally IPersistentList. I would be in favor of eliminating list?, really, in favor of seq?/sequential?/seqable?. Given that lists and (e.g.) vectors behave differently in some circumstances (as the first argument to conj, for instance), it seems desirable to be able to tell what one's got on one's hands. -- Ben Wolfson Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure. [Larousse, Drink entry] -- 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
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.generative library. That's going to wait until there are some improvements in the build and project management process. You won't notice the difference. One change specific to ClojureCLR: building/running under Mono is now supported. Have at it. -David -- 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: list* not returning a list
On Thu, Dec 27, 2012 at 9:08 AM, Michał Marczyk michal.marc...@gmail.com wrote: On 27 December 2012 03:28, Tom Jack t...@tomoj.la 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). Doesn't stop existing lazy seqs: user= (def x (repeat 2)) #'user/x user= (coll? x) true user= (instance? clojure.lang.IPersistentCollection x) true user= (count x) ; predictable lack of results -- Ben Wolfson Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure. [Larousse, Drink entry] -- 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
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 implementation of method: :kv-reduce of protocol: #'clojure.core.protocols/IKVReduce found for class: clojure.lang.APersistentVector$SubVector [Thrown class java.lang.IllegalArgumentException] -- 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: 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 this one: http://dev.clojure.org/jira/browse/CLJ-1082 I made one of the comments there about the possibility in the future of implementing subvec as an O(log n) operation rather than O(1), after there is an implementation of Reduced Radix Balanced Tree vectors. If this were done, subvectors would become just another kind of vector, and most or all of the limitations of operations supported on them would go away. RRB Tree vectors would also support O(log n) concatenation of two vectors. Andy On Dec 27, 2012, at 10:05 AM, Steven Obua wrote: 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 implementation of method: :kv-reduce of protocol: #'clojure.core.protocols/IKVReduce found for class: clojure.lang.APersistentVector$SubVector [Thrown class java.lang.IllegalArgumentException] -- 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: 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 definition is not allowed.. what is a good alternative way of doing this (defprotocol symbolicExpr (evalx [this args])) (let [y #(+ 1 2)] (deftype x [a] symbolicExpr (evalx [this args] (y I know I can do a (def y #(+ 1 2)) but that would unnecessarily make the variable global to the namespace. and I don't want to put it inside the method either, since it would have to re-evaluate the same var multiple times when I know it will remain constant across *evalx* method calls. what is a good way of achieving my goal without making *y *global to the namespace? Thanks, Sunil. -- 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: 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@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] Slamhound 1.3.0
On Wed, Dec 26, 2012 at 11:52 AM, Phil Hagelberg p...@hagelb.org 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 Tim King. -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: 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
:static true}
([args] (seq args))
([a args] (cons a args))
([a b args] (cons a (cons b args)))
([a b c args] (cons a (cons b (cons c args
([a b c d more]
(cons a (cons b (cons c (cons d (spread more)))
Calling 'seq' in the first case means that with calls like: (list* {:a 1})
we get clojure.lang.PersistentArrayMap$Seq and not a List. In theory, we
could do just (apply list args) here, but apply itself also uses list* in
its implementation. Luckily, it doesn't use the one-argument version of
list*, so we could probably declare 'apply' above the 'list*' in the
'core.clj' source and then use it there... Does it seem reasonably?
Marek
On Thursday, December 27, 2012 3:28:04 AM UTC+1, 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 not implement it?
On Wednesday, December 26, 2012 4:13:38 PM UTC-6, Ben wrote:
On Wed, Dec 26, 2012 at 2:07 PM, Stephen Compall
stephen...@gmail.com wrote:
On Wed, 2012-12-26 at 12:35 -0800, Marek Šrank wrote:
...however, its docstring says: Creates a new list containing the
items
prepended to the rest, the last of which will be treated as a
sequence.
List is almost always colloquial, not literally IPersistentList.
I would be in favor of eliminating list?, really, in favor of
seq?/sequential?/seqable?.
Given that lists and (e.g.) vectors behave differently in some
circumstances (as the first argument to conj, for instance), it seems
desirable to be able to tell what one's got on one's hands.
--
Ben Wolfson
Human kind has used its intelligence to vary the flavour of drinks,
which may be sweet, aromatic, fermented or spirit-based. ... Family
and social life also offer numerous other occasions to consume drinks
for pleasure. [Larousse, Drink entry]
--
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
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 kind of thing... Most of the functionality I need is locked away in private methods of clojure.lang.LispReader, so I wondered if there was something else I could re-use. I've recently come across https://github.com/cosmin/clojure-in-clojure and I remember Christophe Grand's presentation at EuroClojure last May which promised some source-manipulation library that could be shared across projects. Can anyone help point me to the current 'state of the art' with respect to parsing Clojure itself? Is there such a thing? Thanks, Malcolm -- 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: Parsing Clojure code in Clojure?
Thanks David, that was just the library I was looking for :) On 27 Dec 2012 20:22, David Nolen dnolen.li...@gmail.com 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 malc...@congreve.comwrote: 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 kind of thing... Most of the functionality I need is locked away in private methods of clojure.lang.LispReader, so I wondered if there was something else I could re-use. I've recently come across https://github.com/cosmin/clojure-in-clojure and I remember Christophe Grand's presentation at EuroClojure last May which promised some source-manipulation library that could be shared across projects. Can anyone help point me to the current 'state of the art' with respect to parsing Clojure itself? Is there such a thing? Thanks, Malcolm -- 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: list* not returning a list
On 27 December 2012 18:52, Ben Wolfson wolf...@gmail.com wrote: On Thu, Dec 27, 2012 at 9:08 AM, Michał Marczyk michal.marc...@gmail.com wrote: On 27 December 2012 03:28, Tom Jack t...@tomoj.la 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). Doesn't stop existing lazy seqs: Oh, indeed. Thanks! user= (def x (repeat 2)) #'user/x user= (coll? x) true user= (instance? clojure.lang.IPersistentCollection x) true user= (count x) ; predictable lack of results -- Ben Wolfson Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure. [Larousse, Drink entry] -- 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: 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 dnolen...@gmail.com javascript: 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 mal...@congreve.comjavascript: wrote: 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 kind of thing... Most of the functionality I need is locked away in private methods of clojure.lang.LispReader, so I wondered if there was something else I could re-use. I've recently come across https://github.com/cosmin/clojure-in-clojure and I remember Christophe Grand's presentation at EuroClojure last May which promised some source-manipulation library that could be shared across projects. Can anyone help point me to the current 'state of the art' with respect to parsing Clojure itself? Is there such a thing? Thanks, Malcolm -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: 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 clo...@googlegroups.comjavascript: Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com javascript: 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
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
implementationhttps://github.com/chrismgray/clojurescript/tree/defmacroabout
native macro about 8 months ago.
So I'm curious if the adoption of native macros into Clojurescript is in
progress by contributors.
If not, is it on the plan at least? Or is it rejected after some discussion?
I have another question. I had a chance to demonstrate the advantage of
Clojurescript(or Lisp which is translated to Javascript) in front of some
people in my company.
I presented an example which shows how to escape from callback hell by
using macros like domonad(or CPS trasnformer):
// You can't escape callback hell in this case although you use libraries
like Promise, Deferred, Async.js and Q.
var promise = Q.fcall(function (){
async1();
}
promise.then(function (a) {
return async2(a).then (function (b) {
return async3(b).then (function(c) {
return async4(c).then (function(d) {
process(a, b, c, d);
});
});
});
});
;; Continuation passing style code can be generated from more readable code
by macros
(domonad identity
[a (async1)
b (async2 a)
c (async3 b)
d (async4 c)]
(process a b c d))
This example did not satisfy my audience.
They required more significant examples to advocate the use of
Clojurescript or Lisp dialect transleted to Javascript, so I agreed to find
more.
Can you suggest any good examples?
Thanks,
Chanwoo
--
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: 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/lang/APersistentVector.java I apologize if I'm missing something key here. On Fri, Dec 28, 2012 at 3:18 AM, Andy Fingerhut andy.finger...@gmail.comwrote: http://dev.clojure.org/jira/browse/CLJ-1082 -- 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: 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 michael.s.klis...@gmail.com wrote: 2012/12/27 Sukh Singh suckhsi...@gmail.com 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 answer. This is open source software, primary implementations are not assigned, they are what people actually adopt. Seehttps://groups.google.com/d/topic/clojure/pEWgq1MGbYY/discussion -- MK http://github.com/michaelklishinhttp://twitter.com/michaelklishin -- 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
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 with two wings, and clojur is like a monster car with big wheels and wings. So forget where i saw the picture last time, it seems in some one's lecture. I will be very priciate if u knonw it, Thanks! -- 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: 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 suckhsi...@gmail.com wrote: 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 this question - - People (Majority) tend to stick with the primary implementations of certain multi-implementation software. And in the case of Clojure, the JVM implementation is the primary implementation now. - Having a primary implementation in case of BDFL lead software helps as a glue in the community. For example , CPython is the primary python implementation, even if there is an existance of IronPython or JPython. - The doubts of many, including me, will be cleared by an abstract answer... That 'many' also include the companies adopting something new, in this particular case, adopting clojure *QUESTION* Rich Hickey chose JVM as the platform of choice when he invented Clojure. It's community developed set of tools and documentation grew around the JVM (Leiningen, for example). From the above statements, can I say that *the JVM will always likely, remain the primary Clojure implementation* ? Thank 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
