Re: clojure.math.combinatorics jar
On Tue, Dec 27, 2011 at 12:47 PM, vitalyper vitaly...@yahoo.com wrote: Do we have this jar in clojars? Clojure Contrib is released to Maven Central. Searched for it under math but could not find it. http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.clojure%22%20AND%20a%3A%22math.combinatorics%22 -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- 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: clojure.math.combinatorics jar
I believe that 0.0.2 is the most current release. By cutting a release, that bumps the working snapshot number up to 0.0.3, but there have been no changes made since 0.0.2. --Mark -- 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] swank-clojure 1.3.4 released
On Wed, Dec 28, 2011 at 6:33 AM, Phil Hagelberg p...@hagelb.org wrote: I just pushed out version 1.3.4 of Swank Clojure. Does it work with Clojure 1.2? What exclusions do I need for that in my project.clj? 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
Namespaced keywords in metadata
I've been writing some code which adds some keywords in metadata associated to vars. Initially I used namespaces keywords to not collide with other keywords. The problem is that having to namespace these keywords makes the code, at least, ugly. Is it any consensus in the use of keywords in metadata? I've done some search of examples and, most of them, does not use namespaced keywords, but I am not sure. Thanks, Juan Manuel -- 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] okasaki-clojure
El sábado 24 de diciembre de 2011 05:21:33 UTC+1, David Nolen escribió: I'd like to fully support types/records as they provide significant performance benefits. Now I'm not very much interested in performance. I have added the possibility to define datatypes that use lazy constructors and now I want to implement more data structures. Probably won't happen in the near, near future - unless of course somebody wants to take a stab at it :) Seems very interesting. I'll download match's code and try to get an overall idea of it to decide if I can be of any help. It is tempting because protocols+types+records are one of the biggest holes I have in clojure knowledge. Juan Manuel -- 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: Namespaced keywords in metadata
I would recommend sticking with namespaced keywords to avoid clashes with var metadata keys. Remember qualified keywords respect namespace aliasing and ::keyword is qualified in the current namespace. These can help making the code more readable. You could store keywords in vars if namespaced keywords really bothered you. (def mykey ::mykey) Thanks, Ambrose On Wed, Dec 28, 2011 at 5:54 PM, JuanManuel Gimeno Illa jmgim...@gmail.comwrote: I've been writing some code which adds some keywords in metadata associated to vars. Initially I used namespaces keywords to not collide with other keywords. The problem is that having to namespace these keywords makes the code, at least, ugly. Is it any consensus in the use of keywords in metadata? I've done some search of examples and, most of them, does not use namespaced keywords, but I am not sure. Thanks, Juan Manuel -- 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: Namespaced keywords in metadata
El miércoles 28 de diciembre de 2011 11:01:16 UTC+1, Ambrose Bonnaire-Sergeant escribió: I would recommend sticking with namespaced keywords to avoid clashes with var metadata keys. Remember qualified keywords respect namespace aliasing and ::keyword is qualified in the current namespace. These can help making the code more readable. OK You could store keywords in vars if namespaced keywords really bothered you. (def mykey ::mykey) My main concern is that when using reader macros for metadata I have to fully qualify it. For instance, I must write: (defdatatype ::Streams Nil (^:ml.datatypes/lazy Cons elem stream)) instead of (defdatatype ::Streams Nil (^:lazy Cons elem stream)) But I suppose the benefits of namespacing outweight these inconveniences. Thanks, Juan Manuel Thanks, Ambrose On Wed, Dec 28, 2011 at 5:54 PM, JuanManuel Gimeno Illa jmgi...@gmail.com wrote: I've been writing some code which adds some keywords in metadata associated to vars. Initially I used namespaces keywords to not collide with other keywords. The problem is that having to namespace these keywords makes the code, at least, ugly. Is it any consensus in the use of keywords in metadata? I've done some search of examples and, most of them, does not use namespaced keywords, but I am not sure. Thanks, Juan Manuel -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clo...@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+u...@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] swank-clojure 1.3.4 released
On 28/12/2011, at 2:03 PM, Phil Hagelberg wrote: I just pushed out version 1.3.4 of Swank Clojure. Great stuff, thanks! I ran into the problem with an older clj-stacktrace jar as you describe in the documentation, because I'm including [ring 1.0.1] in my project.clj, which uses clj-stacktrace 0.2.2 instead of 0.2.4. Since ring is a fairly popular piece of software it might be worth considering mentioning this in your documentation (in addition to the note about incanter and an older clj-stacktrace)? I changed my ring dependencies in project.clj into this, which works: [clj-stacktrace 0.2.4] [ring 1.0.1 :exclusions [clj-stacktrace]] cheers, gert -- 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: Namespaced keywords in metadata
Hi,
Am 28.12.2011 um 11:09 schrieb JuanManuel Gimeno Illa:
My main concern is that when using reader macros for metadata I have to fully
qualify it. For instance, I must write:
(defdatatype
::Streams
Nil
(^:ml.datatypes/lazy Cons elem stream))
instead of
(defdatatype
::Streams
Nil
(^:lazy Cons elem stream))
But I suppose the benefits of namespacing outweight these inconveniences.
Please consider the alternatives outlined by Ambrose:
user= (require '[clojure.string :as str])
nil
user= (meta ^:foo [])
{:foo true}
user= (meta ^::foo [])
{:user/foo true}
user= (meta ^::str/foo [])
{:clojure.string/foo true}
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: Namespaced keywords in metadata
Finally I have considered your advice and namespaced the keywords.
Thanks,
Juan Manuel
El miércoles 28 de diciembre de 2011 12:33:22 UTC+1, Meikel Brandmeyer
(kotarak) escribió:
Hi,
Am 28.12.2011 um 11:09 schrieb JuanManuel Gimeno Illa:
My main concern is that when using reader macros for metadata I have to
fully qualify it. For instance, I must write:
(defdatatype
::Streams
Nil
(^:ml.datatypes/lazy Cons elem stream))
instead of
(defdatatype
::Streams
Nil
(^:lazy Cons elem stream))
But I suppose the benefits of namespacing outweight these inconveniences.
Please consider the alternatives outlined by Ambrose:
user= (require '[clojure.string :as str])
nil
user= (meta ^:foo [])
{:foo true}
user= (meta ^::foo [])
{:user/foo true}
user= (meta ^::str/foo [])
{:clojure.string/foo true}
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: (:require [clojure.contrib.sql :as sql]))
Doesn't this line of your example run as test? user= (ns jay.test (:require [clojure.contrib.sql :as sql])) = The other code I listed was code to run as a clojure program , not as leiningen, which you said was missing lines of code after the (ns I apologize for my lack of understanding, but I feel I must be able to access databases or I can't use clojure On Dec 28, 12:58 am, Sean Corfield seancorfi...@gmail.com wrote: Sorry, I have no idea what you mean... On Tue, Dec 27, 2011 at 9:56 PM, jayvandal s...@ida.net wrote: I have tried the example you provided and it works except I don't see any file printout of the records when I run not as test but without test. Is test going to show any data? Can I ask for a record count? why doesn't the sql jar show for every example that is in the internet? -- 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: Clojure list syntax sugar: f(x) notation
Quoth Louis Yu Lu on Boomtime, the 70th of The Aftermath: The proposed syntax sugar apparently pleases my eyes and fingers from conventional languages. With some experiments, I found the code is more readable for me to use f(x) notation for function call, and (op x) for operator. It sounds like you're interested in M-expressions [1]; anyone care to implement M-expressions for Clojure as reader macros [2]? Footnotes: [1] http://en.wikipedia.org/wiki/M-expression [2] https://github.com/klutometis/reader-macros -- 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: (:require [clojure.contrib.sql :as sql]))
On Wed, Dec 28, 2011 at 7:50 AM, jayvandal s...@ida.net wrote: Doesn't this line of your example run as test? user= (ns jay.test (:require [clojure.contrib.sql :as sql])) It's just declaring a namespace and requiring clojure.contrib.sql (which loads the library). I called it jay.test because it was a test for Jay :) The other code I listed was code to run as a clojure program , not as leiningen, which you said was missing lines of code after the (ns You have not shown how you actually RUN the code. Since you're not using Leiningen, I suspect you have a classpath problem but you need to show us exactly how you are trying to run the code for us to help debug that. I apologize for my lack of understanding, but I feel I must be able to access databases or I can't use clojure I'm sure it's just something simple missing in how you are trying to run the code. As I've shown, the code itself is likely fine since my example loads clojure.contrib.sql correctly (because I'm using Leiningen, the classpath issues are taken care of). -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- 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] swank-clojure 1.3.4 released
Gert Verhoog m...@gertalot.com writes: On 28/12/2011, at 2:03 PM, Phil Hagelberg wrote: I just pushed out version 1.3.4 of Swank Clojure. Great stuff, thanks! I ran into the problem with an older clj-stacktrace jar as you describe in the documentation, because I'm including [ring 1.0.1] in my project.clj, which uses clj-stacktrace 0.2.2 instead of 0.2.4. This is actually already mentioned, but I'll try to make it clearer. Do you think this is good? Since swank-clojure 1.3.4, having versions of clj-stacktrace older than 0.2.4 in your project or user-level plugins will cause `Unable to resolve symbol: pst-elem-str` errors. Keep in mind that user-level plugins in `~/.lein/plugins` are uberjars in Leiningen 1.x, so it's possible that one of your plugins (such as `lein-difftest` before version 1.3.7) contains an old clj-stacktrace even if it doesn't have its own file there. Specifying a newer version should be enough if you're having trouble: :dependencies [[clj-stacktrace 0.2.4]] The :exclusions line shouldn't be necessary. -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: [ANN] swank-clojure 1.3.4 released
Baishampayan Ghose b.gh...@gmail.com writes: On Wed, Dec 28, 2011 at 6:33 AM, Phil Hagelberg p...@hagelb.org wrote: I just pushed out version 1.3.4 of Swank Clojure. Does it work with Clojure 1.2? What exclusions do I need for that in my project.clj? I'm not aware of any issues with using Swank Clojure in 1.2. If you're having trouble please post details. -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
about partial and clojure curry
Hi everybody..I've a little question..the way in than clojure implement curry is affected for the jvm or it is a Rick decision ...in haskell every function accept only one parameter and if you call a function with 1 parameter it use currying...I feel than it is really natural and more clean than use partial for example map function a translation haskell map (+3) [1,2,3] to clojure must be (map (+ 3) '(1 2 3)) much more clean than (map #(+ 3 %) '(1 2 3) or even (map (partial + 3) '(1 2 3)) in this example the difference is not so dramatic but in more extenses codes you can really note a big difference... I'm a clojure newbie and I like a lot clojure...but many times I feel than haskell do the code much more cleaner and I presume than maybe it would be for the jvm limitations... thanks a lot -- 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: about partial and clojure curry
(+ 3) already has a meaning in Clojure. It's an expression whose answer is 3. How is Clojure supposed to read your mind and know that you want the output to be a function there? Similarly, would (+ 3 2) be 5, or would it be the curried function of + applied to 3 and 2 and waiting for more parameters? In any case, there's no way to get Haskell's behavior and also get things like: sane errors when you pass a function too few arguments functions that can take any number of arguments -- 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: about partial and clojure curry
This is definitely not a JVM limitation, it is a design choice. There are lisps that have automatic currying, e.g., Qi (http:// en.wikipedia.org/wiki/Qi_(programming_language)). I think the main issue, why this is not convenient, is that Clojure functions tend to accept a variable number of arguments where in Haskell, one would resort to lists. Addition is an example where any non-negative number of arguments is fine. If (+ 3) was a function, then you would not be able to (apply + u) to get the sum of the list u when u is of length one. -- Peteris Erins On Dec 29, 1:40 am, ron clag...@gmail.com wrote: Hi everybody..I've a little question..the way in than clojure implement curry is affected for the jvm or it is a Rick decision ...in haskell every function accept only one parameter and if you call a function with 1 parameter it use currying...I feel than it is really natural and more clean than use partial for example map function a translation haskell map (+3) [1,2,3] to clojure must be (map (+ 3) '(1 2 3)) much more clean than (map #(+ 3 %) '(1 2 3) or even (map (partial + 3) '(1 2 3)) in this example the difference is not so dramatic but in more extenses codes you can really note a big difference... I'm a clojure newbie and I like a lot clojure...but many times I feel than haskell do the code much more cleaner and I presume than maybe it would be for the jvm limitations... thanks a lot -- 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
Clooj is great :)
Have just been trying Clooj out and I have to say, it is really really good! Thanks Arthur for the neat tool. I particularly like that the repl interaction is very slick, and how it takes care of project structure in a very minimalist but clearly structured way. -- 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] swank-clojure 1.3.4 released
Hi, I don't get colored stacktrace. http://imgur.com/5NCEW Is any procedure needed? I've tried 1.3.4 with clojure 1.2.1/1.3.0 and Emacs 23.3. My .emacs.el includes only load-path and marmalade settings. including [ring 1.0.1] in my project.clj, which uses clj-stacktrace 0.2.2 instead of 0.2.4. This is actually already mentioned, but I'll try to make it clearer. Do you think this is good? I think ring should specify dependency using version range like below. [clj-stacktrace [0.2.2,)] ;; 0.2.2 = x http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution I didn't know it until recently, but now I think wherever possible every library should specify version with it. Thanks. 2011/12/29 Phil Hagelberg p...@hagelb.org: Gert Verhoog m...@gertalot.com writes: On 28/12/2011, at 2:03 PM, Phil Hagelberg wrote: I just pushed out version 1.3.4 of Swank Clojure. Great stuff, thanks! I ran into the problem with an older clj-stacktrace jar as you describe in the documentation, because I'm including [ring 1.0.1] in my project.clj, which uses clj-stacktrace 0.2.2 instead of 0.2.4. This is actually already mentioned, but I'll try to make it clearer. Do you think this is good? Since swank-clojure 1.3.4, having versions of clj-stacktrace older than 0.2.4 in your project or user-level plugins will cause `Unable to resolve symbol: pst-elem-str` errors. Keep in mind that user-level plugins in `~/.lein/plugins` are uberjars in Leiningen 1.x, so it's possible that one of your plugins (such as `lein-difftest` before version 1.3.7) contains an old clj-stacktrace even if it doesn't have its own file there. Specifying a newer version should be enough if you're having trouble: :dependencies [[clj-stacktrace 0.2.4]] The :exclusions line shouldn't be necessary. -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 -- 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] swank-clojure 1.3.4 released
On Wed, Dec 28, 2011 at 6:43 PM, Takahiro fat...@googlemail.com wrote: I think ring should specify dependency using version range like below. [clj-stacktrace [0.2.2,)] ;; 0.2.2 = x http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution I didn't know it until recently, but now I think wherever possible every library should specify version with it. The only problem is when a future version of a dependency introduces a breaking change (which happens quite a lot with relatively new libraries). -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- 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: Clojure list syntax sugar: f(x) notation
Instead of using overloaded (), may be f[x] will cause less trouble, and more inline with clojure's syntax as [ ] already being used for defining the arguments of the function. Louis On Dec 27, 5:26 pm, Gert Verhoog m...@gertalot.com wrote: On 26/12/2011, at 6:23 PM, Louis Yu Lu wrote: My proposition is enhance Clojure to accept both (f x) and f(x) Fortunately, I don't see that happening, for several reasons (many of which have been mentioned). It adds complexity, causes confusion and inconsistent coding styles and it will break everything that parses s-expressions (data = code after all). Imagine trying to read lisp code that is a mix-n-match of the following: ;; the following would be equivalent: (g (f a b)) (g f(a b)) g((f a b)) g(f(a b)) ;; the following would be equivalent: ((f a) b) (f(a) b) (f a)(b) f(a)(b) FOUR different ways of expressing ((f a) b). How is that helping those trying to learn Clojure? Also, note that (g f(a b)) and (g f (a b)) have very different semantics, even though the only difference is the added whitespace between two tokens. If you stick with the elegant simplicity of s-expressions for a few more weeks, I promise that you won't even notice it anymore and you'll find that it's perfectly readable. cheers, gert -- 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: Clojure list syntax sugar: f(x) notation
Why not use fx ? On Thu, Dec 29, 2011 at 12:49 PM, Louis Yu Lu louisy...@gmail.com wrote: Instead of using overloaded (), may be f[x] will cause less trouble, and more inline with clojure's syntax as [ ] already being used for defining the arguments of the function. Louis On Dec 27, 5:26 pm, Gert Verhoog m...@gertalot.com wrote: On 26/12/2011, at 6:23 PM, Louis Yu Lu wrote: My proposition is enhance Clojure to accept both (f x) and f(x) Fortunately, I don't see that happening, for several reasons (many of which have been mentioned). It adds complexity, causes confusion and inconsistent coding styles and it will break everything that parses s-expressions (data = code after all). Imagine trying to read lisp code that is a mix-n-match of the following: ;; the following would be equivalent: (g (f a b)) (g f(a b)) g((f a b)) g(f(a b)) ;; the following would be equivalent: ((f a) b) (f(a) b) (f a)(b) f(a)(b) FOUR different ways of expressing ((f a) b). How is that helping those trying to learn Clojure? Also, note that (g f(a b)) and (g f (a b)) have very different semantics, even though the only difference is the added whitespace between two tokens. If you stick with the elegant simplicity of s-expressions for a few more weeks, I promise that you won't even notice it anymore and you'll find that it's perfectly readable. cheers, gert -- 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: Clojure list syntax sugar: f(x) notation
f%x% would probably work outside of #() forms. % is a symbol delimiter. Ambrose On Thu, Dec 29, 2011 at 12:56 PM, Ambrose Bonnaire-Sergeant abonnaireserge...@gmail.com wrote: Why not use fx ? On Thu, Dec 29, 2011 at 12:49 PM, Louis Yu Lu louisy...@gmail.com wrote: Instead of using overloaded (), may be f[x] will cause less trouble, and more inline with clojure's syntax as [ ] already being used for defining the arguments of the function. Louis On Dec 27, 5:26 pm, Gert Verhoog m...@gertalot.com wrote: On 26/12/2011, at 6:23 PM, Louis Yu Lu wrote: My proposition is enhance Clojure to accept both (f x) and f(x) Fortunately, I don't see that happening, for several reasons (many of which have been mentioned). It adds complexity, causes confusion and inconsistent coding styles and it will break everything that parses s-expressions (data = code after all). Imagine trying to read lisp code that is a mix-n-match of the following: ;; the following would be equivalent: (g (f a b)) (g f(a b)) g((f a b)) g(f(a b)) ;; the following would be equivalent: ((f a) b) (f(a) b) (f a)(b) f(a)(b) FOUR different ways of expressing ((f a) b). How is that helping those trying to learn Clojure? Also, note that (g f(a b)) and (g f (a b)) have very different semantics, even though the only difference is the added whitespace between two tokens. If you stick with the elegant simplicity of s-expressions for a few more weeks, I promise that you won't even notice it anymore and you'll find that it's perfectly readable. cheers, gert -- 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] swank-clojure 1.3.4 released
Hi-- The only way I could get the colorized stack-trace was to use M-x clojure-jack-in. Normally, I type lein swank on a command line, then use M-x slime-connect from Emacs. This is so that I can see the clojure.tools.logging output. (I've no idea where it goes when you use clojure-jack-in. I'm also using emacs 24 and clojure-mode 1.11.5. -- 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: Clojure list syntax sugar: f(x) notation
Since square brackets have been usurped by vectors, angle brackets could be used to approximate M-expressions. Quoth Ambrose Bonnaire-Sergeant on Boomtime, the 70th of The Aftermath: Why not use fx ? On Thu, Dec 29, 2011 at 12:49 PM, Louis Yu Lu louisy...@gmail.com wrote: Instead of using overloaded (), may be f[x] will cause less trouble, and more inline with clojure's syntax as [ ] already being used for defining the arguments of the function. Louis On Dec 27, 5:26 pm, Gert Verhoog m...@gertalot.com wrote: On 26/12/2011, at 6:23 PM, Louis Yu Lu wrote: My proposition is enhance Clojure to accept both (f x) and f(x) Fortunately, I don't see that happening, for several reasons (many of which have been mentioned). It adds complexity, causes confusion and inconsistent coding styles and it will break everything that parses s-expressions (data = code after all). Imagine trying to read lisp code that is a mix-n-match of the following: ;; the following would be equivalent: (g (f a b)) (g f(a b)) g((f a b)) g(f(a b)) ;; the following would be equivalent: ((f a) b) (f(a) b) (f a)(b) f(a)(b) FOUR different ways of expressing ((f a) b). How is that helping those trying to learn Clojure? Also, note that (g f(a b)) and (g f (a b)) have very different semantics, even though the only difference is the added whitespace between two tokens. If you stick with the elegant simplicity of s-expressions for a few more weeks, I promise that you won't even notice it anymore and you'll find that it's perfectly readable. cheers, gert -- 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: Clojure list syntax sugar: f(x) notation
On further thought, it will be a breaking change (def fx 1) (let [x 1] fx) % would work better. Ambrose On Thu, Dec 29, 2011 at 2:00 PM, Peter Danenberg p...@roxygen.org wrote: Since square brackets have been usurped by vectors, angle brackets could be used to approximate M-expressions. Quoth Ambrose Bonnaire-Sergeant on Boomtime, the 70th of The Aftermath: Why not use fx ? On Thu, Dec 29, 2011 at 12:49 PM, Louis Yu Lu louisy...@gmail.com wrote: Instead of using overloaded (), may be f[x] will cause less trouble, and more inline with clojure's syntax as [ ] already being used for defining the arguments of the function. Louis On Dec 27, 5:26 pm, Gert Verhoog m...@gertalot.com wrote: On 26/12/2011, at 6:23 PM, Louis Yu Lu wrote: My proposition is enhance Clojure to accept both (f x) and f(x) Fortunately, I don't see that happening, for several reasons (many of which have been mentioned). It adds complexity, causes confusion and inconsistent coding styles and it will break everything that parses s-expressions (data = code after all). Imagine trying to read lisp code that is a mix-n-match of the following: ;; the following would be equivalent: (g (f a b)) (g f(a b)) g((f a b)) g(f(a b)) ;; the following would be equivalent: ((f a) b) (f(a) b) (f a)(b) f(a)(b) FOUR different ways of expressing ((f a) b). How is that helping those trying to learn Clojure? Also, note that (g f(a b)) and (g f (a b)) have very different semantics, even though the only difference is the added whitespace between two tokens. If you stick with the elegant simplicity of s-expressions for a few more weeks, I promise that you won't even notice it anymore and you'll find that it's perfectly readable. cheers, gert -- 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 -- 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: Clojure list syntax sugar: f(x) notation
% would work even worse because it doesn't nest. I still think the whole idea ia a dreadful one, but would cause problems less often than other suggestions. On Dec 28, 10:06 pm, Ambrose Bonnaire-Sergeant abonnaireserge...@gmail.com wrote: On further thought, it will be a breaking change (def fx 1) (let [x 1] fx) % would work better. Ambrose On Thu, Dec 29, 2011 at 2:00 PM, Peter Danenberg p...@roxygen.org wrote: Since square brackets have been usurped by vectors, angle brackets could be used to approximate M-expressions. Quoth Ambrose Bonnaire-Sergeant on Boomtime, the 70th of The Aftermath: Why not use fx ? On Thu, Dec 29, 2011 at 12:49 PM, Louis Yu Lu louisy...@gmail.com wrote: Instead of using overloaded (), may be f[x] will cause less trouble, and more inline with clojure's syntax as [ ] already being used for defining the arguments of the function. Louis On Dec 27, 5:26 pm, Gert Verhoog m...@gertalot.com wrote: On 26/12/2011, at 6:23 PM, Louis Yu Lu wrote: My proposition is enhance Clojure to accept both (f x) and f(x) Fortunately, I don't see that happening, for several reasons (many of which have been mentioned). It adds complexity, causes confusion and inconsistent coding styles and it will break everything that parses s-expressions (data = code after all). Imagine trying to read lisp code that is a mix-n-match of the following: ;; the following would be equivalent: (g (f a b)) (g f(a b)) g((f a b)) g(f(a b)) ;; the following would be equivalent: ((f a) b) (f(a) b) (f a)(b) f(a)(b) FOUR different ways of expressing ((f a) b). How is that helping those trying to learn Clojure? Also, note that (g f(a b)) and (g f (a b)) have very different semantics, even though the only difference is the added whitespace between two tokens. If you stick with the elegant simplicity of s-expressions for a few more weeks, I promise that you won't even notice it anymore and you'll find that it's perfectly readable. cheers, gert -- 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 -- 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] swank-clojure 1.3.4 released
Hi Sean, The only problem is when a future version of a dependency introduces a breaking change (which happens quite a lot with relatively new libraries).You are right. hmm which we should choose might be bepend on which attitude is conservative or progressive. Keith The only way I could get the colorized stack-trace was to use M-x clojure-jack-in. I'm also using emacs 24 and clojure-mode 1.11.5. I switched emacs to 24 and get the same results. Thanks! 2011/12/29 Sean Corfield seancorfi...@gmail.com: On Wed, Dec 28, 2011 at 6:43 PM, Takahiro fat...@googlemail.com wrote: I think ring should specify dependency using version range like below. [clj-stacktrace [0.2.2,)] ;; 0.2.2 = x http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution I didn't know it until recently, but now I think wherever possible every library should specify version with it. The only problem is when a future version of a dependency introduces a breaking change (which happens quite a lot with relatively new libraries). -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ Perfection is the enemy of the good. -- Gustave Flaubert, French realist novelist (1821-1880) -- 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
[ANN] clj-stream (Iteratees in Clojure)
Hey guys, I've been working on this for a while, experimenting a lot with possible implementations of Iteratees in Clojure, the library is more like a proof of concept (not released yet to clojars). https://github.com/roman/clj-stream If you are interested in Iteratees (or trying to understand how they work) I tried my best to implement a friendly API. Some of the things this library provides: * All public functions are tested and documented. * A Monadic interface so that you can compose simple Iteratees (Consumers) into more complex ones. * A macro (run*) that facilitates the execution of Iteratees (Consumers). Some of the known drawbacks that I'm looking forward to improve (if you have any suggestions, please let me know): * Some Iteratees (Consumers) and Enumeratees (Filters) hold state through recursion, I'm afraid this might cause a StackOverflow with big numbers, so this is something that definitely needs to get improved. Thanks for your feedback. Roman.- -- 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
