Has anyone on this group ever tried Forth?
Hi everyone, I was browsing through webpages and the language Forth caught my eye. Reading through it's supposed advantages it sounded very interesting, and I was wondering if anyone here has any experience with it, and can comment. I'm asking on the Clojure forum instead of the Forth forum because I agree with the programming values that Clojure emphasizes, and would like to hear opinions from people with similar values to myself. I'm most interested in it's productivity aspect. (ie. how quick can I get real work done) Thanks for your opinions -Patrick --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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: Has anyone on this group ever tried Forth?
On 10/04/2009, at 4:43 PM, CuppoJava wrote: Hi everyone, I was browsing through webpages and the language Forth caught my eye. Reading through it's supposed advantages it sounded very interesting, and I was wondering if anyone here has any experience with it, and can comment. I'm asking on the Clojure forum instead of the Forth forum because I agree with the programming values that Clojure emphasizes, and would like to hear opinions from people with similar values to myself. I'm most interested in it's productivity aspect. (ie. how quick can I get real work done) If you are interested in Forth you should probably check Factor at http://factorcode.org/ Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 It is no measure of health to be well adjusted to a profoundly sick society. -- Jiddu Krishnamurti --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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: DISCUSS: clojure.contrib.java-utils/as-str
Sure enough, I get the same results
user= (defn as-str
[ args]
(apply str (map #(if (instance? clojure.lang.Named %) (name %) %) args)))
#'user/as-str
user= (time (dotimes [i 100] (as-str :a)))
Elapsed time: 416.497348 msecs
nil
user= (time (dotimes [i 100] (as-str :a 1)))
Elapsed time: 1023.526175 msecs
Apparently
(defmacro as-str3 [ args]
(cons 'str (map #(if (instance? clojure.lang.Named %) (name %) %) args)))
runs as fast (or minusculy faster) than the original version that you posted:
user= (defn as-str2
With no args, returns the empty string. With one arg, returns its name
or string representation. (as-str nil) returns the empty string. With
more than one arg, returns the concatenation of the as-str values of the
args.
{:tag String}
([] )
([x]
(if (instance? clojure.lang.Named x)
(name x)
(str x)))
([x ys]
(let [sb (StringBuilder. #^String (as-str x))]
(doseq [y ys]
(.append sb (as-str y)))
(.toString sb
user= (time (dotimes [i 100] (as-str2 :a)))
Elapsed time: 29.844296 msecs
user= (time (dotimes [i 100] (as-str2 :a 1)))
Elapsed time: 1046.465682 msecs
user= (defmacro as-str3 [ args]
(cons 'str (map #(if (instance? clojure.lang.Named %) (name %) %) args)))
nil
user= (time (dotimes [i 100] (as-str3 :a)))
Elapsed time: 28.533794 msecs
nil
user= (time (dotimes [i 100] (as-str3 :a 1)))
Elapsed time: 260.311017 msecs
Which sees to indicate that apply is actually what is slow...
Sure enough, if we do
user= (defmacro apply2 [fn args] (cons fn 'args))
nil
user= (time (dotimes [i 100] (apply2 str (map #(if (instance?
clojure.lang.Named %) (name %) %) '(:a)
Elapsed time: 28.215038 msecs
user= (time (dotimes [i 100] (apply2 str (map #(if (instance?
clojure.lang.Named %) (name %) %) '(:a 1)
Elapsed time: 262.348148 msecs
I tried a couple times to use apply2 in a defn or defmacro for as-str,
but kept on getting weird exceptions. I'm probably just tired and
doing something wrong, so I'll just leave it at that for now...
Perhaps apply needs to be revisited?
--Eric Tschetter
On Thu, Apr 9, 2009 at 6:49 AM, Stephen C. Gilardi squee...@mac.com wrote:
On Apr 9, 2009, at 2:57 AM, Eric Tschetter wrote:
Might I suggest
(defn as-str
([] )
([ args]
(apply str (map #(if (instance? clojure.lang.Named %) (name %) %)
args)))
I like it for its simplicity. It can actually be a little simpler yet as the
general case gives the same result when passed no arguments as the special
case does:
(defn as-str
[ args]
(apply str (map #(if (instance? clojure.lang.Named %) (name %) %) args)))
This code works well, but performs much less well than the code I posted.
Just by code inspection, we can see that it's doing a lot more work,
invoking a lot more machinery, especially in the one-argument case.
We can run some micro-benchmarks to get some idea how that affects its
performance:
For a one argument case:
; as-str using apply
user= (time (dotimes [i 100] (as-str :a)))
Elapsed time: 496.361 msecs
; as-str not using apply
user= (time (dotimes [i 100] (as-str :a)))
Elapsed time: 22.178 msecs
The non-apply version is 22 times as fast.
For a two argument case:
; as-str using apply
user= (time (dotimes [i 100] (as-str :a 1)))
Elapsed time: 1057.922 msecs
; as-str not using apply
user= (time (dotimes [i 100] (as-str :a 1)))
Elapsed time: 317.483 msecs
The non-apply version is 3.3 times as fast.
From looking at this difference, my conclusion is that the version I posted
is simple enough to be preferred over the apply version given that its
performance, especially in the one argument case, is so much better.
Criticisms of that conclusion:
- These are micro-benchmarks, they tell us little about how either
version will really perform when the processor is doing more than just
repeating the same operation over and over.
- This is premature optimization, there's no evidence that this
difference will matter in practice.
- The apply version is simple, functional, and pretty. In the long
run that matters more than performance.
Thoughts on the criticisms:
micro-benchmark: that's right, although, combined with thinking about
how the code works, it does give some indication of the performance
difference which is not 10%, or 60%, but 2100%. This is library code that
should run well in a large variety of circumstances. A factor of 22 in
performance is hard to ignore in that scenario.
premature: that's right. It's only the this is a low-level operation
that may be used heavily in circumstances we don't yet imagine argument
that pushes me to consider this optimization in the absence of a real
performance test that shows it matters.
simple: The apply version is certainly pretty. The version I posted,
though, is also
Suggestion - change doc string of rand-int
Hi. (doc rand-int) says ([n]) Returns a random integer between 0 (inclusive) and n (exclusive). I think the word integer may cause some confusion, because it can be interpreted as clojure integer - including int, long and BigInteger. But the reality is with long or BigInteger n, rand-int does not work properly. How about changing doc string to clarify effective range of n? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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 dependency management and build
Iv been using gant which has built in support for Ivy Ant (for example http://tiny.cc/tRGKB), since the build scripts are code they make it easier to keep build scripts DRY. On Apr 9, 9:40 pm, Bradford Cross bradford.n.cr...@gmail.com wrote: On Thu, Apr 9, 2009 at 11:34 AM, Stuart Sierra the.stuart.sie...@gmail.comwrote: I keep a Clojure stuff dir with the latest revisions of all the projects I track -- Clojure, contrib, swank, slime, etc. -- and update them all with a shell script that runs the various svn update and git pull commands. So I always have access to the latest version of everything. But I don't automatically use the latest releases in my projects! Each project that I work on has a lib dir for JARs, including Clojure. I manage the JARs manually, but they're part of my source control repository. I update the the JARs only when some new functionality or bug fix that I depend on comes out. That way I know that a project won't suddenly break just because I've updated to the latest Clojure SVN. I use Ant for build management, with separate build dirs for compiled Java code and AOT-compiled Clojure code. Here's my build.xml: http://tinyurl.com/c5vkfm Cool, thanks, I will look over this stuff today. Sounds like more or less what I have been doing. What are you doing about building up the classpath for your projects in slime/swan? Where does the rake come into play? Multi-version dependency tracking is HARD. I've never seen a system that does it perfectly -- Rubygems, CPAN, Maven, you name it. Yea, I don't imagine will solve things beautifully at first, but we should be able to at least streamline things a bit. -Stuart S On Apr 8, 3:31 pm, Bradford Cross bradford.n.cr...@gmail.com wrote: When you are building something real with Clojure and Emacs/Slime/Swank - things can get a bit hairy with dependency management. I have scoured the inter-tubes in the past couple days to see what I could find. I found Lancet, for builds: http://github.com/stuarthalloway/lancet/tree/master I haven't tried it yet. I found some people doing things with Maven: Creating a clojurue app with maven: http://pupeno.com/blog/how-to-create-a-clojure-application?set_langua... clojure-pom:http://github.com/dysinger/clojure-pom/tree/master I heard some chatter yesterday on #clojure about using Ivy with Clojure. So there is a flurry of activity. Please let me know if there are other things that I am missing. What I am doing now from my emacs / slime-repl is hacking things in manually to my swank-clojure-extra-classpaths. This doesn't scale for working with multiple clojure projects in emacs. I will probably create a script to make things a bit nicer. But I'd like something fundamentally better. Here are the issues: -I download lots of little projects things from github and i want to munge them all together for my app. This means I need to build jars (some with ant, otehrs with maven, etc.) and in other cases I want to depend directly on the .clj files using clojures namespace-to-dir-structure conventions. So there are a couple different ways to build of the classpath - one for .clj and one for .jar. -Many projects also have their own lib foler - with both jars and cljs, so I need to pick those deps up transatively. -The work in the Clojure community is proceeding very fast, so I'd like updating all the projects from git to be automated as well. So what is a good solution to these problems? Perhaps it would be cool to build some git/maven/lancet aware infrastructure to do this refreshing of deps, building the deps, and building up the classpath. It may also be good to configure .emacs to be able to load projects and rebuild the classpath dynamically based on lancet build files - much in the way that intelliJ or eclipse load projects from ant .builds or maven poms. Is all this too much, am I missing something that already exists? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
Behaviour of clojure.core/print and clojure.core/println
Hello, While trying to create a very small Hello world demonstration to a friend, I saw that (print) and (println) are concatenating their arguments with spaces interposed. I thought at first (println a) was a shorter variant of (.println *out* a) and (println a b c) of (doseq [str [a b c]] (.println *out* str)) but it's not the case. Maybe this could be pointed out in the docs ( that print and println interpose a space between their arguments) ? Regards, -- Laurent --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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: DISCUSS: clojure.contrib.java-utils/as-str
On Apr 10, 2009, at 3:55 AM, Eric Tschetter wrote:
Sure enough, I get the same results
user= (defn as-str
[ args]
(apply str (map #(if (instance? clojure.lang.Named %) (name %) %)
args)))
#'user/as-str
user= (time (dotimes [i 100] (as-str :a)))
Elapsed time: 416.497348 msecs
nil
user= (time (dotimes [i 100] (as-str :a 1)))
Elapsed time: 1023.526175 msecs
Right, I get numbers in the same ballpark on my machine.
Apparently
(defmacro as-str3 [ args]
(cons 'str (map #(if (instance? clojure.lang.Named %) (name %) %)
args)))
runs as fast (or minusculy faster) than the original version that
you posted:
user= (defn as-str2
With no args, returns the empty string. With one arg, returns its
name
or string representation. (as-str nil) returns the empty string. With
more than one arg, returns the concatenation of the as-str values of
the
args.
{:tag String}
([] )
([x]
(if (instance? clojure.lang.Named x)
(name x)
(str x)))
([x ys]
(let [sb (StringBuilder. #^String (as-str x))]
(doseq [y ys]
(.append sb (as-str y)))
(.toString sb
user= (time (dotimes [i 100] (as-str2 :a)))
Elapsed time: 29.844296 msecs
user= (time (dotimes [i 100] (as-str2 :a 1)))
Elapsed time: 1046.465682 msecs
The occurrences of as-str near the bottom of the the definition of
as-str2 should be as-str2 instead.
Also it seems to take a few repetitions of the dotimes call for the
time to settle down and become fairly consistent. In all my timings,
I've given what appears to be a representative run, not the first run.
With the corrected as-str2, I'm getting numbers like these on my
machine:
user= (time (dotimes [i 100] (as-str2 :a)))
Elapsed time: 28.319 msecs
user= (time (dotimes [i 100] (as-str2 :a 1)))
Elapsed time: 325.617 msecs
user= (defmacro as-str3 [ args]
(cons 'str (map #(if (instance? clojure.lang.Named %) (name %) %)
args)))
nil
user= (time (dotimes [i 100] (as-str3 :a)))
Elapsed time: 28.533794 msecs
nil
user= (time (dotimes [i 100] (as-str3 :a 1)))
Elapsed time: 260.311017 msecs
That turns out not to be the same test. The macro as-str3 gets fully
expanded at macro expansion time. At runtime, what you're iterating is
the expansion:
user= (as-str3 :a)
a
user= (macroexpand '(as-str3 :a))
(str a)
For literal arguments to as-str3 (as we've used in the micro-
benchmark), doing the operation at macro expansion time is a win. In
the general case, though, we need the as-str facility to evaluate its
arguments:
user= (def i :a)
#'user/i
user= (as-str2 i)
a
user= (as-str3 i)
i
Mapping across the arguments needs to be done at runtime (which in
this case means it will be done a million times), not macro expansion
time (which in this case means it will be done once).
Which seems to indicate that apply is actually what is slow...
Using apply appears to be a somewhat slower than a direct call:
user= (time (dotimes [i 100] (str a b c d)))
Elapsed time: 437.493 msecs
user= (time (dotimes [i 100] (apply str [a b c d])))
Elapsed time: 731.039 msecs
user= (time (dotimes [i 100] (apply str a b [c d])))
Elapsed time: 1061.53 msecs
user= (time (dotimes [i 100] (apply str a b c d [])))
Elapsed time: 1301.953 msecs
However, the big difference you saw was the macro difference described
above.
--Steve
smime.p7s
Description: S/MIME cryptographic signature
Re: Question about metadata on map keys
On Apr 10, 12:14 am, Jason Wolfe jawo...@berkeley.edu wrote: ... Namely, if a map already contains a given key, when you attempt to assoc in a version of the key with new metadata this is not recorded. It seems that the map always retains the original key: ... Is this desired behavior? If so, is there a better way to change the metadata on a key than first dissoc-ing it out and then assoc-ing it back in again with new metadata? Probably this is expected, since metadata is defined not to affect equality, and maps rely on equality semantics. I would recommend against storing metadata on map keys. In general, if the metadata matters for the value of an object, then it shouldn't be metadata. Some alternatives: 1) put the information directly in the map values; 2) store metadata on the map values; 3) use maps as keys. -Stuart Sierra --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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: set-system-properties
On Apr 9, 10:48 pm, Stuart Halloway stuart.hallo...@gmail.com wrote: Yes to almost all of this (r662). I am not totally comfortable with the false/false conversion. Cool. I'm not crazy about false/false either, since it's not symmetric. -Stuart --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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: Has anyone on this group ever tried Forth?
Hi, I confirm. Factor deserves a look: it's a genuine combination of the Common Lisp world (homoiconic, macros, CLOS) and the Smalltalk RAD created by mixing Self and Forth. Plus there's concurrency support and native code compilation. I always liked concatenative programming I discovered 15 years ago with HP RPN calculator and PostScript (on NeXT). I think the data first design of stack-based languages is good for XP. For altaic languages' speakers (korean, japanese, turkish), it's near their way to construct sentences (like Smalltalk for SVO group). Writing R.E.P.L. is more beautiful than writing (L (P (E (R because you don't have to look at the whole code to find out the data (near the R here) but you start with it (you know what? before knowing how?). (I say that but I am a bit addict to prefix ASTs by force of habit with SBCL or Clojure.) -- Martial At Fri, 10 Apr 2009 17:05:21 +0930, Antony Blakey wrote: On 10/04/2009, at 4:43 PM, CuppoJava wrote: Hi everyone, I was browsing through webpages and the language Forth caught my eye. Reading through it's supposed advantages it sounded very interesting, and I was wondering if anyone here has any experience with it, and can comment. I'm asking on the Clojure forum instead of the Forth forum because I agree with the programming values that Clojure emphasizes, and would like to hear opinions from people with similar values to myself. I'm most interested in it's productivity aspect. (ie. how quick can I get real work done) If you are interested in Forth you should probably check Factor at http://factorcode.org/ Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 It is no measure of health to be well adjusted to a profoundly sick society. -- Jiddu Krishnamurti --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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: Question about metadata on map keys
I think you misunderstand, I don't think he is expecting to being able
to use :foo as a key twice with different metadata.
I think he wants something like:
(def x {[:a] 1 [:b] 2})
then
(meta (first (keys (assoc x (with-meta [:a] {:x 1}) 2
;(- (assoc x (with-meta [:a] {:x 1})) keys first meta)
would be {:x 1}, instead of nil
On Fri, Apr 10, 2009 at 7:09 AM, Stuart Sierra
the.stuart.sie...@gmail.com wrote:
On Apr 10, 12:14 am, Jason Wolfe jawo...@berkeley.edu wrote:
...
Namely, if a map already contains a given key, when you attempt to
assoc in a version of the key with new metadata this is not recorded.
It seems that the map always retains the original key:
...
Is this desired behavior? If so, is there a better way to change the
metadata on a key than first dissoc-ing it out and then assoc-ing it
back in again with new metadata?
Probably this is expected, since metadata is defined not to affect
equality, and maps rely on equality semantics. I would recommend
against storing metadata on map keys. In general, if the metadata
matters for the value of an object, then it shouldn't be metadata.
Some alternatives: 1) put the information directly in the map values;
2) store metadata on the map values; 3) use maps as keys.
-Stuart Sierra
--
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
To unsubscribe from 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: Enlive questions
This is great. I had thought that supporting some kind of partial template thing would be interesting, but that's actually just my poor logic at work ;) It seems like with the new version of Enlive I could do something like this: (deftemplate pageA-template path [] [[:div (attr? :tiptree:replace)]] (fn [xml-node] (find-the-widget-html-file-that-corresponds-to-a-certain-attr-and-return-as-result))) (deftemplate pageB-template path [] [[:div (attr? :tiptree:replace)]] (fn [xml-node] (find-the-widget-html-file-that-corresponds-to-a-certain-attr-and-return-as-result))) (def pageAPartial (pageA-template)) (def pageBPartial (pageB-template)) ;; the following would work only if templates allowed passing html as strings and not just as files (deftemplate widgetsPageA pageAPartial [map] [[:div (attr? :tiptree:widget)]] (fn [xml] (use-xml-attr-and-map-to-apply-and-return-a-snippet)) (deftemplate widgetsPageB pageBPartial [map] [[:div (attr? :tiptree:widget)]] (fn [xml] (use-xml-attr-and-map-to-apply-and-return-a-snippet)) (def pageA (widgetsPageA someMap)) (def pageB (widgetsPageA someMap)) Considering the above, I'm left wondering if it's possible to further eliminate these redundancies and make templates more reusable. I'm not sure if this is what you had in mind for Enlive, but allowing templates to be created without references to files would make it possible to build very, very composable interfaces. Of course it's quite possible that you can already do this with Enlive and I'm just unclear about how to accomplish it. David On Wed, Apr 8, 2009 at 8:06 PM, Christophe Grand christo...@cgrand.netwrote: Hi Tom, I'm sorry for this misfeature and, rejoice, it's gone from the ongoing redesign, there's now an explicit 'content function. The tildes are gone too! Christophe Tom Hickey a écrit : Hi Christophe, I keep running into the same problem with elements getting replaced. I'm trying to set the content of an element with raw html (from a snippet) and unable to avoid both 1) the html getting escaped and 2) the element getting replaced. I can avoid one or the other, via escaped or text, just not both. I'm looking forward to see what you've got planned for the redesign, as I'd really like to see this feature go away. Cheers, Tom On Mar 20, 3:59 am, Christophe Grand christo...@cgrand.net wrote: Phil Hagelberg a écrit : But I did notice you have the use test-is line commented out in the implementation; it seems a bit unfortunate to have to uncomment that to run the tests and hope you remember to re-comment it before you commit. The last commit was during the transition to lazy-seq and test-is was broken. I'll fix that. -- Professional:http://cgrand.net/(fr) On Clojure:http://clj-me.blogspot.com/(en) -- Professional: http://cgrand.net/ (fr) On Clojure: http://clj-me.blogspot.com/ (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 To unsubscribe from 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: Enlive questions
Real quick thought: (deftemplate-generator template-generator [args] rule-vector transform-fn) Would produce a template generator. (def template-name (template-generator path-to-xml-or-file-or-xml-string)) Would produce a real template. (apply str (template-name arg1 arg2 arg3)) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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: Has anyone on this group ever tried Forth?
Factor is a positively amazing language that I've checked out in the past. It has virtually no step-by-step tutorial-like information to teach you the language so you are forced to read source code and raw documentation. While it's documented thoroughly I can't bring myself to try to learn it to any decent extent without some kind of tutorial or something. On Apr 10, 4:32 am, Martial Boniou hond...@gmx.com wrote: Hi, I confirm. Factor deserves a look: it's a genuine combination of the Common Lisp world (homoiconic, macros, CLOS) and the Smalltalk RAD created by mixing Self and Forth. Plus there's concurrency support and native code compilation. I always liked concatenative programming I discovered 15 years ago with HP RPN calculator and PostScript (on NeXT). I think the data first design of stack-based languages is good for XP. For altaic languages' speakers (korean, japanese, turkish), it's near their way to construct sentences (like Smalltalk for SVO group). Writing R.E.P.L. is more beautiful than writing (L (P (E (R because you don't have to look at the whole code to find out the data (near the R here) but you start with it (you know what? before knowing how?). (I say that but I am a bit addict to prefix ASTs by force of habit with SBCL or Clojure.) -- Martial At Fri, 10 Apr 2009 17:05:21 +0930, Antony Blakey wrote: On 10/04/2009, at 4:43 PM, CuppoJava wrote: Hi everyone, I was browsing through webpages and the language Forth caught my eye. Reading through it's supposed advantages it sounded very interesting, and I was wondering if anyone here has any experience with it, and can comment. I'm asking on the Clojure forum instead of the Forth forum because I agree with the programming values that Clojure emphasizes, and would like to hear opinions from people with similar values to myself. I'm most interested in it's productivity aspect. (ie. how quick can I get real work done) If you are interested in Forth you should probably check Factor at http://factorcode.org/ Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 It is no measure of health to be well adjusted to a profoundly sick society. -- Jiddu Krishnamurti --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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: Got a Clojure library?
Rich, Since cl-format/pprint has now moved into contrib, we should remove the existing cl-format entry and replace it with this: Name: pprint URL :http://code.google.com/p/clojure-contrib/ Author: Tom Faulhaber Tags: pretty printing, formatted output, Common Lisp compatibility License: EPL Dependencies: none (outside of contrib) Description: Two parts: 1) A flexible, customizable pretty printer for displaying clojure code and data (and potentially other structured data as well). 2) A fully functional implementation of Common Lisp's crazy powerful format function. cl-format provides a way of producing formatted output in the lisp style in which the format string itself can perform destructuring on the the input arguments rather than having complex iterations and conditionals in your code to do output. Thanks! Tom --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
update-in wildcards?
I have a structure of nested Maps and Vectors as follows:
(def document
{:sections
[{:items
[{:quantity 1}
{:quantity 2}]}
{:items
[{:quantity 3}
{:quantity 4}]}]})
The document has a vector of sections (one, in this case), each
section has a vector of items (two, here).
I want to increment the quantity of every item in every section. The
cleanest solution I've found this far is as follows:
(defn update-item [item]
(update-in item [:quantity] inc))
(defn update-section [section]
(update-in section [:items] (partial map update-item)))
(update-in document [:sections]
(partial map update-section))
I'm not concerned about map turning vectors into seqs.
If update-in supported some kind of wildcard, I could write this:
(update-in document [:sections * :items * :quantity] inc)
Where * is a wildcard, meaning any key.
Does the wildcard idea have any merit? Is there a better way to go
about 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
To unsubscribe from 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: Question about metadata on map keys
Probably this is expected, since metadata is defined not to affect equality, and maps rely on equality semantics. I would recommend against storing metadata on map keys. In general, if the metadata matters for the value of an object, then it shouldn't be metadata. Some alternatives: 1) put the information directly in the map values; 2) store metadata on the map values; 3) use maps as keys. Thanks. I know that maps rely on equality semantics, etc. As Kevin mentioned, I expect the keys with different metadata to be compared equal, and point to the same value; my question is about replacing the metadata on the key for a particular map entry. In case this helps, my use case is as follows. I'm working on search algorithms that manage maps from keys representing reachable states to values representing the cost of reaching those states. When I union two such maps, I retain the minimum value (cost) for each key (state), associng in the new key and its (lower) cost. Now, states have metadata describing the path taken to reach them. I think this is a proper use of metadata, since two states reached by different paths should be considered equal. Then, after unioning some maps, I'd like to be able to retrieve the best path associated with a state by just reading the metadata off the key. The only alternative I can see would be to store the path with the cost in a second map, but this ends up being considerably less elegant. Any other ideas/suggestions? Does this seem like a perverse use of metadata to you? Thanks, Jason --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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: Got a Clojure library?
Hi, Beware there's a repetition of the this word in the definition of cl-format : 2009/4/10 Tom Faulhaber tomfaulha...@gmail.com perform destructuring on the the input arguments rather than having --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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: Has anyone on this group ever tried Forth?
I can't speak for getting real work done, but out of academic / enlightening-in-its-simplicity interest, I think everyone should read Leo Brodie's Starting Forth: http://www.forth.com/starting-forth/sf1/sf1.html On Apr 10, 2:13 am, CuppoJava patrickli_2...@hotmail.com wrote: Hi everyone, I was browsing through webpages and the language Forth caught my eye. Reading through it's supposed advantages it sounded very interesting, and I was wondering if anyone here has any experience with it, and can comment. I'm asking on the Clojure forum instead of the Forth forum because I agree with the programming values that Clojure emphasizes, and would like to hear opinions from people with similar values to myself. I'm most interested in it's productivity aspect. (ie. how quick can I get real work done) Thanks for your opinions -Patrick --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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: Got a Clojure library?
On Apr 10, 2:07 pm, Tom Faulhaber tomfaulha...@gmail.com wrote: Rich, Since cl-format/pprint has now moved into contrib, we should remove the existing cl-format entry and replace it with this: Name: pprint URL :http://code.google.com/p/clojure-contrib/ Author: Tom Faulhaber Tags: pretty printing, formatted output, Common Lisp compatibility License: EPL Dependencies: none (outside of contrib) Description: Two parts: 1) A flexible, customizable pretty printer for displaying clojure code and data (and potentially other structured data as well). 2) A fully functional implementation of Common Lisp's crazy powerful format function. cl-format provides a way of producing formatted output in the lisp style in which the format string itself can perform destructuring on the the input arguments rather than having complex iterations and conditionals in your code to do output. Thanks! Done - thanks for this contribution! Rich --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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: Has anyone on this group ever tried Forth?
It has libraries for freakin' everything. On Apr 10, 1:47 pm, CuppoJava patrickli_2...@hotmail.com wrote: Factor sounds very interesting. But I'm concerned about Slava's decision to run it off his own VM and write his own set of standard libraries. Have you guys ever run into any problems with the lack of libraries? -Patrick --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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: DISCUSS: clojure.contrib.java-utils/as-str
That makes sense.
On Fri, Apr 10, 2009 at 6:16 AM, Stephen C. Gilardi squee...@mac.com wrote:
On Apr 10, 2009, at 3:55 AM, Eric Tschetter wrote:
Sure enough, I get the same results
user= (defn as-str
[ args]
(apply str (map #(if (instance? clojure.lang.Named %) (name %) %) args)))
#'user/as-str
user= (time (dotimes [i 100] (as-str :a)))
Elapsed time: 416.497348 msecs
nil
user= (time (dotimes [i 100] (as-str :a 1)))
Elapsed time: 1023.526175 msecs
Right, I get numbers in the same ballpark on my machine.
Apparently
(defmacro as-str3 [ args]
(cons 'str (map #(if (instance? clojure.lang.Named %) (name %) %) args)))
runs as fast (or minusculy faster) than the original version that you
posted:
user= (defn as-str2
With no args, returns the empty string. With one arg, returns its name
or string representation. (as-str nil) returns the empty string. With
more than one arg, returns the concatenation of the as-str values of the
args.
{:tag String}
([] )
([x]
(if (instance? clojure.lang.Named x)
(name x)
(str x)))
([x ys]
(let [sb (StringBuilder. #^String (as-str x))]
(doseq [y ys]
(.append sb (as-str y)))
(.toString sb
user= (time (dotimes [i 100] (as-str2 :a)))
Elapsed time: 29.844296 msecs
user= (time (dotimes [i 100] (as-str2 :a 1)))
Elapsed time: 1046.465682 msecs
The occurrences of as-str near the bottom of the the definition of as-str2
should be as-str2 instead.
Also it seems to take a few repetitions of the dotimes call for the time
to settle down and become fairly consistent. In all my timings, I've given
what appears to be a representative run, not the first run.
With the corrected as-str2, I'm getting numbers like these on my machine:
user= (time (dotimes [i 100] (as-str2 :a)))
Elapsed time: 28.319 msecs
user= (time (dotimes [i 100] (as-str2 :a 1)))
Elapsed time: 325.617 msecs
user= (defmacro as-str3 [ args]
(cons 'str (map #(if (instance? clojure.lang.Named %) (name %) %) args)))
nil
user= (time (dotimes [i 100] (as-str3 :a)))
Elapsed time: 28.533794 msecs
nil
user= (time (dotimes [i 100] (as-str3 :a 1)))
Elapsed time: 260.311017 msecs
That turns out not to be the same test. The macro as-str3 gets fully
expanded at macro expansion time. At runtime, what you're iterating is the
expansion:
user= (as-str3 :a)
a
user= (macroexpand '(as-str3 :a))
(str a)
For literal arguments to as-str3 (as we've used in the micro-benchmark),
doing the operation at macro expansion time is a win. In the general case,
though, we need the as-str facility to evaluate its arguments:
user= (def i :a)
#'user/i
user= (as-str2 i)
a
user= (as-str3 i)
i
Mapping across the arguments needs to be done at runtime (which in this case
means it will be done a million times), not macro expansion time (which in
this case means it will be done once).
Which seems to indicate that apply is actually what is slow...
Using apply appears to be a somewhat slower than a direct call:
user= (time (dotimes [i 100] (str a b c d)))
Elapsed time: 437.493 msecs
user= (time (dotimes [i 100] (apply str [a b c d])))
Elapsed time: 731.039 msecs
user= (time (dotimes [i 100] (apply str a b [c d])))
Elapsed time: 1061.53 msecs
user= (time (dotimes [i 100] (apply str a b c d [])))
Elapsed time: 1301.953 msecs
However, the big difference you saw was the macro difference described
above.
--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
To unsubscribe from 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: Has anyone on this group ever tried Forth?
J seems cool, and, from what I understand, is a descendant of forth. How does Factor compare to J? Rayne, what is it forth or Factor? I know J has awesome documentation . . . but I still haven't taken the time for it. Lotta languages on the list, but I need one from that category. I guess it's two categories, really: stack-based, and array-processing right? On Fri, Apr 10, 2009 at 10:12 PM, Rayne disciplera...@gmail.com wrote: It has libraries for freakin' everything. On Apr 10, 1:47 pm, CuppoJava patrickli_2...@hotmail.com wrote: Factor sounds very interesting. But I'm concerned about Slava's decision to run it off his own VM and write his own set of standard libraries. Have you guys ever run into any problems with the lack of libraries? -Patrick --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from 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: Question about metadata on map keys
On Apr 10, 3:54 pm, Jason Wolfe jawo...@berkeley.edu wrote:
In case this helps, my use case is as follows. I'm working on search
algorithms that manage maps from keys representing reachable states to
values representing the cost of reaching those states. When I union
two such maps, I retain the minimum value (cost) for each key (state),
associng in the new key and its (lower) cost. Now, states have
metadata describing the path taken to reach them. I think this is a
proper use of metadata, since two states reached by different paths
should be considered equal. Then, after unioning some maps, I'd like
to be able to retrieve the best path associated with a state by just
reading the metadata off the key.
The only alternative I can see would be to store the path with the
cost in a second map, but this ends up being considerably less
elegant. Any other ideas/suggestions? Does this seem like a perverse
use of metadata to you?
Not necessarily perverse, but perhaps a little twisted. :)
I'd probably do it using two maps, or one map with composite values
like
{:path ..., :cost ...}.
Or... the cost will be entirely dependent on the path, right? So make
cost a function, memoize it, and you only need to store the paths.
-Stuart Sierra
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Clojure group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---
