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 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
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 wrote: > On Thu, Apr 9, 2009 at 11:34 AM, Stuart Sierra > wrote: > > > > > > > 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 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 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 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
wrote:
>
> On Apr 10, 12:14 am, Jason Wolfe 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 wrote: > > 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 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 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: Has anyone on this group ever tried Forth?
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
> 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 > > > 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 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 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 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 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 wrote: > > It has libraries for freakin' everything. > > On Apr 10, 1:47 pm, CuppoJava 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 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
-~--~~~~--~~--~--~---
Re: Has anyone on this group ever tried Forth?
Martial Boniou 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.) > > > If you really wanted R.E.P.L style coding, it is possible in clojure using the -> macro (kinda neat, if you ask me). If I am not mistaken, the big difference between Forth and Factor is the presence of quotations in Factor which it inherited from Joy, I guess. Quotations, makes it possible to have something like first class functions in a stack language world. Expressiveness-wise, the main difference I see between "conventional" languages and concatenative languages is the idea of being able to wrap a piece of code in an 'environment' of execution determined outside its immediate surrounding scope. In a conventional language you would have function parameters (in the immediate outside scope of the function) as the key way to modify the behavior of a function. In concatenative languages the argument to a quotation on a stack can be expressed differently and arguably fairly independently. Note that it might be possible to get some of the same expressiveness using a concept like clojure's "binding" and judicious use of global variables... in such a case, factor only buys you anonymous global variables potentially avoiding naming conflicts ;). pinocchio P.S. The argument about expressiveness is generally very subjective besides some glaring violations (dare I bring C++... ;) ). P.S(2). Disclaimer: haven't done any programming in stack based languages. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
