Re: Nil Coalesce
On 18 August 2010 04:44, Justin Kramer jkkra...@gmail.com wrote: On Aug 17, 4:42 pm, Alan a...@malloys.org wrote: Devious! The OP wanted to handle underflow of the subs collection though, so you need a tweak: (apply assoc v (interleave (positions nil? v) (concat subs (repeat nil interleave stops once either collection is exhausted. In your modified version, nils replace nils when there are fewer substitutions than nil positions, which is unnecessary. Unless I'm missing something...which is entirely possible. nils replace nils when there are fewer substitutions than nil positions was one of the requirements. From the first post: If nil is encountered in the first sequence and the second sequence is exhaused, nil will be returned: e.g. user (nil-coalesce (nil 1 2 3 nil nil) (4 5)) (4 1 2 3 5 nil) -- Michael Wood esiot...@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
Program design
Dear Friends, I am thinking about porting my existing program to clojure. Is there any way of designing equivalents to classes with simple inheritance? For e.g. if I have base class fruit and derived classes apple and orange. The OOP design gives me a possibility to handle those object in the same way. Thank you in advance. -- 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: Program design
I think the easiest way to port OO code would be to use Clojure's multimethods, dispatching on the type of the first argument. -- 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: Emacs auto-complete plugin for slime users
On 17 Aug 2010, at 21:21, Steve Molitor wrote: Sorry my message got truncated. Let's try again: Fuzzy completion (ac-source-slime-fuzzy) isn't working for me. It complains that the function slime-fuzzy-completions is not defined. I'm using slime.el version 2010404, which does not define that function, although it does define slime-simple-completions. Not sure if there's a newer version of slime.el out there but I did install fresh about a week or two ago. Not to worry; I'm very happy with ac-source-slime-simple. To use fuzzy completions you need to have and require slime-fuzzy.el, which comes with the full slime, but not with the version in ELPA. -Steve -- 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: multiline strings and multiline comments ?
On Aug 17, 12:14 am, Lee Spector lspec...@hampshire.edu wrote: On Aug 16, 2010, at 4:13 PM, Meikel Brandmeyer wrote: Every descent editor should provide a comment-selected-text functionality. I've worked in several editors that have comment-selected-text, but I don't see it in Eclipse/Counterclockwise I've created issue: comment multiple lines by pressing Ctrl+/ http://code.google.com/p/counterclockwise/issues/detail?id=61 Still under development. -- Zmi La -- 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
Simple question about name-spaces
Dear all, I have a simple problem I can't manage to solve. I have a library of multiple namespaces( a b c) that I want to include in one namespace lib, so user of the library can only use/require lib and have access to all the functions i a, b and c. What is the standard way to do that? Best, Nicolas. -- 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: Simple question about name-spaces
Hi,
On 18 Aug., 11:49, Nicolas Oury nicolas.o...@gmail.com wrote:
I have a library of multiple namespaces( a b c) that I want to include
in one namespace lib, so user of
the library can only use/require lib and have access to all the
functions i a, b and c.
What is the standard way to do that?
There is no standard way of doing that. There is immigrate of an old
Compojure version, which is a hack at best. If all functions should
end up in one namespace anyway, you can have a master file, which
basically loads the other files.
my/name/space.clj:
(ns my.name.space
(:load a b c))
my/name/{a,b,c}.clj:
(in-ns 'my.name.space)
Hope that helps.
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: Clojure Web Programming group?
+1 Neat idea. Starting a Google group Clojure web development might be a solution. Regards, Shantanu On Aug 18, 2:05 am, Rasmus Svensson r...@lysator.liu.se wrote: I think there's a lot of questions that a Clojure programmer faces when doing web programming, not only regarding how the libraries work, but also regarding how to design a larger-than-trivial web applications. A mail list would be a very good way to be able to ask for advice or to be inspired by solutions other people have come up with. I think there is a lack of articles and blog posts on the web where people write about the experiences they had during the development of their web applications. I always get the feeling that what I am struggling with, some else has already struggled with too and maybe even solved. During the time I've done web development, I've been searching for something like this. // Rasmus -- 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: Simple question about name-spaces
That helps a lot. Thank you very much.
That is not very nice though. I quite would like a :reexport option to use.
Best,
Nicolas.
On Wed, Aug 18, 2010 at 11:17 AM, Meikel Brandmeyer m...@kotka.de wrote:
There is no standard way of doing that. There is immigrate of an old
Compojure version, which is a hack at best. If all functions should
end up in one namespace anyway, you can have a master file, which
basically loads the other files.
my/name/space.clj:
(ns my.name.space
(:load a b c))
my/name/{a,b,c}.clj:
(in-ns 'my.name.space)
Hope that helps.
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: Clojure Web Programming group?
Great idea. I'm trying to figure out web development in Clojure atm and a group to specifically talk about this area would be great. On 18 August 2010 11:20, Shantanu Kumar kumar.shant...@gmail.com wrote: +1 Neat idea. Starting a Google group Clojure web development might be a solution. Regards, Shantanu On Aug 18, 2:05 am, Rasmus Svensson r...@lysator.liu.se wrote: I think there's a lot of questions that a Clojure programmer faces when doing web programming, not only regarding how the libraries work, but also regarding how to design a larger-than-trivial web applications. A mail list would be a very good way to be able to ask for advice or to be inspired by solutions other people have come up with. I think there is a lack of articles and blog posts on the web where people write about the experiences they had during the development of their web applications. I always get the feeling that what I am struggling with, some else has already struggled with too and maybe even solved. During the time I've done web development, I've been searching for something like this. // Rasmus -- 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.comclojure%2bunsubscr...@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: Simple question about name-spaces
Hi Nicolas,
I've done a bit of manipulation of namespaces for dynamic loading and
executing of functions in a web app context which might give you some
ideas...
Here ns-nm and ipath have been extracted from a url. Then...
(let [ .
ipath (if (or (nil? ipath) (= ipath )) root ipath)
ipath (if (.startsWith ipath /) (.substring ipath 1) ipath)
ns-sym (symbol ns-nm)
found-ns (find-ns ns-sym)
found-ns (if (nil? found-ns)
(let [n (create-ns ns-sym)]
(require ns-sym) n)
found-ns)
_ (when (nil? found-ns)
(throw (IllegalArgumentException.
(str Namespace not found for: ns-sym
req-fn (get (ns-publics ns-sym) (symbol ipath)) ]
(req-fn ...
So, the requisite functions you can use are;
create-ns
require
ns-publics
and you can role your own :).
-Hope that helps a bit, Adrian.
On Wed, Aug 18, 2010 at 12:24 PM, Nicolas Oury nicolas.o...@gmail.com wrote:
That helps a lot. Thank you very much.
That is not very nice though. I quite would like a :reexport option to use.
Best,
Nicolas.
On Wed, Aug 18, 2010 at 11:17 AM, Meikel Brandmeyer m...@kotka.de wrote:
There is no standard way of doing that. There is immigrate of an old
Compojure version, which is a hack at best. If all functions should
end up in one namespace anyway, you can have a master file, which
basically loads the other files.
my/name/space.clj:
(ns my.name.space
(:load a b c))
my/name/{a,b,c}.clj:
(in-ns 'my.name.space)
Hope that helps.
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
--
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: Simple question about name-spaces
If you intern all the ns-public variable of a namespace, they will be reexoprted? Will there be an indirection at runtime or the JVM can sort that out? -- 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: Emacs auto-complete plugin for slime users
I'm experiencing the exact same problem. Haven't found a way to fix this yet. On 17 Aug., 04:38, Stefan Kamphausen ska2...@googlemail.com wrote: Hi, just yesterday I took a first look at auto-complete together with your slime auto completion sources. I'm encountering some Exceptions, though, If I'm in a .clj-buffer and start typing (clojure. and then wait for the auto completion to popup I see a list of possible completions like, e.g., clojure.set, clojure.xml and more, and then an Exception pops up: clojure.set [Thrown class java.lang.ClassNotFoundException] Restarts: 0: [QUIT] Quit to the SLIME top level 1: [ABORT] ABORT to SLIME level 0 Backtrace: 0: java.net.URLClassLoader$1.run(URLClassLoader.java:202) 1: java.security.AccessController.doPrivileged(Native Method) 2: java.net.URLClassLoader.findClass(URLClassLoader.java:190) 3: clojure.lang.DynamicClassLoader.findClass(DynamicClassLoader.java: 58) 4: java.lang.ClassLoader.loadClass(ClassLoader.java:307) 5: java.lang.ClassLoader.loadClass(ClassLoader.java:248) 6: java.lang.Class.forName0(Native Method) 7: java.lang.Class.forName(Class.java:247) 8: clojure.lang.RT.classForName(RT.java:1566) 9: clojure.lang.Compiler.maybeResolveIn(Compiler.java:5700) 10: clojure.core$ns_resolve.invoke(core.clj:3380) 11: swank.commands.basic$describe_symbol_STAR_.invoke(basic.clj:184) 12: swank.commands.basic $eval880$documentation_symbol__881.invoke(basic.clj:201) 13: clojure.lang.Var.invoke(Var.java:365) 14: user$eval1927.invoke(NO_SOURCE_FILE) 15: clojure.lang.Compiler.eval(Compiler.java:5424) 16: clojure.lang.Compiler.eval(Compiler.java:5391) 17: clojure.core$eval.invoke(core.clj:2382) 18: swank.core$eval_in_emacs_package.invoke(core.clj:94) 19: swank.core$eval_for_emacs.invoke(core.clj:241) 20: clojure.lang.Var.invoke(Var.java:373) 21: clojure.lang.AFn.applyToHelper(AFn.java:169) 22: clojure.lang.Var.applyTo(Var.java:482) 23: clojure.core$apply.invoke(core.clj:540) 24: swank.core$eval_from_control.invoke(core.clj:101) 25: swank.core$sldb_loop$fn__401.invoke(core.clj:203) 26: swank.core$sldb_loop.invoke(core.clj:200) 27: swank.core$invoke_debugger.invoke(core.clj:216) 28: swank.core$sldb_debug.invoke(core.clj:220) 29: swank.core$eval_for_emacs.invoke(core.clj:279) 30: clojure.lang.Var.invoke(Var.java:373) 31: clojure.lang.AFn.applyToHelper(AFn.java:169) 32: clojure.lang.Var.applyTo(Var.java:482) 33: clojure.core$apply.invoke(core.clj:540) 34: swank.core$eval_from_control.invoke(core.clj:101) 35: swank.core$spawn_worker_thread$fn__455$fn__456.invoke(core.clj: 300) 36: clojure.lang.AFn.applyToHelper(AFn.java:159) 37: clojure.lang.AFn.applyTo(AFn.java:151) 38: clojure.core$apply.invoke(core.clj:540) 39: swank.core$spawn_worker_thread$fn__455.doInvoke(core.clj:296) 40: clojure.lang.RestFn.invoke(RestFn.java:398) 41: clojure.lang.AFn.run(AFn.java:24) 42: java.lang.Thread.run(Thread.java:619) Another one shows up if I hit TAB (bound to indent-for-tab-command) before the completion shows up I get a No message. [Thrown class java.lang.NullPointerException] Restarts: 0: [QUIT] Quit to the SLIME top level Backtrace: 0: clojure.lang.Compiler$FnMethod.parse(Compiler.java:4290) 1: clojure.lang.Compiler$FnExpr.parse(Compiler.java:3173) 2: clojure.lang.Compiler.analyzeSeq(Compiler.java:5367) 3: clojure.lang.Compiler.analyze(Compiler.java:5190) 4: clojure.lang.Compiler.analyze(Compiler.java:5151) 5: clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3057) 6: clojure.lang.Compiler.analyzeSeq(Compiler.java:5371) 7: clojure.lang.Compiler.analyze(Compiler.java:5190) 8: clojure.lang.Compiler.analyze(Compiler.java:5151) 9: clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:4670) 10: clojure.lang.Compiler$FnMethod.parse(Compiler.java:4328) 11: clojure.lang.Compiler$FnExpr.parse(Compiler.java:3173) 12: clojure.lang.Compiler.analyzeSeq(Compiler.java:5367) 13: clojure.lang.Compiler.analyze(Compiler.java:5190) 14: clojure.lang.Compiler.eval(Compiler.java:5421) 15: clojure.lang.Compiler.eval(Compiler.java:5391) 16: clojure.core$eval.invoke(core.clj:2382) 17: swank.core$eval_in_emacs_package.invoke(core.clj:94) 18: swank.core$eval_for_emacs.invoke(core.clj:241) 19: clojure.lang.Var.invoke(Var.java:373) 20: clojure.lang.AFn.applyToHelper(AFn.java:169) 21: clojure.lang.Var.applyTo(Var.java:482) 22: clojure.core$apply.invoke(core.clj:540) 23: swank.core$eval_from_control.invoke(core.clj:101) 24: swank.core$spawn_worker_thread$fn__455$fn__456.invoke(core.clj: 300) 25: clojure.lang.AFn.applyToHelper(AFn.java:159) 26: clojure.lang.AFn.applyTo(AFn.java:151) 27: clojure.core$apply.invoke(core.clj:540) 28: swank.core$spawn_worker_thread$fn__455.doInvoke(core.clj:296) 29: clojure.lang.RestFn.invoke(RestFn.java:398) 30: clojure.lang.AFn.run(AFn.java:24) 31:
Re: Nil Coalesce
On Aug 18, 2:42 am, Michael Wood esiot...@gmail.com wrote: nils replace nils when there are fewer substitutions than nil positions was one of the requirements. From the first post: If nil is encountered in the first sequence and the second sequence is exhaused, nil will be returned: e.g. user (nil-coalesce (nil 1 2 3 nil nil) (4 5)) (4 1 2 3 5 nil) _Returning_ nil is the requirement, which is what happens in the code I posted (it behaves the same as other submissions as far as I can tell). Replacing nil with nil in the result vector isn't necessary for that to happen. Justin -- 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: Emacs auto-complete plugin for slime users
On 18 Aug 2010, at 13:51, MHOOO wrote: I'm experiencing the exact same problem. Haven't found a way to fix this yet. I've fixed the problem in my fork of swank-clojure and requested that Phil pull the commit into the master repo: http://github.com/purcell/swank-clojure/commit/7172c275f390c59d0b532ec3dc2994b2b9f72167 -Steve On 17 Aug., 04:38, Stefan Kamphausen ska2...@googlemail.com wrote: Hi, just yesterday I took a first look at auto-complete together with your slime auto completion sources. I'm encountering some Exceptions, though, If I'm in a .clj-buffer and start typing (clojure. and then wait for the auto completion to popup I see a list of possible completions like, e.g., clojure.set, clojure.xml and more, and then an Exception pops up: clojure.set [Thrown class java.lang.ClassNotFoundException] Restarts: 0: [QUIT] Quit to the SLIME top level 1: [ABORT] ABORT to SLIME level 0 Backtrace: 0: java.net.URLClassLoader$1.run(URLClassLoader.java:202) 1: java.security.AccessController.doPrivileged(Native Method) 2: java.net.URLClassLoader.findClass(URLClassLoader.java:190) 3: clojure.lang.DynamicClassLoader.findClass(DynamicClassLoader.java: 58) 4: java.lang.ClassLoader.loadClass(ClassLoader.java:307) 5: java.lang.ClassLoader.loadClass(ClassLoader.java:248) 6: java.lang.Class.forName0(Native Method) 7: java.lang.Class.forName(Class.java:247) 8: clojure.lang.RT.classForName(RT.java:1566) 9: clojure.lang.Compiler.maybeResolveIn(Compiler.java:5700) 10: clojure.core$ns_resolve.invoke(core.clj:3380) 11: swank.commands.basic$describe_symbol_STAR_.invoke(basic.clj:184) 12: swank.commands.basic $eval880$documentation_symbol__881.invoke(basic.clj:201) 13: clojure.lang.Var.invoke(Var.java:365) 14: user$eval1927.invoke(NO_SOURCE_FILE) 15: clojure.lang.Compiler.eval(Compiler.java:5424) 16: clojure.lang.Compiler.eval(Compiler.java:5391) 17: clojure.core$eval.invoke(core.clj:2382) 18: swank.core$eval_in_emacs_package.invoke(core.clj:94) 19: swank.core$eval_for_emacs.invoke(core.clj:241) 20: clojure.lang.Var.invoke(Var.java:373) 21: clojure.lang.AFn.applyToHelper(AFn.java:169) 22: clojure.lang.Var.applyTo(Var.java:482) 23: clojure.core$apply.invoke(core.clj:540) 24: swank.core$eval_from_control.invoke(core.clj:101) 25: swank.core$sldb_loop$fn__401.invoke(core.clj:203) 26: swank.core$sldb_loop.invoke(core.clj:200) 27: swank.core$invoke_debugger.invoke(core.clj:216) 28: swank.core$sldb_debug.invoke(core.clj:220) 29: swank.core$eval_for_emacs.invoke(core.clj:279) 30: clojure.lang.Var.invoke(Var.java:373) 31: clojure.lang.AFn.applyToHelper(AFn.java:169) 32: clojure.lang.Var.applyTo(Var.java:482) 33: clojure.core$apply.invoke(core.clj:540) 34: swank.core$eval_from_control.invoke(core.clj:101) 35: swank.core$spawn_worker_thread$fn__455$fn__456.invoke(core.clj: 300) 36: clojure.lang.AFn.applyToHelper(AFn.java:159) 37: clojure.lang.AFn.applyTo(AFn.java:151) 38: clojure.core$apply.invoke(core.clj:540) 39: swank.core$spawn_worker_thread$fn__455.doInvoke(core.clj:296) 40: clojure.lang.RestFn.invoke(RestFn.java:398) 41: clojure.lang.AFn.run(AFn.java:24) 42: java.lang.Thread.run(Thread.java:619) Another one shows up if I hit TAB (bound to indent-for-tab-command) before the completion shows up I get a No message. [Thrown class java.lang.NullPointerException] Restarts: 0: [QUIT] Quit to the SLIME top level Backtrace: 0: clojure.lang.Compiler$FnMethod.parse(Compiler.java:4290) 1: clojure.lang.Compiler$FnExpr.parse(Compiler.java:3173) 2: clojure.lang.Compiler.analyzeSeq(Compiler.java:5367) 3: clojure.lang.Compiler.analyze(Compiler.java:5190) 4: clojure.lang.Compiler.analyze(Compiler.java:5151) 5: clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3057) 6: clojure.lang.Compiler.analyzeSeq(Compiler.java:5371) 7: clojure.lang.Compiler.analyze(Compiler.java:5190) 8: clojure.lang.Compiler.analyze(Compiler.java:5151) 9: clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:4670) 10: clojure.lang.Compiler$FnMethod.parse(Compiler.java:4328) 11: clojure.lang.Compiler$FnExpr.parse(Compiler.java:3173) 12: clojure.lang.Compiler.analyzeSeq(Compiler.java:5367) 13: clojure.lang.Compiler.analyze(Compiler.java:5190) 14: clojure.lang.Compiler.eval(Compiler.java:5421) 15: clojure.lang.Compiler.eval(Compiler.java:5391) 16: clojure.core$eval.invoke(core.clj:2382) 17: swank.core$eval_in_emacs_package.invoke(core.clj:94) 18: swank.core$eval_for_emacs.invoke(core.clj:241) 19: clojure.lang.Var.invoke(Var.java:373) 20: clojure.lang.AFn.applyToHelper(AFn.java:169) 21: clojure.lang.Var.applyTo(Var.java:482) 22: clojure.core$apply.invoke(core.clj:540) 23: swank.core$eval_from_control.invoke(core.clj:101) 24: swank.core$spawn_worker_thread$fn__455$fn__456.invoke(core.clj: 300) 25: clojure.lang.AFn.applyToHelper(AFn.java:159) 26:
accessing a mutable field outside of a deftype
This works
(deftype A [a])
(.a (A. 5))
This don't
(deftype A [^{:volatile-mutable true} a])
(.a (A. 5))
Is this normal? Is this a bug?
How could I access the field?
Best,
Nicolas.
--
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: accessing a mutable field outside of a deftype
On Wed, Aug 18, 2010 at 10:06 AM, Nicolas Oury nicolas.o...@gmail.comwrote:
This works
(deftype A [a])
(.a (A. 5))
This don't
(deftype A [^{:volatile-mutable true} a])
(.a (A. 5))
Is this normal? Is this a bug?
How could I access the field?
Best,
Nicolas.
It's not a bug. You need to define your own setters and getters.
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
Today's clojure trick question
Consider the following bit of code: (let [ x (new java.lang.Boolean false) ] (if x trouble ok)) As you might guess from the fact that I'm calling it's a trick question, the above code returns trouble, not ok. From experimentation, it looks like clojure's if takes the second branch if the value is nil or referentially equal to java.lang.Boolean/FALSE. If you have a boolean object which is not referentially equal to Boolean/FALSE, but still holds the value false, this is treated as true by Clojure. The problem is, I'm not 100% sure if this is a bug or not. The problem is nil-punning. The if statement can't rely on the test expression evaluating to a boolean. Which means to make this work correctly, if statements would have to do an instanceof test (to see if the object was a Boolean), then a cast and a call to .booleanValue to get the boolean value. Which is way more expensive than a quick nil test and referential equality test. This is, however, more than a little bit surprising and depressing. Somewhere, in my 10K lines of clojure code, boolean values are getting boxed in exactly that way. I've fixed the current problem (dropping in a call to .booleanValue in the test), but having if statements that can fail makes me paranoid. Brian -- 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: Today's clojure trick question
(defmacro fat-if) On Wed, Aug 18, 2010 at 4:09 PM, Brian Hurt bhur...@gmail.com wrote: Consider the following bit of code: (let [ x (new java.lang.Boolean false) ] (if x trouble ok)) As you might guess from the fact that I'm calling it's a trick question, the above code returns trouble, not ok. From experimentation, it looks like clojure's if takes the second branch if the value is nil or referentially equal to java.lang.Boolean/FALSE. If you have a boolean object which is not referentially equal to Boolean/FALSE, but still holds the value false, this is treated as true by Clojure. The problem is, I'm not 100% sure if this is a bug or not. The problem is nil-punning. The if statement can't rely on the test expression evaluating to a boolean. Which means to make this work correctly, if statements would have to do an instanceof test (to see if the object was a Boolean), then a cast and a call to .booleanValue to get the boolean value. Which is way more expensive than a quick nil test and referential equality test. This is, however, more than a little bit surprising and depressing. Somewhere, in my 10K lines of clojure code, boolean values are getting boxed in exactly that way. I've fixed the current problem (dropping in a call to .booleanValue in the test), but having if statements that can fail makes me paranoid. Brian -- 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: accessing a mutable field outside of a deftype
And they need to be in an interface first? -- 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: Today's clojure trick question
On Wed, Aug 18, 2010 at 11:09 AM, Brian Hurt bhur...@gmail.com wrote: This is, however, more than a little bit surprising and depressing. Somewhere, in my 10K lines of clojure code, boolean values are getting boxed in exactly that way. I've fixed the current problem (dropping in a call to .booleanValue in the test), but having if statements that can fail makes me paranoid. Brian Somewhere in your code you are creating boolean values instead of just using Clojure's true and false. Get rid of this code. 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: Simple question about name-spaces
Here's an approach that might work... ; app1.clj (ns app1) (defn myinc[x] (inc x)) (defn mydec[x] (dec x)) (defn .) ;app2.clj (ns app2) (defn mysq[x] (* x x)) then you have a mylib.clj which is your public user module; (ns mylib) (require 'app1 'app2) (defn exports[] (refer 'app1 :only '(myinc mydec)) ; for e.g (refer 'app2)) Then your users use it as follows; (require 'mylib) (mylib/exports) (myinc 2) 3 (mydec 1) 0 (mysq 2) 4 You could wrap the require/exports in a macro and pass in the ns-symbol. -Regards, Adrian On Wed, Aug 18, 2010 at 1:21 PM, Nicolas Oury nicolas.o...@gmail.com wrote: If you intern all the ns-public variable of a namespace, they will be reexoprted? Will there be an indirection at runtime or the JVM can sort that out? -- 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: Today's clojure trick question
On Wed, Aug 18, 2010 at 11:09 AM, Brian Hurt bhur...@gmail.com wrote: Consider the following bit of code: (let [ x (new java.lang.Boolean false) ] (if x trouble ok)) The Javadoc for Boolean has something to say on this subject[1] as does the following excerpt from Fogus' book The Joy of Clojure: Don't create Boolean objects It is possible to create an object that looks a lot like, but is not actually, `false`. Java has left a little landmine for you here, so take a moment to look at it so that you can step past it gingerly and get on with your life: (def evil-false (Boolean. false)) ; NEVER do this This creates a new instance of Boolean -- and that's already wrong! Since there are only two possible values of Boolean, an instance of each has already been made for you -- they're named `true` and `false`. But here you've gone and done it anyway, created a new instance of Boolean and stored it in a Var named `evil-false`. It looks like false: evil-false ;= false Sometimes it even acts like false: (= false evil-false) ;= true But once it gains your trust, it will show you just how wicked it is by acting like `true`: (if evil-false :truthy :falsey) ;= :truthy Java's own documentation warns against the creation of this evil thing, and now you've been warned again. If you just want to parse a string, use Boolean's static method instead of its constructor. This is the right way: (if (Boolean/valueOf false) :truthy :falsey) ;= :falsey --Chouser http://joyofclojure.com/ 1: http://download-llnw.oracle.com/javase/1.5.0/docs/api/java/lang/Boolean.html#Boolean%28boolean%29 -- 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: accessing a mutable field outside of a deftype
And is the one that works (for non-mutable fields) reliable or just an implementation accident that could change in the future? On Wed, Aug 18, 2010 at 4:27 PM, Nicolas Oury nicolas.o...@gmail.com wrote: And they need to be in an interface first? -- 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
Multi-field sorting: juxt and sort-by
This is a helpful hint, and probably one that others are already using, but seemed good to share. If you're sorting a list of maps on one field, you can use (sort-by :community list-of-residents) But sorting on two (or more) fields seems to require a little more coding: (sort-by :community (sort-by :last-name list-of-residents)) or (sort-by #(vector (:community %) (:last-name %)) list-of- residents) But the latter version is equivalent to the terser (sort-by (juxt :community :last-name) list-of-residents) The juxt function takes functions as an argument (and this includes function equivalents like keywords) and returns a function that generates a vector by applying each function in order. (Not clear enough? Well, from the docstring for juxt: Takes a set of functions and returns a fn that is the juxtaposition of those fns. The returned fn takes a variable number of args, and returns a vector containing the result of applying each fn to the args (left-to- right). Anyway, the resulting code for sort-by is terse and clear (even if the reader is not sure about juxt, the prominent key-fields may give the correct idea). Thanks for your patience, ron -- 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: accessing a mutable field outside of a deftype
On Wed, Aug 18, 2010 at 11:41 AM, Nicolas Oury nicolas.o...@gmail.comwrote: And is the one that works (for non-mutable fields) reliable or just an implementation accident that could change in the future? I'm assuming it's reliable for 1.2.0. -- 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: Today's clojure trick question
On Wed, Aug 18, 2010 at 11:34 AM, David Nolen dnolen.li...@gmail.comwrote: On Wed, Aug 18, 2010 at 11:09 AM, Brian Hurt bhur...@gmail.com wrote: This is, however, more than a little bit surprising and depressing. Somewhere, in my 10K lines of clojure code, boolean values are getting boxed in exactly that way. I've fixed the current problem (dropping in a call to .booleanValue in the test), but having if statements that can fail makes me paranoid. Brian Somewhere in your code you are creating boolean values instead of just using Clojure's true and false. Get rid of this code. For the record, no where in my code am I deliberately creating Boolean objects. Why the hell would I write (new java.lang.Boolean false) when I can just as easily write false? And I have looked through the code to see if something stupid like that did sneak in, and didn't find anything. So this means what is happening is the values are being boxed because of some subtle interaction I haven't tracked down yet. Could it be something to do with Java's serialization? Or maybe the way Clojure boxes boolean values? I don't know. So unless you have some information on what I could be doing wrong, simply going don't do that does not help. Brian -- 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
What is the reason Lisp code is not written with closing parenthesis on new lines?
Wouldn't that make it easier to keep track of them. Example: (defn myfn-a [a b] (if (zero? b) a (recur (afn (bfn (...)) a) (dec b (defn myfn-b [a b] (if (zero? b) a (recur (afn (bfn (...)) a) (dec b) ) ) ) -- 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
Wrong package name of record classes
Hi, I noticed that when I define a record (using defrecord) in a namespace having hyphen in its name (like abc.d-ef) and compile the clj file using AOT, a class file corresponding to the record defined is created in the package with the name same as the namespace it is defined in, with hyphen (in this case abc.d-ef) whereas everything else goes in the package with the name of the namespace with hyphens replaced by underscore (in this case abc.d_ef). This seems like a bug to me. Just wanted to confirm here before reporting. Cheers, Abhinav -- 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: defprotocol not working?
Ok, thanks for the answer. I actually have Leiningen installed, and I've just done a lein update - it's now on 1.2.0 as it says. Is this actually clojure 1.2.0, or just a stand-alone leiningen version? But I'm in the progress of just learning, so I don't want to have projects (yet). Because of that I installed clojure-1.1.jar (and clojure-contrib) manually, and found a clj shell script to run. I updated it to support clojure 1.1, and now when I want a REPL I type clj. When I want to run a script file, I type clj scriptfilename.clj. It's very simple, and pretty much resembles what I know from languages such as ruby (irb). Is there any way to use leiningen in this way - using it just for REPL and running test-scripts with simple command lines, not having to create projects (yet)? Thanks in advance! _henrik On Aug 17, 3:46 pm, Nicolas Oury nicolas.o...@gmail.com wrote: defprotocol is a new feature of Clojure 1.2. A fantastic RC3 of this fantastic software is available. A good way to get it is to use the amazing Leiningen. On Tue, Aug 17, 2010 at 7:17 AM, Henrik Mohr lupos...@gmail.com wrote: Hi there! I'm a completely new newbie in the clojure sphere - old dog in Java and a handful of other languages. But Clojure is my first (new) functional language, and I'm very excited about it - complements on your word Rich et. al.! :-) To learn clojure I've started with the (beta) book Seven Languages in Seven Weeks by Bruce Tate (pragprog.com) - great book by the way. He's got a section called defrecord and protocols where he's got this example: (ns tate.compass) (defprotocol Compass (direction [c]) (left [c]) (right [c])) The problem for me is this: When I run the code I get this error message from the REPL: java.lang.Exception: Unable to resolve symbol: defprotocol in this context (NO_SOURCE_FILE:4) I'm using the stable version of clojure 1.1 and clojure contrib 1.1. I'm on OSX 10.6.4 and Apple JDK 1.6.0_20-b02-279-10M3065. Please help! I'm stuck, and I don't want to procede (for too long) until I figure out why I get this error ;) Thanks in advance. Kind regards, Henrik Mohr -- 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
cool compiler-project?
Hi, I am a post-grad student looking for a cool compiler - project to do. I am getting comfortable with clojure and would really like to help Ideas anyone? or, Is there a to-do list where can i start? Cheers Sreeraj -- 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: What is the reason Lisp code is not written with closing parenthesis on new lines?
On Wed, Aug 18, 2010 at 2:09 AM, michele michelemen...@gmail.com wrote: Wouldn't that make it easier to keep track of them. It would make it easier for people to keep track of them. However, keeping track of parentheses is not something people should be doing since it's menial, repetitive, error-prone work. Computer programs are much better at tasks like that. -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: Nil Coalesce
My take is almost identical but I used the same length arguments for the collections which means that the difference in the if branch are easier to spot, at the cost of more cryptic argument names. This version will not blow the stack, and its easy to wrap in lazy-seq. (defn nil-coalesce [s1 s2] (if (seq s1) (if (first s1) (cons (first s1) (nil-coalesce (rest s1) s2)) (cons (first s2) (nil-coalesce (rest s1) (rest s2)) On 17 Aug, 15:07, Meikel Brandmeyer m...@kotka.de wrote: Yeah! Golf! user= (defn nil-coalesce [coll replacements] (lazy-seq (when-let [s (seq coll)] (let [fst (first s)] (if (nil? fst) (cons (first replacements) (nil-coalesce (rest s) (rest replacements))) (cons fst (nil-coalesce (rest s) replacements))) #'user/nil-coalesce user= (nil-coalesce [nil 1 2 3 nil nil] [4 5]) (4 1 2 3 5 nil) 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: Today's clojure trick question
On Wed, Aug 18, 2010 at 11:09 AM, Brian Hurt bhur...@gmail.com wrote: Consider the following bit of code: (let [ x (new java.lang.Boolean false) ] (if x trouble ok)) I consider the fact that Boolean has a public constructor a bug. It can only ever represent 2 values. However, if you do (let [x (java.lang.Boolean/getBoolean false)] (if x :trouble :ok)) you're fine, which obviously isn't helpful in your situation. As you might guess from the fact that I'm calling it's a trick question, the above code returns trouble, not ok. From experimentation, it looks like clojure's if takes the second branch if the value is nil or referentially equal to java.lang.Boolean/FALSE. If you have a boolean object which is not referentially equal to Boolean/FALSE, but still holds the value false, this is treated as true by Clojure. The problem is, I'm not 100% sure if this is a bug or not. The problem is nil-punning. The if statement can't rely on the test expression evaluating to a boolean. Which means to make this work correctly, if statements would have to do an instanceof test (to see if the object was a Boolean), then a cast and a call to .booleanValue to get the boolean value. Which is way more expensive than a quick nil test and referential equality test. This is, however, more than a little bit surprising and depressing. Somewhere, in my 10K lines of clojure code, boolean values are getting boxed in exactly that way. I've fixed the current problem (dropping in a call to .booleanValue in the test), but having if statements that can fail makes me paranoid. Brian -- 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 -- http://www.apgwoz.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: Today's clojure trick question
On Wed, Aug 18, 2010 at 11:58 AM, Brian Hurt bhur...@gmail.com wrote: For the record, no where in my code am I deliberately creating Boolean objects. Why the hell would I write (new java.lang.Boolean false) when I can just as easily write false? And I have looked through the code to see if something stupid like that did sneak in, and didn't find anything. So this means what is happening is the values are being boxed because of some subtle interaction I haven't tracked down yet. Could it be something to do with Java's serialization? Or maybe the way Clojure boxes boolean values? I don't know. So unless you have some information on what I could be doing wrong, simply going don't do that does not help. Brian Boxing has nothing to do with it. (let [x ((fn [] false))] (if x trouble ok)) ; ok Somewhere new Boolean values are being constructed. Are you using an external Java library that might be doing this? -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Today's clojure trick question
I am not an expert. Is it possible on some JDK to put a breakpoint on Boolean constructor and look at the stack? Or you can't put a breakpoint on standard library? -- 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: Today's clojure trick question
No, you can put a breakpoint on any class, regardless of where it's been loaded from. In this case, I'd suggest not relying on the line numbers shown in source dumps. At least in my experience, line numbers in the standard library source differ from what is shown at runtime. All three Java IDEs allow you to set breakpoints on specific classes and methods, irrespective of line number -- doing that will allow you to set the right breakpoint, if the line number in Booleaninit(boolean) happens to mismatch whichever source tree you have wired into the IDE. - Chas On Aug 18, 12:57 pm, Nicolas Oury nicolas.o...@gmail.com wrote: I am not an expert. Is it possible on some JDK to put a breakpoint on Boolean constructor and look at the stack? Or you can't put a breakpoint on standard library? -- 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: What is the reason Lisp code is not written with closing parenthesis on new lines?
On Wed, Aug 18, 2010 at 2:09 AM, michele michelemen...@gmail.com wrote: (defn myfn-b [a b] (if (zero? b) a (recur (afn (bfn (...)) a) (dec b) ) ) ) I started out trying to do that but it ended up being far more work that it was worth - as Phil said, computer programs (IDEs / editors) do this much better. If you're using an IDE that auto-closes / auto-deletes forms, you really don't need to think about parentheses at all. -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ If you're not annoying somebody, you're not really alive. -- Margaret Atwood -- 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: Nil Coalesce
I have a solution : (defn unfold [f as] (if-let [[hd new-as] (apply f as)] (lazy-seq (cons hd (apply unfold f new-as))) ())) unfold could be called co-reduce or coreduce. It is the dual operation of reduce, in category theory. Instead of reducing a seq to create a value, it generates a seq from a value. (generate is sometimes a name for that, too) I don't know if it is somewhere in core or contrib. With this function, it is very simple: (defn nil-coalesce [s1 s2] (unfold #(and %1 (if (first %1) [(first %1) [(next %1) %2]] [(first %2) [(next %1) (next %2)]])) s1 s2)) -- 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 Web Programming group?
its a good idea, so here it is: Congratulations: you've successfully created your Google Group, Clojure Web Development. Here are the essentials: * Group name: Clojure Web Development * Group home page: http://groups.google.com/group/clojure-web-dev * Group email address clojure-web-...@googlegroups.com feel free to sign up and all archives will be publicly available thanks, marc On Wed, Aug 18, 2010 at 6:38 AM, Chris Jenkins cdpjenk...@gmail.com wrote: Great idea. I'm trying to figure out web development in Clojure atm and a group to specifically talk about this area would be great. On 18 August 2010 11:20, Shantanu Kumar kumar.shant...@gmail.com wrote: +1 Neat idea. Starting a Google group Clojure web development might be a solution. Regards, Shantanu On Aug 18, 2:05 am, Rasmus Svensson r...@lysator.liu.se wrote: I think there's a lot of questions that a Clojure programmer faces when doing web programming, not only regarding how the libraries work, but also regarding how to design a larger-than-trivial web applications. A mail list would be a very good way to be able to ask for advice or to be inspired by solutions other people have come up with. I think there is a lack of articles and blog posts on the web where people write about the experiences they had during the development of their web applications. I always get the feeling that what I am struggling with, some else has already struggled with too and maybe even solved. During the time I've done web development, I've been searching for something like this. // Rasmus -- 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 -- Freedom is nothing but a chance to be better. --Albert Camus The problem with socialism is that eventually you run out of other people's money. --Margaret Thatcher -- 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: What is the reason Lisp code is not written with closing parenthesis on new lines?
auto-indentation and parens highlighting are better than lines with only one parens. At least for me. There is no law. Do what is best for you. You might, or not, change your mind when you have more practice with all those parens. -- 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: Today's clojure trick question
Would suggest to consider this: (let [ x (true? (new java.lang.Boolean false)) ] (if x trouble ok)) Regards, Shantanu On Aug 18, 10:05 pm, Chas Emerick cemer...@snowtide.com wrote: No, you can put a breakpoint on any class, regardless of where it's been loaded from. In this case, I'd suggest not relying on the line numbers shown in source dumps. At least in my experience, line numbers in the standard library source differ from what is shown at runtime. All three Java IDEs allow you to set breakpoints on specific classes and methods, irrespective of line number -- doing that will allow you to set the right breakpoint, if the line number in Booleaninit(boolean) happens to mismatch whichever source tree you have wired into the IDE. - Chas On Aug 18, 12:57 pm, Nicolas Oury nicolas.o...@gmail.com wrote: I am not an expert. Is it possible on some JDK to put a breakpoint on Boolean constructor and look at the stack? Or you can't put a breakpoint on standard library? -- 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: What is the reason Lisp code is not written with closing parenthesis on new lines?
On Wed, Aug 18, 2010 at 1:11 PM, Sean Corfield seancorfi...@gmail.com wrote: On Wed, Aug 18, 2010 at 2:09 AM, michele michelemen...@gmail.com wrote: (defn myfn-b [a b] (if (zero? b) a (recur (afn (bfn (...)) a) (dec b) ) ) ) I started out trying to do that but it ended up being far more work that it was worth - as Phil said, computer programs (IDEs / editors) do this much better. If you're using an IDE that auto-closes / auto-deletes forms, you really don't need to think about parentheses at all. -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ Also it adds up, you end up seeing much less code on your screen that way. marc -- Freedom is nothing but a chance to be better. --Albert Camus The problem with socialism is that eventually you run out of other people's money. --Margaret Thatcher -- 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: What is the reason Lisp code is not written with closing parenthesis on new lines?
Putting them on separate lines put the focus on the wrong element of the code. You do not want to be focusing on the parentheses, you want to be focusing on the structure of the code. The idiomatic lisp formatting style uses indentation to reveal the large scale structure of the code, and so the parentheses can be neatly tucked away. With a little experience, the parentheses will start to fade from view. Additionally, putting them on separate lines waste vertical space, and you should be using an editor that supports paren matching so you don't need to count them. -- 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: Today's clojure trick question
On Wed, Aug 18, 2010 at 10:28 AM, Shantanu Kumar kumar.shant...@gmail.com wrote: Would suggest to consider this: (let [ x (true? (new java.lang.Boolean false)) ] (if x trouble ok)) Ah, but that wouldn't work for a new Boolean set to true: (let [ x (true? (new java.lang.Boolean true)) ] (if x ok trouble)) Expect ok? Nope, you'll get trouble. -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ If you're not annoying somebody, you're not really alive. -- Margaret Atwood -- 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: defprotocol not working?
You can create a new project, even if you don't use it: lein new experiments inside it will create a project.clj. Checks the dependencies look like that: :dependencies [[org.clojure/clojure 1.2.0-RC3] [org.clojure/clojure-contrib 1.2.0-RC3] Type lein deps in the directory. It will download the latest version of clojure. lein repl, will open a repl. You can also have a look to the cljr project http://github.com/liebke/cljr It is intended for repl-based project. Hopes that helps. On Wed, Aug 18, 2010 at 12:29 PM, Henrik Mohr lupos...@gmail.com wrote: updated it to support clojure 1.1, and now when I want a REPL I type -- 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: Emacs auto-complete plugin for slime users
I can get rid of those errors by evaling this in the repl. Does this
work for you as well?:
(do
(require 'clojure.contrib.with-ns)
(clojure.contrib.with-ns/with-ns
'swank.commands.basic
(defn- describe-to-string [var]
{:pre [(var? var)]}
(with-out-str
(print-doc var)))
(defn- describe-symbol* [symbol-name]
(with-emacs-package
(let [v (try (ns-resolve (maybe-ns *current-package*) (symbol
symbol-name))
(catch ClassNotFoundException e
nil))]
(if (and v (var? v))
(describe-to-string v)
(str Unknown symbol symbol-name)))
On Aug 17, 10:38 am, Stefan Kamphausen ska2...@googlemail.com wrote:
Hi,
just yesterday I took a first look at auto-complete together with your
slime auto completion sources.
I'm encountering some Exceptions, though,
If I'm in a .clj-buffer and start typing
(clojure.
and then wait for the auto completion to popup I see a list of
possible completions like, e.g., clojure.set, clojure.xml and more,
and then an Exception pops up:
clojure.set
[Thrown class java.lang.ClassNotFoundException]
Restarts:
0: [QUIT] Quit to the SLIME top level
1: [ABORT] ABORT to SLIME level 0
Backtrace:
0: java.net.URLClassLoader$1.run(URLClassLoader.java:202)
1: java.security.AccessController.doPrivileged(Native Method)
2: java.net.URLClassLoader.findClass(URLClassLoader.java:190)
3: clojure.lang.DynamicClassLoader.findClass(DynamicClassLoader.java:
58)
4: java.lang.ClassLoader.loadClass(ClassLoader.java:307)
5: java.lang.ClassLoader.loadClass(ClassLoader.java:248)
6: java.lang.Class.forName0(Native Method)
7: java.lang.Class.forName(Class.java:247)
8: clojure.lang.RT.classForName(RT.java:1566)
9: clojure.lang.Compiler.maybeResolveIn(Compiler.java:5700)
10: clojure.core$ns_resolve.invoke(core.clj:3380)
11: swank.commands.basic$describe_symbol_STAR_.invoke(basic.clj:184)
12: swank.commands.basic
$eval880$documentation_symbol__881.invoke(basic.clj:201)
13: clojure.lang.Var.invoke(Var.java:365)
14: user$eval1927.invoke(NO_SOURCE_FILE)
15: clojure.lang.Compiler.eval(Compiler.java:5424)
16: clojure.lang.Compiler.eval(Compiler.java:5391)
17: clojure.core$eval.invoke(core.clj:2382)
18: swank.core$eval_in_emacs_package.invoke(core.clj:94)
19: swank.core$eval_for_emacs.invoke(core.clj:241)
20: clojure.lang.Var.invoke(Var.java:373)
21: clojure.lang.AFn.applyToHelper(AFn.java:169)
22: clojure.lang.Var.applyTo(Var.java:482)
23: clojure.core$apply.invoke(core.clj:540)
24: swank.core$eval_from_control.invoke(core.clj:101)
25: swank.core$sldb_loop$fn__401.invoke(core.clj:203)
26: swank.core$sldb_loop.invoke(core.clj:200)
27: swank.core$invoke_debugger.invoke(core.clj:216)
28: swank.core$sldb_debug.invoke(core.clj:220)
29: swank.core$eval_for_emacs.invoke(core.clj:279)
30: clojure.lang.Var.invoke(Var.java:373)
31: clojure.lang.AFn.applyToHelper(AFn.java:169)
32: clojure.lang.Var.applyTo(Var.java:482)
33: clojure.core$apply.invoke(core.clj:540)
34: swank.core$eval_from_control.invoke(core.clj:101)
35: swank.core$spawn_worker_thread$fn__455$fn__456.invoke(core.clj:
300)
36: clojure.lang.AFn.applyToHelper(AFn.java:159)
37: clojure.lang.AFn.applyTo(AFn.java:151)
38: clojure.core$apply.invoke(core.clj:540)
39: swank.core$spawn_worker_thread$fn__455.doInvoke(core.clj:296)
40: clojure.lang.RestFn.invoke(RestFn.java:398)
41: clojure.lang.AFn.run(AFn.java:24)
42: java.lang.Thread.run(Thread.java:619)
Another one shows up if I hit TAB (bound to indent-for-tab-command)
before the completion shows up I get a
No message.
[Thrown class java.lang.NullPointerException]
Restarts:
0: [QUIT] Quit to the SLIME top level
Backtrace:
0: clojure.lang.Compiler$FnMethod.parse(Compiler.java:4290)
1: clojure.lang.Compiler$FnExpr.parse(Compiler.java:3173)
2: clojure.lang.Compiler.analyzeSeq(Compiler.java:5367)
3: clojure.lang.Compiler.analyze(Compiler.java:5190)
4: clojure.lang.Compiler.analyze(Compiler.java:5151)
5: clojure.lang.Compiler$InvokeExpr.parse(Compiler.java:3057)
6: clojure.lang.Compiler.analyzeSeq(Compiler.java:5371)
7: clojure.lang.Compiler.analyze(Compiler.java:5190)
8: clojure.lang.Compiler.analyze(Compiler.java:5151)
9: clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:4670)
10: clojure.lang.Compiler$FnMethod.parse(Compiler.java:4328)
11: clojure.lang.Compiler$FnExpr.parse(Compiler.java:3173)
12: clojure.lang.Compiler.analyzeSeq(Compiler.java:5367)
13: clojure.lang.Compiler.analyze(Compiler.java:5190)
14: clojure.lang.Compiler.eval(Compiler.java:5421)
15: clojure.lang.Compiler.eval(Compiler.java:5391)
16: clojure.core$eval.invoke(core.clj:2382)
17: swank.core$eval_in_emacs_package.invoke(core.clj:94)
18: swank.core$eval_for_emacs.invoke(core.clj:241)
19: clojure.lang.Var.invoke(Var.java:373)
20:
Re: What is the reason Lisp code is not written with closing parenthesis on new lines?
On 8/18/10 1:32 PM, Brian Goslinga wrote: Putting them on separate lines put the focus on the wrong element of the code. You do not want to be focusing on the parentheses, you want to be focusing on the structure of the code. The idiomatic lisp formatting style uses indentation to reveal the large scale structure of the code, and so the parentheses can be neatly tucked away. With a little experience, the parentheses will start to fade from view. Additionally, putting them on separate lines waste vertical space, and you should be using an editor that supports paren matching so you don't need to count them. Generally, when I am working on a function, I will put the closing parens anywhere with a ton of whitespace all around. Once I'm done with the function, I make sure to delete all of the excess breaks so that it's a nice neat block of code. Using paredit in emacs makes it really easy to handle the closing parens. I'm sure there are other good tools for the other editors. signature.asc Description: OpenPGP digital signature
Re: What is the reason Lisp code is not written with closing parenthesis on new lines?
Three reasons. First, code density, that is the number of (/ number-of-lines-of-code number-of-lines-on-screen) should approach 1 so that every line on the screen is code. Second, real editors paren-bounce to show matching parens. Third, real lispers don't exit the thought process until the s-expression is complete :-) Tim Daly michele wrote: Wouldn't that make it easier to keep track of them. Example: (defn myfn-a [a b] (if (zero? b) a (recur (afn (bfn (...)) a) (dec b (defn myfn-b [a b] (if (zero? b) a (recur (afn (bfn (...)) a) (dec b) ) ) ) -- 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: What is the reason Lisp code is not written with closing parenthesis on new lines?
It's almost purely community convention that has been adopted from Lisp. You may be interested in this link: http://gregslepak.posterous.com/on-lisps-readability There is much discussion about this topic there. Cheers, Greg On Aug 18, 2010, at 2:09 AM, michele wrote: Wouldn't that make it easier to keep track of them. Example: (defn myfn-a [a b] (if (zero? b) a (recur (afn (bfn (...)) a) (dec b (defn myfn-b [a b] (if (zero? b) a (recur (afn (bfn (...)) a) (dec b) ) ) ) -- 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: SQLRat - A Clojure 1.2 library to access Relational Databases using DataTypes
Hi, I have uploaded source code (Apache 2 license) for SQLRat - a library for Clojure 1.2 to access relational databases using DataTypes (entities). It also lets you define relations between entities and navigate them. While this is a part of what typically Object- Relational Mapping (ORM) frameworks do, it is not an ORM framework per se -- it does not implement State managent, Identity management, Lazy loading, Eager fetching etc. The code is quite rough around the edges right now and beta-quality at best (at 0.1-SNAPSHOT), but it works nevertheless. I intend to release it as GA soon after Clojure 1.2 goes GA too. The source code is here: http://bitbucket.org/kumarshantanu/sqlrat/ Discussions can be posted here: http://groups.google.com/group/bitumenframework You may also like to keep a tab at this: http://code.google.com/p/bitumenframework/ The intent of this announcement is to gather feedback, so that I can fix as many warts as I can before doing a 0.1 GA release. It is not on Clojars yet, but the GA will eventually be there. The most important parts to review would be the API it exposes, followed by the implementation details. So, I would request you to give the library a try, ask questions (I would be happy to answer), give feedback, make suggestions and if you can, fork and contribute as well. The usage can be found in the dbblog.clj file, which contains the unit tests and describes how the library can be used. Regards, Shantanu -- 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: What is the reason Lisp code is not written with closing parenthesis on new lines?
The indentation is enough of a hint to get it right. For example, in myfn-a, because you've indented it correctly I can easily tell that (dec b) is the second argument to recur, without looking at the parentheses at all. Isolating close-parens would probably help a little with this task, but the loss of screen real estate would far outweigh the gains. Without the indentation to help, indeed we would be lost in a sea of parens and it might be necessary to put one on each line; but as Phil points out, computers are better at that than we are, so we can leave the parentheses as an implementation detail and work on top of the indentation-based abstraction emacs (or whatever IDE) offers us. On Aug 18, 2:09 am, michele michelemen...@gmail.com wrote: Wouldn't that make it easier to keep track of them. Example: (defn myfn-a [a b] (if (zero? b) a (recur (afn (bfn (...)) a) (dec b (defn myfn-b [a b] (if (zero? b) a (recur (afn (bfn (...)) a) (dec b) ) ) ) -- 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: Today's clojure trick question
All~ Boolean.valueOf() was added in 1.4. While that seems ancient, some older libraries use 'new Boolean()' because they maintain 1.2 compatibility. It seems like Clojure should take more care when it unboxes Booleans... Matt On Wed, Aug 18, 2010 at 12:57 PM, Nicolas Oury nicolas.o...@gmail.comwrote: I am not an expert. Is it possible on some JDK to put a breakpoint on Boolean constructor and look at the stack? Or you can't put a breakpoint on standard library? -- 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.comclojure%2bunsubscr...@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: What is the reason Lisp code is not written with closing parenthesis on new lines?
On Aug 18, 2010, at 1:38 PM, Greg wrote: http://gregslepak.posterous.com/on-lisps-readability That article is dishonest. The author changes indentation widths between examples, while focusing entirely on the trailing-parens. He claims in a comment that the post is not solely about trailing parenthesis, but there's only one passing remark about 2-space indentation in the whole article. (I personally use 4-space indents precisely because they make code easy to parse at a glance.) -- 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: What is the reason Lisp code is not written with closing parenthesis on new lines?
On Aug 18, 2010, at 12:07 PM, Michael Gardner wrote: On Aug 18, 2010, at 1:38 PM, Greg wrote: http://gregslepak.posterous.com/on-lisps-readability That article is dishonest. Speaking as the author, I'm a bit offended. Yes, the indentation width was changed, and this was acknowledged both in the post and in the comments, but you seem to conveniently ignore everything else that was said. Increasing the default indentation width does improve readability, but readability is still further improved by trailing parens, for the multitude of reasons the article mentions. - Greg The author changes indentation widths between examples, while focusing entirely on the trailing-parens. He claims in a comment that the post is not solely about trailing parenthesis, but there's only one passing remark about 2-space indentation in the whole article. (I personally use 4-space indents precisely because they make code easy to parse at a glance.) -- 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: Today's clojure trick question
I don't see what the concern may be. Can you elaborate? On Aug 18, 10:04 am, Matt Fowles matt.fow...@gmail.com wrote: All~ Boolean.valueOf() was added in 1.4. While that seems ancient, some older libraries use 'new Boolean()' because they maintain 1.2 compatibility. It seems like Clojure should take more care when it unboxes Booleans... Matt On Wed, Aug 18, 2010 at 12:57 PM, Nicolas Oury nicolas.o...@gmail.comwrote: I am not an expert. Is it possible on some JDK to put a breakpoint on Boolean constructor and look at the stack? Or you can't put a breakpoint on standard library? -- 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.comclojure%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en- Hide quoted text - - Show quoted text - -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: What is the reason Lisp code is not written with closing parenthesis on new lines?
A more serious answer is that when I code in Java I use the brace-on-a-line kind of indentation. When I code in Lisp I never write single-line parens of any kind. I find that I think differently in each language. My Java code is always a pile of declare-this, do-this, do-this, return Thus I find that I'm delimiting the scope of my variables, marking my control flow and branching logic, try/catch logic, class boundaries, etc. My Lisp code mixes control flow and data structures in the same syntax. Thus the idea that parens are some kind of control flow delimiter is not particularly meaningful. To see the alternative case, take a Java program, find every function call such as: MyFactory(somearg); throw away the ';', and move the paren left to get: (MyFactory somearg) Now the question you're asking is, why don't lispers write (MyFactory somearg ) which makes me cringe. A second reason is that Lisp allows you to think things that Java does not. Java has this imperative, object-oriented, hierarchical style of writing. My lisp code sytle varies to fit the problem. Sometimes it is imperative, sometimes functional, sometimes OO, sometimes snobol-like pattern matching, sometimes class-based. Occasionally I dynamically construct the code and execute it inline. Or I use macros to create my own problem language and code in that. And I create my data structures on the fly inline to the code. Once you really internalize lisp there are no real constraints on what you think or write. Thus there is no question of bracing style that is meaningful. The whole idea of bracing style is Java-think. Your language choice has given you an OO-procedural mindset. So when you reach for Lisp you want to see what you have come to expect. People who work with bricks (Java) tend to wonder why they don't find bricks among people who work with modelling clay (Lisp). The answer isn't in the material, it is in your mindset. Just by looking at lisp code I can tell what your native language is. Fortran programmers simulate COMMON blocks, C programmers use things as pointers, etc. You can write Fortran in any language is a famous quote but you can't write Lisp in any language. And you can quote me on that. (But only in my obituary :-) ) In fact, I think that this is going to be the hardest barrier to the adoption of Clojure. Real Java Programmers are not going to like the bracing style (or lack thereof) in Clojure. Tim Daly Greg wrote: It's almost purely community convention that has been adopted from Lisp. You may be interested in this link: http://gregslepak.posterous.com/on-lisps-readability There is much discussion about this topic there. Cheers, Greg On Aug 18, 2010, at 2:09 AM, michele wrote: Wouldn't that make it easier to keep track of them. Example: (defn myfn-a [a b] (if (zero? b) a (recur (afn (bfn (...)) a) (dec b (defn myfn-b [a b] (if (zero? b) a (recur (afn (bfn (...)) a) (dec b) ) ) ) -- 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: What is the reason Lisp code is not written with closing parenthesis on new lines?
On Aug 18, 2010, at 2:49 PM, Greg wrote: On Aug 18, 2010, at 12:07 PM, Michael Gardner wrote: On Aug 18, 2010, at 1:38 PM, Greg wrote: http://gregslepak.posterous.com/on-lisps-readability That article is dishonest. Speaking as the author, I'm a bit offended. Too bad. If you wanted to focus on the trailing-parens (which you clearly did in that article), you should have kept everything else the same between your examples. If you wanted to comment on indentation as well, you should have (a) given it equal prominence in your discussion, (b) used separate code examples for trailing-parens vs indentation, and/or (c) made a separate post. Closing the comments after people started to question you on this wasn't a good move, either (otherwise I'd be commenting there rather than here). -- 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: What is the reason Lisp code is not written with closing parenthesis on new lines?
I should qualify my response though to say that I am not advocating that everyone switch their preferred style of code. Just simply giving reasons for why some prefer one style over another. It's a personal thing, and I do not wish to engage in a flame war over it. Best, Greg On Aug 18, 2010, at 1:36 PM, Greg wrote: Now the question you're asking is, why don't lispers write (MyFactory somearg ) which makes me cringe. That's not at all what's being suggested -- you'll find that both in the OP's code and in the link below, there are many locations where closing parenthesis are ended on the same line. Trailing parens are placed only for certain blocks that traditionally would define a scope in another language, and this is convenient for many reasons, including generic reasons not attached to any specific language. It's not about carrying over much loved C style to Lisp, but to make actual use of parenthesis for the purpose of clearly outlining the structure of your code. Again, the link goes much more into depth on this. Attached is a screenshot of some code from the wonderful Incanter library. I think it's a great illustration of how confusing stacking parenthesis can be (there are many functions in there that are like this). The readability issue occurs when there's a drop in several indentation levels after many lines. This is a problem regardless of what the indentation width is, but is certainly made worse by a small indentation width. - Greg On Aug 18, 2010, at 1:17 PM, Tim Daly wrote: A more serious answer is that when I code in Java I use the brace-on-a-line kind of indentation. When I code in Lisp I never write single-line parens of any kind. I find that I think differently in each language. My Java code is always a pile of declare-this, do-this, do-this, return Thus I find that I'm delimiting the scope of my variables, marking my control flow and branching logic, try/catch logic, class boundaries, etc. My Lisp code mixes control flow and data structures in the same syntax. Thus the idea that parens are some kind of control flow delimiter is not particularly meaningful. To see the alternative case, take a Java program, find every function call such as: MyFactory(somearg); throw away the ';', and move the paren left to get: (MyFactory somearg) Now the question you're asking is, why don't lispers write (MyFactory somearg ) which makes me cringe. A second reason is that Lisp allows you to think things that Java does not. Java has this imperative, object-oriented, hierarchical style of writing. My lisp code sytle varies to fit the problem. Sometimes it is imperative, sometimes functional, sometimes OO, sometimes snobol-like pattern matching, sometimes class-based. Occasionally I dynamically construct the code and execute it inline. Or I use macros to create my own problem language and code in that. And I create my data structures on the fly inline to the code. Once you really internalize lisp there are no real constraints on what you think or write. Thus there is no question of bracing style that is meaningful. The whole idea of bracing style is Java-think. Your language choice has given you an OO-procedural mindset. So when you reach for Lisp you want to see what you have come to expect. People who work with bricks (Java) tend to wonder why they don't find bricks among people who work with modelling clay (Lisp). The answer isn't in the material, it is in your mindset. Just by looking at lisp code I can tell what your native language is. Fortran programmers simulate COMMON blocks, C programmers use things as pointers, etc. You can write Fortran in any language is a famous quote but you can't write Lisp in any language. And you can quote me on that. (But only in my obituary :-) ) In fact, I think that this is going to be the hardest barrier to the adoption of Clojure. Real Java Programmers are not going to like the bracing style (or lack thereof) in Clojure. Tim Daly Greg wrote: It's almost purely community convention that has been adopted from Lisp. You may be interested in this link: http://gregslepak.posterous.com/on-lisps-readability There is much discussion about this topic there. Cheers, Greg On Aug 18, 2010, at 2:09 AM, michele wrote: Wouldn't that make it easier to keep track of them. Example: (defn myfn-a [a b] (if (zero? b) a (recur (afn (bfn (...)) a) (dec b (defn myfn-b [a b] (if (zero? b) a (recur (afn (bfn (...)) a) (dec b) ) ) ) -- 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
Re: cool compiler-project?
While I think Clojure is an impressive achievement, I would not have thought that the Clojure compiler (or Lisp compilers in general) would be interesting for a post-grad student to work on. After all, Lisps are known for their simple syntax and grammar, and Clojure compiles to Java byte codes, so presumably the Clojure compiler does not include an optimizer. Bill Smith Austin, Texas On Aug 18, 7:35 am, Sreeraj a writeto...@gmail.com wrote: Hi, I am a post-grad student looking for a cool compiler - project to do. I am getting comfortable with clojure and would really like to help Ideas anyone? or, Is there a to-do list where can i start? Cheers Sreeraj -- 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: What is the reason Lisp code is not written with closing parenthesis on new lines?
On Wed, Aug 18, 2010 at 1:36 PM, Greg g...@kinostudios.com wrote: Attached is a screenshot of some code from the wonderful Incanter library. I think it's a great illustration of how confusing stacking parenthesis can be (there are many functions in there that are like this). Again, that's quite a straw man--the attached code uses tabs for indentation, (ick!) and you're viewing it with a different tab-stop setting. It's also several times longer than reasonable. -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: What is the reason Lisp code is not written with closing parenthesis on new lines?
Actually, to be honest the short C++ example with lisp bracket style I find a lot easier to read: I don't need to scan all the page to find what belongs where... 2010/8/18 Greg g...@kinostudios.com: Now the question you're asking is, why don't lispers write (MyFactory somearg ) which makes me cringe. That's not at all what's being suggested -- you'll find that both in the OP's code and in the link below, there are many locations where closing parenthesis are ended on the same line. Trailing parens are placed only for certain blocks that traditionally would define a scope in another language, and this is convenient for many reasons, including generic reasons not attached to any specific language. It's not about carrying over much loved C style to Lisp, but to make actual use of parenthesis for the purpose of clearly outlining the structure of your code. Again, the link goes much more into depth on this. Attached is a screenshot of some code from the wonderful Incanter library. I think it's a great illustration of how confusing stacking parenthesis can be (there are many functions in there that are like this). The readability issue occurs when there's a drop in several indentation levels after many lines. This is a problem regardless of what the indentation width is, but is certainly made worse by a small indentation width. - Greg On Aug 18, 2010, at 1:17 PM, Tim Daly wrote: A more serious answer is that when I code in Java I use the brace-on-a-line kind of indentation. When I code in Lisp I never write single-line parens of any kind. I find that I think differently in each language. My Java code is always a pile of declare-this, do-this, do-this, return Thus I find that I'm delimiting the scope of my variables, marking my control flow and branching logic, try/catch logic, class boundaries, etc. My Lisp code mixes control flow and data structures in the same syntax. Thus the idea that parens are some kind of control flow delimiter is not particularly meaningful. To see the alternative case, take a Java program, find every function call such as: MyFactory(somearg); throw away the ';', and move the paren left to get: (MyFactory somearg) Now the question you're asking is, why don't lispers write (MyFactory somearg ) which makes me cringe. A second reason is that Lisp allows you to think things that Java does not. Java has this imperative, object-oriented, hierarchical style of writing. My lisp code sytle varies to fit the problem. Sometimes it is imperative, sometimes functional, sometimes OO, sometimes snobol-like pattern matching, sometimes class-based. Occasionally I dynamically construct the code and execute it inline. Or I use macros to create my own problem language and code in that. And I create my data structures on the fly inline to the code. Once you really internalize lisp there are no real constraints on what you think or write. Thus there is no question of bracing style that is meaningful. The whole idea of bracing style is Java-think. Your language choice has given you an OO-procedural mindset. So when you reach for Lisp you want to see what you have come to expect. People who work with bricks (Java) tend to wonder why they don't find bricks among people who work with modelling clay (Lisp). The answer isn't in the material, it is in your mindset. Just by looking at lisp code I can tell what your native language is. Fortran programmers simulate COMMON blocks, C programmers use things as pointers, etc. You can write Fortran in any language is a famous quote but you can't write Lisp in any language. And you can quote me on that. (But only in my obituary :-) ) In fact, I think that this is going to be the hardest barrier to the adoption of Clojure. Real Java Programmers are not going to like the bracing style (or lack thereof) in Clojure. Tim Daly Greg wrote: It's almost purely community convention that has been adopted from Lisp. You may be interested in this link: http://gregslepak.posterous.com/on-lisps-readability There is much discussion about this topic there. Cheers, Greg On Aug 18, 2010, at 2:09 AM, michele wrote: Wouldn't that make it easier to keep track of them. Example: (defn myfn-a [a b] (if (zero? b) a (recur (afn (bfn (...)) a) (dec b (defn myfn-b [a b] (if (zero? b) a (recur (afn (bfn (...)) a) (dec b) ) ) ) -- 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
Re: What is the reason Lisp code is not written with closing parenthesis on new lines?
On Wed, Aug 18, 2010 at 1:36 PM, Greg g...@kinostudios.com wrote: Attached is a screenshot of some code from the wonderful Incanter library. I think it's a great illustration of how confusing stacking parenthesis can be (there are many functions in there that are like this). But the indentation is broken in that code already. If the indentation were fixed (and the long functions refactored) it would be a lot more readable. In order to reformat it with trailing parens, you'd have to fix the basic indentation first anyway... In the blog post's example, I found the println 'parent' straight away and the extra vertical whitespace didn't help (sorry but lone closing parens just create vertical whitespace for me). I did find the 4 char indents easier to read than the 2 char indents. I wish CCW respected the displayed tab width setting as its indentation in strict structural mode as I'd rather have 4 spaces than 2 but it seems 2 is pretty much the standard around here? The readability issue occurs when there's a drop in several indentation levels after many lines. This is a problem regardless of what the indentation width is, but is certainly made worse by a small indentation width. The readability of the attached screenshot is due to broken indentation and the function being too long, IMO. (and, for background, I'm far more used to programming in C-style languages even tho' my Lisp usages dates back to the early 80's - but I do find I naturally settle into a different style in Lisp to what I use elsewhere) -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ If you're not annoying somebody, you're not really alive. -- Margaret Atwood -- 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: What is the reason Lisp code is not written with closing parenthesis on new lines?
Greg wrote: Now the question you're asking is, why don't lispers write (MyFactory somearg ) which makes me cringe. That's not at all what's being suggested -- you'll find that both in the OP's code and in the link below, there are many locations where closing parenthesis are ended on the same line. Trailing parens are placed only for certain blocks that traditionally would define a scope in another language, and this is convenient for many reasons, including generic reasons not attached to any specific language. It's not about carrying over much loved C style to Lisp, but to make actual use of parenthesis for the purpose of clearly outlining the structure of your code. In lisp it is functions all the way down. Defining functions that introduce scope and having them outdent is odd. Some of those functions could be macros which introduce lexical or dynamic scope. Should functions that are macros use outdenting? Maybe some should, such as (with-open-file...) but I often have macros that introduce binding blocks yet they appear to the user to be a function. (e.g. the MyFactory macro) Scope is a very slippery concept in a language like lisp. Where it does occur in obvious cases (e.g. a let) you'll find that lispers universally indent their code, just like everyone else. Again, the link goes much more into depth on this. Yes, I read the link. I'm going to hazard a guess that lisp is not your native language :-) Attached is a screenshot of some code from the wonderful Incanter library. I think it's a great illustration of how confusing stacking parenthesis can be (there are many functions in there that are like this). The readability issue occurs when there's a drop in several indentation levels after many lines. This is a problem regardless of what the indentation width is, but is certainly made worse by a small indentation width. Well, if all else fails, try (pprint your-expression) and see what the canonical version is. The modelling clay (lisp) doesn't care, it reflects the shape of your thoughts. If you want brick shapes (java), the lisp reader won't care. Your claim seems to be that outdented code in brick form is easier to read and understand. That's a very personal issue and I don't think I've ever struggled to understand code based on the outdenting style. (Factory, Visitor, Facade, etc. DO cause me to stumble :-) ) I do think it is interesting that most of the code snippets I see posted here in Clojure do not tend to use outdenting brace style. And when I look at core.clj I don't see any outdenting going on but I find the code highly readable. In fact, I can't find a single instance of outdenting anywhere in src/clj/clojure. Rich has obviously discovered his inner lisp. Anyway, since this is a religious issue with no resolution I can only recommend: http://www.youtube.com/watch?v=5-OjTPj7K54 Beware the lightning :-) Tim Daly - Greg On Aug 18, 2010, at 1:17 PM, Tim Daly wrote: A more serious answer is that when I code in Java I use the brace-on-a-line kind of indentation. When I code in Lisp I never write single-line parens of any kind. I find that I think differently in each language. My Java code is always a pile of declare-this, do-this, do-this, return Thus I find that I'm delimiting the scope of my variables, marking my control flow and branching logic, try/catch logic, class boundaries, etc. My Lisp code mixes control flow and data structures in the same syntax. Thus the idea that parens are some kind of control flow delimiter is not particularly meaningful. To see the alternative case, take a Java program, find every function call such as: MyFactory(somearg); throw away the ';', and move the paren left to get: (MyFactory somearg) Now the question you're asking is, why don't lispers write (MyFactory somearg ) which makes me cringe. A second reason is that Lisp allows you to think things that Java does not. Java has this imperative, object-oriented, hierarchical style of writing. My lisp code sytle varies to fit the problem. Sometimes it is imperative, sometimes functional, sometimes OO, sometimes snobol-like pattern matching, sometimes class-based. Occasionally I dynamically construct the code and execute it inline. Or I use macros to create my own problem language and code in that. And I create my data structures on the fly inline to the code. Once you really internalize lisp there are no real constraints on what you think or write. Thus there is no question of bracing style that is meaningful. The whole idea of bracing style is Java-think. Your language choice has given you an OO-procedural mindset. So when you reach for Lisp you want to see what you have come to expect. People who work with bricks (Java) tend to wonder why they don't find bricks among people who work with modelling clay (Lisp). The answer isn't in the material, it is
Re: What is the reason Lisp code is not written with closing parenthesis on new lines?
Yes, I read the link. I'm going to hazard a guess that lisp is not your native language :-) I consider Lisp to be one of my favorite languages (if not my favorite), and I've been coding in it for several years. It's rather silly to assume something about someone's programming experience based on their code style. Sometimes you'd be right, and other times you'd be wrong, just as with any sort of stereotyping. Scope is a very slippery concept in a language like lisp. Where it does occur in obvious cases (e.g. a let) you'll find that lispers universally indent their code, just like everyone else. This I understand very well (as I mentioned in the post). It really has no bearing on the central argument though. It's only introduced as a guideline as to where you might want to consider trailing your parens. That's a very personal issue and I don't think I've ever struggled to understand code based on the outdenting style. I think I've said that several times now. :-) I actually do like the succinctness of stacked parenthesis, but unfortunately that style has many shortcomings that I find rather annoying. Again, to each his own. Sincerely, Greg Slepak On Aug 18, 2010, at 2:49 PM, Tim Daly wrote: Greg wrote: Now the question you're asking is, why don't lispers write (MyFactory somearg ) which makes me cringe. That's not at all what's being suggested -- you'll find that both in the OP's code and in the link below, there are many locations where closing parenthesis are ended on the same line. Trailing parens are placed only for certain blocks that traditionally would define a scope in another language, and this is convenient for many reasons, including generic reasons not attached to any specific language. It's not about carrying over much loved C style to Lisp, but to make actual use of parenthesis for the purpose of clearly outlining the structure of your code. In lisp it is functions all the way down. Defining functions that introduce scope and having them outdent is odd. Some of those functions could be macros which introduce lexical or dynamic scope. Should functions that are macros use outdenting? Maybe some should, such as (with-open-file...) but I often have macros that introduce binding blocks yet they appear to the user to be a function. (e.g. the MyFactory macro) Scope is a very slippery concept in a language like lisp. Where it does occur in obvious cases (e.g. a let) you'll find that lispers universally indent their code, just like everyone else. Again, the link goes much more into depth on this. Yes, I read the link. I'm going to hazard a guess that lisp is not your native language :-) Attached is a screenshot of some code from the wonderful Incanter library. I think it's a great illustration of how confusing stacking parenthesis can be (there are many functions in there that are like this). The readability issue occurs when there's a drop in several indentation levels after many lines. This is a problem regardless of what the indentation width is, but is certainly made worse by a small indentation width. Well, if all else fails, try (pprint your-expression) and see what the canonical version is. The modelling clay (lisp) doesn't care, it reflects the shape of your thoughts. If you want brick shapes (java), the lisp reader won't care. Your claim seems to be that outdented code in brick form is easier to read and understand. That's a very personal issue and I don't think I've ever struggled to understand code based on the outdenting style. (Factory, Visitor, Facade, etc. DO cause me to stumble :-) ) I do think it is interesting that most of the code snippets I see posted here in Clojure do not tend to use outdenting brace style. And when I look at core.clj I don't see any outdenting going on but I find the code highly readable. In fact, I can't find a single instance of outdenting anywhere in src/clj/clojure. Rich has obviously discovered his inner lisp. Anyway, since this is a religious issue with no resolution I can only recommend: http://www.youtube.com/watch?v=5-OjTPj7K54 Beware the lightning :-) Tim Daly - Greg On Aug 18, 2010, at 1:17 PM, Tim Daly wrote: A more serious answer is that when I code in Java I use the brace-on-a-line kind of indentation. When I code in Lisp I never write single-line parens of any kind. I find that I think differently in each language. My Java code is always a pile of declare-this, do-this, do-this, return Thus I find that I'm delimiting the scope of my variables, marking my control flow and branching logic, try/catch logic, class boundaries, etc. My Lisp code mixes control flow and data structures in the same syntax. Thus the idea that parens are some kind of control flow delimiter is not particularly
Re: What is the reason Lisp code is not written with closing parenthesis on new lines?
Too bad. If you wanted to focus on the trailing-parens (which you clearly did in that article), you should have kept everything else the same between your examples. Perhaps I should, then I wouldn't have to respond to your emails. :-p As I've said multiple times now, now indentation width does help readability, but adding trailing parenthesis on top of that can increase it further. From an information theoretic point of view, it should be obvious. Whereas on the one hand you only have one bit of information to judge what function you're in (just increasing indentation width), on the other you have two bits (indentation width + trailing parenthesis). Closing the comments after people started to question you on this wasn't a good move, either (otherwise I'd be commenting there rather than here). Oh goodie, it seems like it was a good move after all. :-P - Greg On Aug 18, 2010, at 1:33 PM, Michael Gardner wrote: On Aug 18, 2010, at 2:49 PM, Greg wrote: On Aug 18, 2010, at 12:07 PM, Michael Gardner wrote: On Aug 18, 2010, at 1:38 PM, Greg wrote: http://gregslepak.posterous.com/on-lisps-readability That article is dishonest. Speaking as the author, I'm a bit offended. Too bad. If you wanted to focus on the trailing-parens (which you clearly did in that article), you should have kept everything else the same between your examples. If you wanted to comment on indentation as well, you should have (a) given it equal prominence in your discussion, (b) used separate code examples for trailing-parens vs indentation, and/or (c) made a separate post. Closing the comments after people started to question you on this wasn't a good move, either (otherwise I'd be commenting there rather than here). -- 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: cool compiler-project?
so presumably the Clojure compiler does not include an optimizer. So write an optimizing Clojure compiler! Or do type inference for Clojure. Or partial evaluation. Or a compiler that targets LLVM. On Aug 18, 10:46 pm, .Bill Smith william.m.sm...@gmail.com wrote: While I think Clojure is an impressive achievement, I would not have thought that the Clojure compiler (or Lisp compilers in general) would be interesting for a post-grad student to work on. After all, Lisps are known for their simple syntax and grammar, and Clojure compiles to Java byte codes, so presumably the Clojure compiler does not include an optimizer. Bill Smith Austin, Texas On Aug 18, 7:35 am, Sreeraj a writeto...@gmail.com wrote: Hi, I am a post-grad student looking for a cool compiler - project to do. I am getting comfortable with clojure and would really like to help Ideas anyone? or, Is there a to-do list where can i start? Cheers Sreeraj -- 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: cool compiler-project?
Or a Clojure to Javascript compiler. So many interesting projects! On Aug 19, 12:36 am, Jules julesjac...@gmail.com wrote: so presumably the Clojure compiler does not include an optimizer. So write an optimizing Clojure compiler! Or do type inference for Clojure. Or partial evaluation. Or a compiler that targets LLVM. On Aug 18, 10:46 pm, .Bill Smith william.m.sm...@gmail.com wrote: While I think Clojure is an impressive achievement, I would not have thought that the Clojure compiler (or Lisp compilers in general) would be interesting for a post-grad student to work on. After all, Lisps are known for their simple syntax and grammar, and Clojure compiles to Java byte codes, so presumably the Clojure compiler does not include an optimizer. Bill Smith Austin, Texas On Aug 18, 7:35 am, Sreeraj a writeto...@gmail.com wrote: Hi, I am a post-grad student looking for a cool compiler - project to do. I am getting comfortable with clojure and would really like to help Ideas anyone? or, Is there a to-do list where can i start? Cheers Sreeraj -- 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: What is the reason Lisp code is not written with closing parenthesis on new lines?
I wrote a post about this very thread. http://blog.fogus.me/2010/07/12/wadlers-law-extended-to-clojure/ :f -- 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: cool compiler-project?
Hi people! Related to Clojure to Javascript http://github.com/richhickey/clojure-contrib/tree/master/clojurescript/ Angel Java Lopez http://www.ajlopez.com http://twitter.com/ajlopez On Wed, Aug 18, 2010 at 7:37 PM, Jules julesjac...@gmail.com wrote: Or a Clojure to Javascript compiler. So many interesting projects! On Aug 19, 12:36 am, Jules julesjac...@gmail.com wrote: so presumably the Clojure compiler does not include an optimizer. So write an optimizing Clojure compiler! Or do type inference for Clojure. Or partial evaluation. Or a compiler that targets LLVM. On Aug 18, 10:46 pm, .Bill Smith william.m.sm...@gmail.com wrote: While I think Clojure is an impressive achievement, I would not have thought that the Clojure compiler (or Lisp compilers in general) would be interesting for a post-grad student to work on. After all, Lisps are known for their simple syntax and grammar, and Clojure compiles to Java byte codes, so presumably the Clojure compiler does not include an optimizer. Bill Smith Austin, Texas On Aug 18, 7:35 am, Sreeraj a writeto...@gmail.com wrote: Hi, I am a post-grad student looking for a cool compiler - project to do. I am getting comfortable with clojure and would really like to help Ideas anyone? or, Is there a to-do list where can i start? Cheers Sreeraj -- 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: cool compiler-project?
+1 for an optimizer -- 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: cool compiler-project?
Or a native dalvik compiler! -- Pull me down under... On Thu, Aug 19, 2010 at 10:37 AM, Jules julesjac...@gmail.com wrote: Or a Clojure to Javascript compiler. So many interesting projects! -- 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: What is the reason Lisp code is not written with closing parenthesis on new lines?
The Incanter example is confusing for the same reason that the Leiningen example from the blog post is confusing, and I don't think paren style matters at all. The functions have grown over time, they're now too big, and they need to be refactored into several smaller functions. The paren style is a red herring. core.clj is readable because its functions are short. When your code makes you want to outdent, you can take this as a signal that your function has gotten too big and needs to be refactored. - Will Morgan On Aug 18, 4:36 pm, Greg g...@kinostudios.com wrote: Now the question you're asking is, why don't lispers write (MyFactory somearg ) which makes me cringe. That's not at all what's being suggested -- you'll find that both in the OP's code and in the link below, there are many locations where closing parenthesis are ended on the same line. Trailing parens are placed only for certain blocks that traditionally would define a scope in another language, and this is convenient for many reasons, including generic reasons not attached to any specific language. It's not about carrying over much loved C style to Lisp, but to make actual use of parenthesis for the purpose of clearly outlining the structure of your code. Again, the link goes much more into depth on this. Attached is a screenshot of some code from the wonderful Incanter library. I think it's a great illustration of how confusing stacking parenthesis can be (there are many functions in there that are like this). The readability issue occurs when there's a drop in several indentation levels after many lines. This is a problem regardless of what the indentation width is, but is certainly made worse by a small indentation width. - Greg Screen shot 2010-08-18 at 1.32.09 PM.png 48KViewDownload On Aug 18, 2010, at 1:17 PM, Tim Daly wrote: A more serious answer is that when I code in Java I use the brace-on-a-line kind of indentation. When I code in Lisp I never write single-line parens of any kind. I find that I think differently in each language. My Java code is always a pile of declare-this, do-this, do-this, return Thus I find that I'm delimiting the scope of my variables, marking my control flow and branching logic, try/catch logic, class boundaries, etc. My Lisp code mixes control flow and data structures in the same syntax. Thus the idea that parens are some kind of control flow delimiter is not particularly meaningful. To see the alternative case, take a Java program, find every function call such as: MyFactory(somearg); throw away the ';', and move the paren left to get: (MyFactory somearg) Now the question you're asking is, why don't lispers write (MyFactory somearg ) which makes me cringe. A second reason is that Lisp allows you to think things that Java does not. Java has this imperative, object-oriented, hierarchical style of writing. My lisp code sytle varies to fit the problem. Sometimes it is imperative, sometimes functional, sometimes OO, sometimes snobol-like pattern matching, sometimes class-based. Occasionally I dynamically construct the code and execute it inline. Or I use macros to create my own problem language and code in that. And I create my data structures on the fly inline to the code. Once you really internalize lisp there are no real constraints on what you think or write. Thus there is no question of bracing style that is meaningful. The whole idea of bracing style is Java-think. Your language choice has given you an OO-procedural mindset. So when you reach for Lisp you want to see what you have come to expect. People who work with bricks (Java) tend to wonder why they don't find bricks among people who work with modelling clay (Lisp). The answer isn't in the material, it is in your mindset. Just by looking at lisp code I can tell what your native language is. Fortran programmers simulate COMMON blocks, C programmers use things as pointers, etc. You can write Fortran in any language is a famous quote but you can't write Lisp in any language. And you can quote me on that. (But only in my obituary :-) ) In fact, I think that this is going to be the hardest barrier to the adoption of Clojure. Real Java Programmers are not going to like the bracing style (or lack thereof) in Clojure. Tim Daly Greg wrote: It's almost purely community convention that has been adopted from Lisp. You may be interested in this link: http://gregslepak.posterous.com/on-lisps-readability There is much discussion about this topic there. Cheers, Greg On Aug 18, 2010, at 2:09 AM, michele wrote: Wouldn't that make it easier to keep track of them. Example: (defn myfn-a [a b] (if (zero? b) a (recur (afn (bfn (...)) a) (dec b (defn myfn-b [a b] (if (zero? b) a (recur (afn (bfn (...)) a) (dec b) ) ) )
Re: cool compiler-project?
Write a compiler routine to detect tail recursion. It is my (limited) understanding that Java can perform tail recursion elimination but only under limited conditions. Is there a way to detect tail recursion in Clojure and dynamically rewrite the code to do real recursion rather than using recur? Is your solution general enough? Mark Derricutt wrote: Or a native dalvik compiler! -- Pull me down under... On Thu, Aug 19, 2010 at 10:37 AM, Jules julesjac...@gmail.com mailto:julesjac...@gmail.com wrote: Or a Clojure to Javascript compiler. So many interesting projects! -- 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: Today's clojure trick question
However, if you do (let [x (java.lang.Boolean/getBoolean false)] (if x :trouble :ok)) you're fine, which obviously isn't helpful in your situation. Boolean.getBoolean() is pretty evil, too. It was featured in one of Joshua Bloch's java puzzlers (which might have been borrowed from somewhere else, I don't know if it was originally his). Watch out, it might not do what you think it does. :) For instance: System.out.println(Boolean.getBoolean(false)); System.out.println(Boolean.getBoolean(true)); System.out.println(Boolean.getBoolean(fred)); will print false three times. Joe -- 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: What is the reason Lisp code is not written with closing parenthesis on new lines?
I've rarely found these coding style discussions to be productive, and have wondered why source control systems don't just store code in a whitespace normalized format and automatically format the code to your own taste when you check it out, because, let's face it, formatting is semantically irrelevant. It may help *you* grasp the meaning more quickly, but the opposite may be true for others. But I guess automatic formatting would totally destroy the ability to talk about line 16 of a particular file. Then I move on to thinking it best for a language designer to just legislate fomatting and make it a compiler error, but that would probably generate more discussion than otherwise, so I've just written the whole thing off as a lose-lose situation. But maybe I'm just getting cumudgenly in my old age. I do however firmly believe that each language has a worldview and a culture that coaleces around it, and one is better off either adopting it whole hog, or finding another language that matches better with one's own worldview. Something akin to what Brenton said about choosing a language because it mirrors your thinking, not because of readability concerns. It is a disaster to try to force the idioms of one language to be true in another. Paul -- 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: What is the reason Lisp code is not written with closing parenthesis on new lines?
I'm reminded gigamonkey's footnote about when functions get too big: A friend of mine was once interviewing an engineer for a programming job and asked him a typical interview question: how do you know when a function or method is too big? Well, said the candidate, I don't like any method to be bigger than my head. You mean you can't keep all the details in your head? No, I mean I put my head up against my monitor, and the code shouldn't be bigger than my head. [1] There are many different styles for source code, but my experience with lisp suggests that variable indentation (as provided by emacs lisp-mode or clojure-mode) and parens-not-on-their-own-line makes for much more readable code. core.clj is a good example where the code is generally readable, but I shudder to think what it would be like to read the code for doseq or destructure if each closing parenthesis were on its own line. And, as for writing code, I couldn't live without paredit. To each their own, but let's not go down the route of saying hey, you're code formatting style sucks, but I don't want to start a flame war :). Cyrus 1. http://www.gigamonkeys.com/book/practical-a-simple-database.html On Aug 18, 2010, at 6:24 PM, wwmorgan wrote: The Incanter example is confusing for the same reason that the Leiningen example from the blog post is confusing, and I don't think paren style matters at all. The functions have grown over time, they're now too big, and they need to be refactored into several smaller functions. The paren style is a red herring. core.clj is readable because its functions are short. When your code makes you want to outdent, you can take this as a signal that your function has gotten too big and needs to be refactored. - Will Morgan On Aug 18, 4:36 pm, Greg g...@kinostudios.com wrote: Now the question you're asking is, why don't lispers write (MyFactory somearg ) which makes me cringe. That's not at all what's being suggested -- you'll find that both in the OP's code and in the link below, there are many locations where closing parenthesis are ended on the same line. Trailing parens are placed only for certain blocks that traditionally would define a scope in another language, and this is convenient for many reasons, including generic reasons not attached to any specific language. It's not about carrying over much loved C style to Lisp, but to make actual use of parenthesis for the purpose of clearly outlining the structure of your code. Again, the link goes much more into depth on this. Attached is a screenshot of some code from the wonderful Incanter library. I think it's a great illustration of how confusing stacking parenthesis can be (there are many functions in there that are like this). The readability issue occurs when there's a drop in several indentation levels after many lines. This is a problem regardless of what the indentation width is, but is certainly made worse by a small indentation width. - Greg Screen shot 2010-08-18 at 1.32.09 PM.png 48KViewDownload On Aug 18, 2010, at 1:17 PM, Tim Daly wrote: A more serious answer is that when I code in Java I use the brace-on-a-line kind of indentation. When I code in Lisp I never write single-line parens of any kind. I find that I think differently in each language. My Java code is always a pile of declare-this, do-this, do-this, return Thus I find that I'm delimiting the scope of my variables, marking my control flow and branching logic, try/catch logic, class boundaries, etc. My Lisp code mixes control flow and data structures in the same syntax. Thus the idea that parens are some kind of control flow delimiter is not particularly meaningful. To see the alternative case, take a Java program, find every function call such as: MyFactory(somearg); throw away the ';', and move the paren left to get: (MyFactory somearg) Now the question you're asking is, why don't lispers write (MyFactory somearg ) which makes me cringe. A second reason is that Lisp allows you to think things that Java does not. Java has this imperative, object-oriented, hierarchical style of writing. My lisp code sytle varies to fit the problem. Sometimes it is imperative, sometimes functional, sometimes OO, sometimes snobol-like pattern matching, sometimes class-based. Occasionally I dynamically construct the code and execute it inline. Or I use macros to create my own problem language and code in that. And I create my data structures on the fly inline to the code. Once you really internalize lisp there are no real constraints on what you think or write. Thus there is no question of bracing style that is meaningful. The whole idea of bracing style is Java-think. Your language choice has given you an OO-procedural mindset. So when you reach for Lisp you want to see what you have come to expect. People who work with bricks (Java) tend to wonder why
Re: What is the reason Lisp code is not written with closing parenthesis on new lines?
On Wed, 18 Aug 2010 22:48:07 -0400 Paul Stadig p...@stadig.name wrote: Then I move on to thinking it best for a language designer to just legislate fomatting and make it a compiler error, but that would probably generate more discussion than otherwise, so I've just written the whole thing off as a lose-lose situation. But maybe I'm just getting cumudgenly in my old age. You could argue that this is the route that ABC/Python took - formatting, not punctuation, dictates flow control. Broken formatting generates compiler errors: python /tmp/break.py File /tmp/break.py, line 3 print 4 ^ IndentationError: unexpected indent So people argue about putting back the punctuation instead of where the punctuation goes. Not quite as much, but it still happens. mike -- Mike Meyer m...@mired.org http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: What is the reason Lisp code is not written with closing parenthesis on new lines?
On Aug 18, 2010, at 7:48 PM, Paul Stadig wrote: It may help *you* grasp the meaning more quickly, but the opposite may be true for others. But I guess automatic formatting would totally destroy the ability to talk about line 16 of a particular file. This is a nifty point and idea. I think I'd enjoy living in such a world, as it would probably support a more harmonious existence amongst coders, somewhat in the same vein as the good that comes out of racial-tolerance. Your code may look different than mine, but it's still cool because they both compile just the same. ;-) In such a world it may be better than to speak of expression numbers instead of line numbers, but alas, that would require quite a departure from the world of editors that we live in today. - Greg I've rarely found these coding style discussions to be productive, and have wondered why source control systems don't just store code in a whitespace normalized format and automatically format the code to your own taste when you check it out, because, let's face it, formatting is semantically irrelevant. It may help *you* grasp the meaning more quickly, but the opposite may be true for others. But I guess automatic formatting would totally destroy the ability to talk about line 16 of a particular file. Then I move on to thinking it best for a language designer to just legislate fomatting and make it a compiler error, but that would probably generate more discussion than otherwise, so I've just written the whole thing off as a lose-lose situation. But maybe I'm just getting cumudgenly in my old age. I do however firmly believe that each language has a worldview and a culture that coaleces around it, and one is better off either adopting it whole hog, or finding another language that matches better with one's own worldview. Something akin to what Brenton said about choosing a language because it mirrors your thinking, not because of readability concerns. It is a disaster to try to force the idioms of one language to be true in another. Paul -- 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: cool compiler-project?
only in the cases already handled by recur. jvm's goto instruction only works within method bodies On Wed, Aug 18, 2010 at 6:24 PM, Tim Daly d...@axiom-developer.org wrote: Write a compiler routine to detect tail recursion. It is my (limited) understanding that Java can perform tail recursion elimination but only under limited conditions. Is there a way to detect tail recursion in Clojure and dynamically rewrite the code to do real recursion rather than using recur? Is your solution general enough? Mark Derricutt wrote: Or a native dalvik compiler! -- Pull me down under... On Thu, Aug 19, 2010 at 10:37 AM, Jules julesjac...@gmail.com mailto:julesjac...@gmail.com wrote: Or a Clojure to Javascript compiler. So many interesting projects! -- 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 -- And what is good, Phaedrus, And what is not good— Need we ask anyone to tell us these things? -- 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: What is the reason Lisp code is not written with closing parenthesis on new lines?
It isn't helpful at all to me. My eyes bleed when I see code written like that. It may be helpful to some people, but I don't see the point when I have an editor that can match parens for me without any real work on my part. The parens aren't something I feel I need to maintain, because between paredit and paren matching, I never have problems with them. On Aug 18, 4:09 am, michele michelemen...@gmail.com wrote: Wouldn't that make it easier to keep track of them. Example: (defn myfn-a [a b] (if (zero? b) a (recur (afn (bfn (...)) a) (dec b (defn myfn-b [a b] (if (zero? b) a (recur (afn (bfn (...)) a) (dec b) ) ) ) -- 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: cool compiler-project?
Could the compiler insert phantom method bodies around classes? Or does the JVM insist that you can't lie about the code structure? Am I being too lispish for the JVM? Clearly the JVM needs to look up some factoid out of the method body in order to recur so I'm suggesting that the whole set of classes get wrapped in a phantom method. The code that comes out of the compiler does not need to mirror the code that went into the compiler. That's the whole point of doing compiler optimizations. Perhaps a literature pointer could make the restriction clear. Tim Daly Kevin Downey wrote: only in the cases already handled by recur. jvm's goto instruction only works within method bodies On Wed, Aug 18, 2010 at 6:24 PM, Tim Daly d...@axiom-developer.org wrote: Write a compiler routine to detect tail recursion. It is my (limited) understanding that Java can perform tail recursion elimination but only under limited conditions. Is there a way to detect tail recursion in Clojure and dynamically rewrite the code to do real recursion rather than using recur? Is your solution general enough? Mark Derricutt wrote: Or a native dalvik compiler! -- Pull me down under... On Thu, Aug 19, 2010 at 10:37 AM, Jules julesjac...@gmail.com mailto:julesjac...@gmail.com wrote: Or a Clojure to Javascript compiler. So many interesting projects! -- 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
