Re: Lisp/Clojure doesn't have syntax?
On Dec 11, 3:58 pm, Randall R Schulz wrote:
> On Thursday 11 December 2008 13:47, Sean Spencer wrote:
>
> > That was one of the best explanations of code as data I've ever read.
> > Kudos!
>
> Thanks. You forced me to look up the reference to which I alluded:
>
> On Thursday 11 December 2008 06:32, evins.mi...@gmail.com wrote:
>
> > Subject: Re: In core structure editor, anyone?
>
> > Structure editors are not in common use, maybe because, while they're
> > a valid and maybe cool alternative to text editors for lisp code,
> > it's not clear how useful they are for other kinds of code. In most
> > programming languages a lexer and parser construct an abstract syntax
> > tree from the source code. In lisp, the abstract syntax tree *is* the
> > source code. That being the case, it makes a lot of sense with lisp
> > to operate directly on the parse tree. In other languages, not so
> > much.
>
> So the kudos go to Mikel Evins (or is it Evins Mikel?).
Thanks.
It's mikel evins. GMail somehow arranged a few years ago to make my
preferred account name ("mikel") and my second choice ("mikelevins")
and my third choice ("mikel.evins") inaccessible to me. I haven't
bothered to understand what the problem is.
--~--~-~--~~~---~--~~
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: throw-if with no exception class
Hi Rich, I am very interested in your view of the world - why are 'checked' exceptions evil? Thanks -Ralf On Thu, Dec 11, 2008 at 2:08 PM, Rich Hickey wrote: > > > > On Dec 10, 10:52 pm, "Stephen C. Gilardi" wrote: > > On Dec 10, 2008, at 4:38 AM, Ralf Bensmann wrote: > > > > > Being a Java trainer for a long time, we talk with students about > > > the "handle-or-declare rule" in Java and the two types of > > > exceptions: "checked" (declared) and "unchecked" (runtime). So I > > > prefer using a RuntimeException because no exception was specified. > > > > I'm inclined to accept the recommendation to make RuntimeException the > > default. I see that Clojure's Java source code uses both. It seems to > > me that within Clojure, the distinction doesn't matter, but in the > > case of Java interop, RuntimeExceptions would be more in keeping with > > what Clojure's "never declare them" philosophy. > > > > Does anyone have any more advice on this? > > > > Clojure doesn't have 'checked' exceptions. They are a bad idea, and a > misfeature of Java, bad enough with interfaces but completely > incompatible with closures. As a result of the flawed logic that has > grown up around this misfeature, in Java you might choose between > checked and non-checked based on whether you thought a caller could do > anything about it - if not, use unchecked, thus making your method one > that didn't require explicit handling. > > Given that there are no 'checked' exceptions in Clojure, the > distinction is moot, except in the case of Java interop, where, at > least through the IFn interface, all Clojure calls declare Exception. > RuntimeException is a particularly dubious notion, a special exemption > granted to those exceptions the Java runtime might throw, created in > acknowledgment of the insufferable pain it would cause to use the > checked exception system for those. If it were a fixed set it would be > one thing - every caller could expect one of those (enumerated, > documented) exceptions, or a declared one. But RuntimeExceptions are > an open set - it's just plain goofy. > > Clojure's Java code throws explicit RuntimeExceptions only in those > places where the checked exception system precludes it from letting an > Exception flow out, and it pains me every time. > > I guess my recommendation is, if there is an existing exception type > (checked or unchecked) that roughly matches your problem, throw that, > else throw Exception. In this case, perhaps the default should be > IllegalArgumentException. > > 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: In core structure editor, anyone?
On Dec 11, 12:39 pm, TNeste wrote: > On Dec 10, 2:15 pm, Simon Brooke wrote: > > > I note people seem mainly to be using Emacs as an editing/development > > environment for Clojure. But as people keep pointing out, Clojure is > > homoiconic; the canonical source of a function is not a stream of > > bytes read from a file, but is a structure in core. > > > Now, in-core editing does raise some issues - there needs to be some > > means of associating the structure which is the canonical source of a > > function with the function itself, so that when the user invokes (edit > > froboz) (or (edit 'froboz), or whatever), the source structure for > > froboz is displayed in the editor. But in-core structure editors are > > extremely powerful and useful when editing homoiconic languages, so... > > is anyone working on an in-core editor for Clojure? > > Do you mean structured editing combined with image based development? > I haven't really looked that closely at the old Interlisp documents > but I suppose the source code is managed the same way it is in most > Smalltalk systems but I have always been a bit puzzled about how that > works with Lisp. > > In Smalltalk it is fairly straightforward since there is an obvious > mapping from classes and methods to source code. With lisp it is not > that simple as there is no limit to the syntactic forms that the user > might want to query and edit in different forms. For example, if I > have (define-foo my-foo ...) macro that is used to define some complex > function named my-foo what happens when I do (edit 'my-foo)? Do I get > the original define-foo form or the macroexpansion? What about when > define-foo does something more complex like defines a bunch of methods > and datastructures or binds my-foo to a closure? There needs to be > mechanism that associates evaluated forms with the name(s) of the > resulting object(s) and it probably couldn't, in general, be done > automatically. Depends. Using a decent lisp environment nowadays, the lisp will remember the files and line numbers for all the forms it has read, so you can get those back pretty easily, as long as you don't turn that feature off, and as long as you have those text files. If you don't have the original text, but only the data produced from it by the reader and compiler, then the best you can usually do is some plausible lisp forms that correspond to what's in memory--generally a bunch of fully-expanded s-expressions that don't look all that much like code a human would write. It'll be accurate, but not necessarily congenial. In older Lisp systems, like Interlisp and Genera, the systems remembered absolutely everything about how a given hunk of data was created, including versions of everything, including mouse-and-window direct-manipulation operations, so you could view the contents of a structure editor in any form you found convenient. --~--~-~--~~~---~--~~ 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: Swing GUI Builder and Clojure
2008/12/12 wubbie > > Hi, > The same hello world did not work for me. > The error msgs are: > (defn hello-world [] > (qt4 > (let [app (QCoreApplication/instance) > button (new QPushButton "Go Clojure Go")] > (.. button clicked (connect app "quit()")) > (doto button > (resize 250 100) > (setFont (new QFont "Deja Vu Sans" 18 (.. QFont$Weight Bold > value))) > (setWindowTitle "Go Clojure Go") > (show) > java.lang.Exception: Unable to resolve symbol: resize in this context > (NO_SOURCE_FILE:44) > > Hi, Depending on which version of Clojure you are using you may find that you need to change: (doto button (resize 250 100)) to: (doto button -- Geoffrey Teale Freelance Software and Technology Consultant Munich, Germany --~--~-~--~~~---~--~~ 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: Swing GUI Builder and Clojure
2008/12/12 Geoffrey Teale > >> > Hi, > > Depending on which version of Clojure you are using you may find that you > need to change: > > (doto button > (resize 250 100)) > > to: > > (doto button > Argh.. goddam google mail... I meant to say: (doto button (.resize 250 100)) Note the additional dot in the notation. There are a number of gotchas using QtJambi with post AOT versions of Clojure. I have spent a few weekends converting a program. I will blog when my code reaches a useful stage and my current Qt branch is checked into github. -- Geoffrey Teale Freelance Software and Technology Consultant Munich, Germany --~--~-~--~~~---~--~~ 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: defining keywords ?
On Dec 11, 9:08 pm, Chouser wrote: > On Thu, Dec 11, 2008 at 7:49 PM, Robert Koberg wrote: > > > Hi, > > > Would it be desirable to further define keywords such that it allows a > > special kind of namespacing. > > > * This could allow for more efficient (for the user) and targeted > > navigation over large, nested collections. > > * It would allow for mixing related data that might need to be treated > > in different ways. > > * It could provide the building blocks for a collection transformation > > language > > > For example: > > > :keyword or :nil:keyword - defines a keyword in a null namespace > > -- keeps backward compatibility > > -- equivalent to the XML element (no namepsace defined) > > > ::keyword - defines a namespaced keyword in a default namespace > > -- equivalent to the XML element http://some/namespace"/> > > > :myns:keyword - defines a namespaced keyword in a named namespace > > -- equivalent to the XML element http://some/namespace > > "/> > > > Perhaps a requirement for this type of thing would be that the > > namespaces need to be declared on the root element of the (nested) > > collection. > > Keywords can already be namespace-qualified: > > user=> (namespace :foo) > nil > user=> (namespace :my-ns/foo) > "my-ns" > user=> (namespace ::foo) > "user" > > The idea of using this feature to specify XML namespaces has been > discussed. Rich even adjusted the reader rules to allow fully-qualified > URLs as namespaces: > > user=> (namespace :http://n01se.net/chouser/tag) > "http://n01se.net/chouser"; > > This should allow something to parse XML and produce a tree of Clojure > collections representing it with full namespace qualifications, though to my > knowledge this hasn't been done yet. It would be a convenience for some of my work if it were legal to do (derive :foo :bar) using unqualified keywords. I don't know enough yet about Clojure to know what that might break. In Common Lisp, the text ":FOO" is guaranteed always to be turned into a reference to the exact same keyword object, a symbol in the KEYWORD package whose name is "FOO"; I don't know what the rules are in Clojure about keywords without namespaces. Perhaps they're like uninterned symbols; I don't know. I'm building a type system for classifying lots of hunks of data and selecting appropriate operations for them, and derive is nice for that, but it's a minor inconvenience to have to namespace-qualify all those typenames. It's nice that I *can* qualify them by namespace; it isn't always nice that I *have* to. That said, it doesn't prevent me from getting anything done, it's just a sort of pebble in my shoe sometimes. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
distributing a cliojure application as .jar - guide
Hello, What is the position on distributing clojure classes with user application classes in single .jar file. Is including the license for clojure in the .jar as a text file enough? I would like to amend: http://en.wikibooks.org/wiki/Clojure_Programming/Tutorials_and_Tips section 1.9 so the "the right stuff" happens from licensing and distribution point of view... Kind regards, Vlad --~--~-~--~~~---~--~~ 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: jEdit Mode for Clojure
If anyone on this thread is interested I uploaded clj-jedit.tar.gz to the group file section on an incomplete jedit plugin for clojure. It has the hilighting, repl, and namespace browser (courtesy of enclojure) - anyone want to take it on and improve it, I don't have time right now?? It was based on the scheme plugin. bd On Thu, 11 Dec 2008 17:30:37 -0800 (PST) Daniel Spiewak wrote: > > I merged in all the interesting stuff from David Moss's Clojure jEdit > mode. We do highlight things in very different colors, but all of the > elements that his recognizes are also recognized by mine now. Also, I > fixed the annoying issue with def: > > (def this)(def that) > > The above now highlights correctly. > > Feedback is welcome. I'm certainly willing to change the way things > are highlighted, add highlighting or remove it. > > Daniel > > On Dec 11, 2:58 pm, Daniel Spiewak wrote: > > > Hi, just saw this thread. I had made some modifications to the > > > edit mode and uploaded it for inclusion (as a patch) > > > here:http://sourceforge.net/tracker/index.php?func=detail&aid=2201893&grou... > > > . > > > > > I haven't checked the status in a while as my internet is very > > > intermittent ATM. Please let me know if there is anything missing > > > from it or if I can in any way enhance the mode. > > > > I'll have to take a closer look at your new version. We probably > > should merge our efforts. Your mode does do some things that mine > > doesn't, and it doesn't really benefit anyone to have three > > competing Clojure modes. :-) My mode is pretty convoluted in the > > way it uses some tricks to highlight things like (def > > blah), so it's probably easier if I steal your improvements and > > merge them into mine. I'll give that a try later today and post > > back with the results. > > > > Daniel > > -- None are more hopelessly enslaved than those who falsely believe they are free — Goethe --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
distributing a clojure application as self contained .jar - guide
Hello, What is the position on distributing clojure classes with user application classes in single .jar file. Is including the license for clojure in the .jar as a text file enough? I would like to amend: http://en.wikibooks.org/wiki/Clojure_Programming/Tutorials_and_Tips section 1.9 so the "the right stuff" happens from licensing and distribution point of view... Kind regards, Vlad --~--~-~--~~~---~--~~ 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: Swing GUI Builder and Clojure
Swing - as it comes built in with java Vlad --~--~-~--~~~---~--~~ 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: Emacs / Slime questions
On Sun, Dec 7, 2008 at 12:24 PM, Bill Clementson wrote: >> 3. If something in the REPL is running in an infinite loop, how do I >> interrupt evaluation? > > C-c C-c usually works for me (not sure about Windows) This isn't working for me on Clojure Box in Windows. Can anyone else tell me a way to interrupt evaluation of the REPL? Thanks! Mark --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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 -~--~~~~--~~--~--~---
Best style for internal variables
Sometimes you use mutable state inside of a function to do some local temporary computation, and this state will never be visible outside of the function. So externally speaking, the function is still a pure function. Vars, Refs, and Atoms all seem to be reasonable choices for representing this kind of state. What is the preferred style? For example, imagine you want to write the factorial function the imperative way. Here are some options: ; functional way for reference (defn fact0 [n] (reduce * 1 (range 1 (inc n ; use var (defn fact1 [n] (with-local-vars [total 1] (doseq [i (range 1 (inc n))] (var-set total (* @total i))) @total)) ;use ref (defn fact2 [n] (let [total (ref 1)] (doseq [i (range 1 (inc n))] (dosync (ref-set total (* @total i @total)) ;use atom (defn fact3 [n] (let [total (atom 1)] (doseq [i (range 1 (inc n))] (swap! total #(* % i))) @total)) Now I don't have a sufficiently recent build to test the atom version myself, but I tested the others. The var version has a running time comparable to the functional version. The ref version starts out noticeably slower, but after a few runs, hotspot gets it to where it runs almost as fast as the other two versions. I imagine the atom performance would be somewhere between the var and ref performance. I'd be interested in hearing the details of atom performance from someone who can test that, but really, it seems like the performance is fairly similar here. It becomes a question of style, mostly. What do you guys think is the best style (assuming you really want to code something internally in an imperative way)? It is also instructive to compare the syntax of the three imperative versions. I find it odd how similar, and yet different they each are. I find it especially odd how you need with-local-vars to create a local var, rather than something like (let [total (var 1)]) which would be more consistent with the other methods. Granted, vars have some pretty bizarre semantics (for example, if you DID try to return a var outside of the function, or use it in a lazy-cons, you get weird results because the var essentially loses its binding outside of its lexical scope). I'm guessing that's the point of with-local-vars syntax -- to flag that it's invalid outside of that block. But still, it seems rather quirky. I think I'd prefer local vars to be more consistent with ref syntax. That said, it seems to me like the var version is the best fit for hidden imperative behavior. The transactional nature of ref is clearly unnecessary here, and the swapping behavior of atom only makes sense when multiple threads might be competing to alter atom. Any other opinions? --Mark --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: Swing GUI Builder and Clojure
Hello Rock, > Does anyone know of such a possibility? And, if not, what are the > chances of coming up with a tool like that? I'm not a Java nor a Swing > expert, so I haven't the faintest clue as to what the difficulties may > be. There is such a tool for jruby (which I tried for a basic gui) called monkeybars: http://monkeybars.rubyforge.org/ It would be a perfect candidate for borrowing the concept and approach... Basically, one uses netbeans (but it is not tied to netbeans) swing gui builder to define the gui, the monkeybars does the plumbing and the programmer uses jruby to do the programming in ruby... Kind regards, Vlad PS: The jruby is ruby language implementation running on java virtual machine... --~--~-~--~~~---~--~~ 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: Lisp/Clojure doesn't have syntax?
On Dec 12, 1:35 am, Mon Key wrote: > > Clojure does not allow for programmer-defined > > reader macros (unlike other lisps). > > I know this has been touched upon last Spring - and Stu Halloway refs > at least one discussion of this in his book. > > From a practical standpoint I am beginning to understand more why the > choice was made to not support reader macros. > > But can someone (RH?) clarify the following? > > Is it possible to introduce reader macros (albeit unsupported frowned > upon ones). > > > You could define a different reader and completely different text-based > > syntax for the language. > > Given the suggestion that Clojure could potentially be reimplemented > with a different text-based syntax utilizing an alternate reader does > this imply that reader macros are possible under a modified REPL?. > > From a purely speculative standpoint, if this is possible - the > assertion that "Clojure does not allow for..." may be misplaced. > > I'm wondering to the extent that it *may* be possible to 'Rig the > REPL' where would/does the Clojure license stand on this? > > I ask, because I remember reading in one of P. Graham's books '.* > LISP' that some commercial LISPs were/are distributed with exceptions > for calling `eval' at the top level - presumably to prevent one from > modifying the REPL with some combination of macros/reader macros. > > Has Clojure taken an alternate approach whereby code distributed under > license simply doesn't permit user defined reader macros? > > And if so - would it not be more appropriate to communicate (as a > matter of policy - and stakeholder prudence) - "The Clojure License > agreement doesn't *permit* user introduction of reader macros which > when expanded at compile time attempt to modify the designer(s) > intended specification of Clojure's REPL"? > > I tend to recoil at the use of the phrase, "not allowed", and while > I'm not personally even remotely capable of even beginning an attempt > to endeavor to introduce any sort of modification as envisioned above > I can certainly imagine situations/environments where such an attempt > might be made - advocate(s) of competitive open source license models > being one of the more benign examples... > > If I have mis-characterized something or have otherwise misunderstood > the situation/possibilities I apologize. > I'm not going to rehash reader macros or licensing again - they've been discussed here at length, except to say the two are unrelated. The license doesn't say anything about the reader or repls - it's the standard CPL. People are going to put their Clojure programs in text files they expect to be read by the standard reader and evaluated, and it is a design goal of Clojure that programs by different people be able to be combined. User-defined reader macros don't compose, they clash. If you did so under Clojure's license, you could make a version of Clojure with a modified reader - the reader source is there. But the programs you wrote to your version of the reader would be incompatible with those written by someone else who did the same thing. So, it has less to do with technical or licensing issues than it has to do with it being a bad idea, if you don't want to encourage programmers to create islands. CL has this feature and it is very rarely used for that exact reason - programs that require custom reader macros are a pain. People have mentioned wanting to use the reader to read programs in other languages or data formats, and while I'm not generally opposed to the idea of a data reader whose output is not destined for the compiler, I'm also skeptical of the generality of such a thing. A lisp- style reader is a page or two of Clojure code. People are making parser combinator libs etc. There are ways to solve this problem without making the standard reader fungible, with the added complexity of providing an API and semantics for reader macros, and permanently leaving characters available for customization that that entails. If you want to modify the reader to create syntax for yourself, convince me and the community that the syntax has wide utility and I'll consider putting it in the standard reader so everyone can use it portably. 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: Best style for internal variables
On Fri, Dec 12, 2008 at 7:10 AM, Mark Engelberg wrote: > > Sometimes you use mutable state inside of a function to do some local > temporary computation, and this state will never be visible outside of > the function. So externally speaking, the function is still a pure > function. Vars, Refs, and Atoms all seem to be reasonable choices for > representing this kind of state. What is the preferred style? > > For example, imagine you want to write the factorial function the > imperative way. Here are some options: > > ; functional way for reference > (defn fact0 [n] > (reduce * 1 (range 1 (inc n > > ; use var > (defn fact1 [n] > (with-local-vars [total 1] >(doseq [i (range 1 (inc n))] (var-set total (* @total i))) >@total)) > > ;use ref > (defn fact2 [n] > (let [total (ref 1)] >(doseq [i (range 1 (inc n))] (dosync (ref-set total (* @total i >@total)) > > ;use atom > (defn fact3 [n] > (let [total (atom 1)] >(doseq [i (range 1 (inc n))] (swap! total #(* % i))) >@total)) > > Now I don't have a sufficiently recent build to test the atom version > myself, but I tested the others. The var version has a running time > comparable to the functional version. The ref version starts out > noticeably slower, but after a few runs, hotspot gets it to where it > runs almost as fast as the other two versions. I imagine the atom > performance would be somewhere between the var and ref performance. > I'd be interested in hearing the details of atom performance from > someone who can test that, but really, it seems like the performance > is fairly similar here. It becomes a question of style, mostly. What > do you guys think is the best style (assuming you really want to code > something internally in an imperative way)? > > It is also instructive to compare the syntax of the three imperative > versions. I find it odd how similar, and yet different they each are. > I find it especially odd how you need with-local-vars to create a > local var, rather than something like (let [total (var 1)]) which > would be more consistent with the other methods. Granted, vars have > some pretty bizarre semantics (for example, if you DID try to return a > var outside of the function, or use it in a lazy-cons, you get weird > results because the var essentially loses its binding outside of its > lexical scope). I'm guessing that's the point of with-local-vars > syntax -- to flag that it's invalid outside of that block. But still, > it seems rather quirky. I think I'd prefer local vars to be more > consistent with ref syntax. > > That said, it seems to me like the var version is the best fit for > hidden imperative behavior. The transactional nature of ref is > clearly unnecessary here, and the swapping behavior of atom only makes > sense when multiple threads might be competing to alter atom. Any > other opinions? > Please don't do it. If you really miss your loops, use loop/recur. 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: Lisp/Clojure doesn't have syntax?
On Thu, Dec 11, 2008 at 3:44 PM, Randall R Schulz wrote:
>
> Punctuation is not syntax.
>> Clojure goes on to add a lot of syntax. The literal syntax for
>> vectors [], maps {}, sets #{}, functions #(), keywords :, etc. are
>> all syntax, not possible with macros, and then there are all the
>> "reader macros" that are listed in Section 2.2, Comment ;, Deref @,
>> Meta ^, Metadata #^, regex #"", syntax-quote `, unquote ~,
>> unquote-splicing ~@, and var-quote #'.
>
> All these things are syntactic sugar. Shorthand ways to write things
> that have vanilla S-Expression counterparts. Again, I would not call
> them syntax.
I really have trouble understanding the idea that punctuation and
syntactic sugar shouldn't be considered syntax. To me, syntax is
anything that a human reader has to comprehend in order to understand
the structure of the code. I say "structure" because that excludes
having to understand what every function and macro does.
For example, it is very important for human readers of Clojure code to
understand that ^# adds the metadata that follows to the form that
follows that.
--
R. Mark Volkmann
Object Computing, Inc.
--~--~-~--~~~---~--~~
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: defining keywords ?
On Dec 12, 4:34 am, "evins.mi...@gmail.com" wrote: > On Dec 11, 9:08 pm, Chouser wrote: > > > > > On Thu, Dec 11, 2008 at 7:49 PM, Robert Koberg wrote: > > > > Hi, > > > > Would it be desirable to further define keywords such that it allows a > > > special kind of namespacing. > > > > * This could allow for more efficient (for the user) and targeted > > > navigation over large, nested collections. > > > * It would allow for mixing related data that might need to be treated > > > in different ways. > > > * It could provide the building blocks for a collection transformation > > > language > > > > For example: > > > > :keyword or :nil:keyword - defines a keyword in a null namespace > > > -- keeps backward compatibility > > > -- equivalent to the XML element (no namepsace defined) > > > > ::keyword - defines a namespaced keyword in a default namespace > > > -- equivalent to the XML element http://some/namespace"/> > > > > :myns:keyword - defines a namespaced keyword in a named namespace > > > -- equivalent to the XML element http://some/namespace > > > "/> > > > > Perhaps a requirement for this type of thing would be that the > > > namespaces need to be declared on the root element of the (nested) > > > collection. > > > Keywords can already be namespace-qualified: > > > user=> (namespace :foo) > > nil > > user=> (namespace :my-ns/foo) > > "my-ns" > > user=> (namespace ::foo) > > "user" > > > The idea of using this feature to specify XML namespaces has been > > discussed. Rich even adjusted the reader rules to allow fully-qualified > > URLs as namespaces: > > > user=> (namespace :http://n01se.net/chouser/tag) > > "http://n01se.net/chouser"; > > > This should allow something to parse XML and produce a tree of Clojure > > collections representing it with full namespace qualifications, though to my > > knowledge this hasn't been done yet. > > It would be a convenience for some of my work if it were legal to do > (derive :foo :bar) using unqualified keywords. I don't know enough yet > about Clojure to know what that might break. In Common Lisp, the text > ":FOO" is guaranteed always to be turned into a reference to the exact > same keyword object, a symbol in the KEYWORD package whose name is > "FOO"; I don't know what the rules are in Clojure about keywords > without namespaces. Perhaps they're like uninterned symbols; I don't > know. > > I'm building a type system for classifying lots of hunks of data and > selecting appropriate operations for them, and derive is nice for > that, but it's a minor inconvenience to have to namespace-qualify all > those typenames. It's nice that I *can* qualify them by namespace; it > isn't always nice that I *have* to. > > That said, it doesn't prevent me from getting anything done, it's just > a sort of pebble in my shoe sometimes. Keywords have interned identity semantics, that is, :foo anywhere is the identical object, and :my-ns/foo is a different object. The problem with your (derive :foo :bar) is that it is incompatible with my (derive :bar :foo). Since such derives constitute a global hierarchy, that is prohibited. There are a few things that can mitigate somewhat: 1) ::foo will give you a keyword qualified with the current namespace: user=> ::foo :user/foo 2) namespace qualifiers in keywords can be namespace aliases - :alias/ foo 3) a recent patch lets you define relationships between names without qualifiers in private hierarchies (derive my-hierarchy :foo :bar) I'm thinking about a multimethod enhancement that will let you specify the hierarchy to be used. 4) You can use symbols instead of keywords and get require/use capability. 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: throw-if with no exception class
On Friday 12 December 2008 01:18, Ralf Bensmann wrote: > Hi Rich, > > I am very interested in your view of the world - why are 'checked' > exceptions evil? It's a huge and unending debate (last I checked). It's probably not worth recapping it here. I'm sure there are reams of blogs and email list archives on the 'Net wherein everyone with an opinion on this matter has made that opinion clear (ad nauseum). Instead, let's talk about top-posting, quote-trimming, thread-hijacking, whether the list server should set the Reply-To field or inject a [list-name] tag into the Subject header... > Thanks > -Ralf Randall Schulz --~--~-~--~~~---~--~~ 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: Extending deref
On Dec 12, 2:15 am, "Mark Engelberg" wrote: > If you wanted to extend deref to new types, is there any way to do > that? For example, deref of a delay could be equivalent to a force. > Or deref of a Future could invoke the Future's get method. This would > give you the handy @ reader macro for things that frequently need to > be forced to evaluate further in some way. Right now you can do that by implementing clojure.lang.IRef. It is implemented by refs/agents/var/atoms. I need to refactor it to pull apart the validator stuff, at which point there will be only get(), in a super-interface. Delay used to implement IRef before validators, and will again after this refactoring. The semantics of Future.get() do not match IRef.get(), in that Future.get() can block, so they should not be unified. 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: XML Namespaces :xmlns, was Re: xml/parse
On Thu, Dec 11, 2008 at 8:49 PM, Robert Koberg wrote:
>
> Given an XML structure like:
>
> http://purl.org/dc/elements/1.1/"; >
> http://www.w3.org/1999/xhtml";>
> A HEAD Title
> A BODY Title
>
> http://www.w3.org/1999/xhtml";>
> A HEAD Title
> A BODY Title
>
>
>
> which will be parsed by clojure.xml/parse and converted into a nested
> collection.
>
> How would you find the title elements that need to be treated the same
> (those in the xhtml namespace) and those that need to be treated
> different (those in the dublin core namespace)?
>
> Now assume that you don't know what namespace prefix some XML that is
> not in your control will use.
>
> To an XML parser the fragment at position 1 is basically the same as
> the fragment at position 2. Is this the case in clojure?
Hmmm ... doesn't look like it:
1:37 user=> (clojure.xml/parse "file:///tmp/test.xml")
{:tag :root, :attrs {:xmlns:dc "http://purl.org/dc/elements/1.1/"}, :content [
{:tag :fragment, :attrs {:xmlns:xyz "http://www.w3.org/1999/xhtml"},
:content [
{:tag :dc:title, :attrs nil, :content ["A HEAD Title"]}
{:tag :xyz:title, :attrs nil, :content ["A BODY Title"]}
]}
{:tag :fragment, :attrs {:xmlns:zyx "http://www.w3.org/1999/xhtml"},
:content [
{:tag :dc:title, :attrs nil, :content ["A HEAD Title"]}
{:tag :zyx:title, :attrs nil, :content ["A BODY Title"]}
]}
]}
At least all the info you need to determine their equality is
maintained. I wonder if it would be worthwhile to expand namespace
aliases so that clojure.xml/parse would return something like the
following on this input:
1:37 user=> (clojure.xml/parse "file:///tmp/test.xml")
{:tag :root, :attrs nil, :content [
{:tag :fragment, :attrs nil, :content [
{:tag ::title, :attrs nil, :content
["A BODY Title"]}
]}
{:tag :fragment, :attrs nil, :content [
{:tag ::title, :attrs nil, :content
["A BODY Title"]}
]}
]}
It describes the same XML and has the added benefit that (= # #) is true.
- J.
--~--~-~--~~~---~--~~
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: Emacs / Slime questions
On Fri, Dec 12, 2008 at 6:40 AM, Mark Engelberg wrote: > > On Sun, Dec 7, 2008 at 12:24 PM, Bill Clementson > wrote: > >> 3. If something in the REPL is running in an infinite loop, how do I > >> interrupt evaluation? > > > > C-c C-c usually works for me (not sure about Windows) > > This isn't working for me on Clojure Box in Windows. Can anyone else > tell me a way to interrupt evaluation of the REPL? > > Thanks! > > Mark > It doesn't work for me on Windows either. Maybe my grep skills are lacking, but I can't find where swank-clojure implements the interrupt functionality. If that's the case, you're left with killing the REPL buffer (C-x k) and restarting it (M-x slime). Shawn --~--~-~--~~~---~--~~ 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: Running out of memory when using filter?
On Dec 12, 12:29 am, "Mark Engelberg" wrote: > On Mon, Dec 8, 2008 at 6:51 PM, Rich Hickey wrote: > > I don't have the latest build of Clojure with atoms, so I > reimplemented Rich's filter solution using refs, turning: > > > (defn filter > > [pred coll] > > (let [sa (atom (seq coll)) > > step (fn step [] > > (when-let [s @sa] > > (let [x (first s)] > > (if (pred x) > > (lazy-cons x (do (swap! sa rest) (step))) > > (do (swap! sa rest) > > (recur))] > > (step))) > > into: > > (defn safe-filter > [pred coll] > (let [sa (ref (seq coll)), > step (fn step [] >(when-let [s @sa] > (let [x (first s)] > (if (pred x) >(lazy-cons x (do > (dosync (ref-set sa (rest s))) > (step))) >(do > (dosync (ref-set sa (rest s))) > (recur))] > (step))) > > But splode still splodes!: > > (defn splode [n] > (doseq [i (safe-filter #(= % 20) (map inc (range n)))])) > > Any idea why the ref version wouldn't be working? > Yes, because that is not the same - your version still closes over s. swap! passes a fn to transform the current value, ref-set does not. But alter and commute do: (defn safe-filter [pred coll] (let [sa (ref (seq coll)), step (fn step [] (when-let [s @sa] (let [x (first s)] (if (pred x) (lazy-cons x (do (dosync (commute sa rest)) (step))) (do (dosync (commute sa rest)) (recur))] (step))) > > But it's not pretty. Fortunately, this segues with work I have been > > doing on I/O and generators/streams. > > I'm really looking forward to seeing how this all turns out. Cached > lazy sequences seems to be a bad default for all the standard sequence > operations. You have to be very careful to not retain the head of one > of these sequences (can't give names to intermediate results, for > example), and it's very hard to predict when the head of one of these > sequences might be unintentionally held. This seems to make code more > brittle. Probably the best solution is to default to sequences that > always freshly generate the results, and you have to intentionally > cache the sequence if that is what you want. > I'm appreciate the time you and others have spent on this, and will improve filter, but I'm not sure where you are getting your presumptions about lazy sequences. They are not a magic bullet that makes working with data bigger than memory transparent. They do make it possible in some cases, but that is not their intent. Latent runtime memory consumption is a fact of life of laziness, and is present in Haskell etc. I can make it go away for the specific case of filter and the rest of the library, but not generally. Not caching would let to excessive recalculation in many contexts, and then people would be complaining about performance. There are many benefits of the thread-safe once-and-only-once evaluation promise of lazy-cons that you may not be considering. It is certainly not a bad default. There will soon be a streams/generator library, intended for i/o, that will do one-pass non-cached iteration. It will offer a different set of tradeoffs and benefits, including reduced ease-of use - not being persistent removes a lot of things like first/rest/nth, destructuring etc. But the important thing is tradeoffs/benefits. They always come together. 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: XML Namespaces :xmlns, was Re: xml/parse
On Fri, Dec 12, 2008 at 9:39 AM, Chouser wrote:
>
> On Fri, Dec 12, 2008 at 9:15 AM, J. McConnell wrote:
>>
>> {:tag :root, :attrs nil, :content [
>> {:tag :fragment, :attrs nil, :content [
>>{:tag :
Re: XML Namespaces :xmlns, was Re: xml/parse
On Fri, Dec 12, 2008 at 9:15 AM, J. McConnell wrote:
>
> {:tag :root, :attrs nil, :content [
> {:tag :fragment, :attrs nil, :content [
>{:tag :
Re: XML Namespaces :xmlns, was Re: xml/parse
On Fri, Dec 12, 2008 at 9:49 AM, J. McConnell wrote:
> On Fri, Dec 12, 2008 at 9:39 AM, Chouser wrote:
>>
>> I think it's often desirable to also maintain (somewhere) the original
>> document's shortcut names, and use those where applicable when
>> emitting XML text again.
>
> I agree. Unfortunately, that breaks the equality semantics that some
> would expect. Perhaps we could come up with a way to store the
> original aliases in metadata, since that's really what they are?
Something like:
#^{:xmlns-aliases {:http://purl.org/dc/elements/1.1 :dc}}
{:tag :root, :attrs nil, :content [
#^{:xmlns-aliases {:http://www.w3.org/1999/xhtml xyz}}
{:tag :fragment, :attrs nil, :content [
{:tag :http://purl.org/dc/elements/1.1/title, :attrs nil,
:content ["A HEAD Title"]}
{:tag :http://www.w3.org/1999/xhtml/:title, :attrs nil, :content
["A BODY Title"]}
]}
#^{:xmlns-aliases {:http://www.w3.org/1999/xhtml zyx}}
{:tag :fragment, :attrs nil, :content [
{:tag :http://purl.org/dc/elements/1.1/:title, :attrs nil,
:content ["A HEAD Title"]}
{:tag :http://www.w3.org/1999/xhtml/:title, :attrs nil,
:content ["A BODY Title"]}
]}
]}
- J.
--~--~-~--~~~---~--~~
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: why can't I set! stuff in user.clj?
On Thu, Dec 11, 2008 at 8:28 PM, Stephen C. Gilardi wrote: > > On Dec 11, 2008, at 7:24 PM, Rich Hickey wrote: > >> I am interested in the issues you are trying to address, and thanks >> for volunteering! > > Excellent. You're welcome. > >> I'd like to try to focus our efforts on release 1.0. > > Sounds good. > >> Towards that end, it would be nice if your repl code got more >> exercise, which it probably isn't given existing scripts which run >> clojure.lang.Repl. Maybe it would be useful to have that just call >> clojure.main/repl? > > I think clojure.lang.Repl should translate its args to the new format and > call clojure.main/-main: > > old: clojure.lang.Repl file1 file2 -- a b c > new: clojure.main -i file1 -i file2 -r a b c > > Similarly for clojure.lang.Script: > > old: clojure.lang.Script file1 file2 file3 -- a b c > new: clojure.main -i file1 -i file2 file3 a b c > Ok, so calls to them won't change but they will delegate to main/repl. >> Other than that, I think we should hang on to these ideas post 1.0, >> since adding them now doesn't give us enough time to shake them out. >> Do you have a short list of things in this area that need to be fixed >> for 1.0? > > There are the two things I think need to be fixed for 1.0. (If you're > including [1] below in the set of things you want to defer until post-1.0, > please veto it.) > > [1] Stub launcher written in Java for when clojure.jar contains only source > code: > > - the new clojure.lang.Repl could fill this role, but I think that's not > ideal for 1.0 > > - Better would be to allow this java command line to work: > > java -cp clojure.jar clojure.main ... > >whether or not clojure.jar contains only source code. > > We could do this by writing a clojure/main.java that calls > clojure.main/-main and removing :genclass in clojure/main.clj. I think > that's a simple change that provides an important flexibility for > clojure.jar. Adding a "source_jar" target to build.xml would go hand in hand > with this. Ok. > > [2] A single "-e" or "--eval" option should be allowed to contain multiple > forms and it should evaluate them sequentially. There are cases where > wrapping multiple forms in a "do" does not work and writing > > -e (this) -e (that) -e (the-other) > > is tedious compared to > > -e "(this) (that) (the-other)" > This (-e) seems rather unimportant, but I wonder when does 'do' not work? 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: XML Namespaces :xmlns, was Re: xml/parse
On 12.12.2008, at 15:49, J. McConnell wrote:
>
> On Fri, Dec 12, 2008 at 9:39 AM, Chouser wrote:
>>
>> On Fri, Dec 12, 2008 at 9:15 AM, J. McConnell
>> wrote:
>>>
>>> {:tag :root, :attrs nil, :content [
>>> {:tag :fragment, :attrs nil, :content [
>>> {:tag :
Re: Emacs / Slime questions
On Fri, 12 Dec 2008 09:32:09 -0500 "Shawn Hoover" wrote: > >It doesn't work for me on Windows either. Maybe my grep skills are >lacking, but I can't find where swank-clojure implements the interrupt >functionality. If that's the case, you're left with killing the REPL >buffer (C-x k) and restarting it (M-x slime). > I don't think it's implemented and it's quite an important feature. I tried implementing it but I don't know SLIME very well and failed. Jeffrey, the author of swank-clojure, welcomes contributions, so it would be great if someone with SLIME knowledge implemented it. --~--~-~--~~~---~--~~ 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: Emacs / Slime questions
On Fri, Dec 12, 2008 at 5:31 PM, mehrheit wrote: > > On Fri, 12 Dec 2008 09:32:09 -0500 > "Shawn Hoover" wrote: > > > > >It doesn't work for me on Windows either. Maybe my grep skills are > >lacking, but I can't find where swank-clojure implements the interrupt > >functionality. If that's the case, you're left with killing the REPL > >buffer (C-x k) and restarting it (M-x slime). > > > > I don't think it's implemented and it's quite an important feature. I > tried implementing it but I don't know SLIME very well and failed. > Jeffrey, the author of swank-clojure, welcomes contributions, so it > would be great if someone with SLIME knowledge implemented it. > > > > I recently played around a bit with implementing slime-list-threads, which could be used to interrupt running threads but since my Java is lacking I'm not sure what is the right way to kill runaway threads since that part of the API is (understandably) deprecated. -- tomppa --~--~-~--~~~---~--~~ 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: In core structure editor, anyone?
On Dec 11, 6:39 pm, TNeste wrote: > On Dec 10, 2:15 pm, Simon Brooke wrote: > > > I note people seem mainly to be using Emacs as an editing/development > > environment for Clojure. But as people keep pointing out, Clojure is > > homoiconic; the canonical source of a function is not a stream of > > bytes read from a file, but is a structure in core. > > > Now, in-core editing does raise some issues - there needs to be some > > means of associating the structure which is the canonical source of a > > function with the function itself, so that when the user invokes (edit > > froboz) (or (edit 'froboz), or whatever), the source structure for > > froboz is displayed in the editor. But in-core structure editors are > > extremely powerful and useful when editing homoiconic languages, so... > > is anyone working on an in-core editor for Clojure? > > Do you mean structured editing combined with image based development? > I haven't really looked that closely at the old Interlisp documents > but I suppose the source code is managed the same way it is in most > Smalltalk systems but I have always been a bit puzzled about how that > works with Lisp. > > In Smalltalk it is fairly straightforward since there is an obvious > mapping from classes and methods to source code. With lisp it is not > that simple as there is no limit to the syntactic forms that the user > might want to query and edit in different forms. For example, if I > have (define-foo my-foo ...) macro that is used to define some complex > function named my-foo what happens when I do (edit 'my-foo)? Do I get > the original define-foo form or the macroexpansion? What about when > define-foo does something more complex like defines a bunch of methods > and datastructures or binds my-foo to a closure? There needs to be > mechanism that associates evaluated forms with the name(s) of the > resulting object(s) and it probably couldn't, in general, be done > automatically. I am indeed looking back at structure editors such as DEdit on InterLISP - which I rate as the best programmer's editor I've ever used, superior even to its successor SEdit - but also to the editor in the versions of Portable Standard LISP I was exposed to. I don't know what the genesis of those was. I also wrote my own structure editors for other variants of LISP I worked with - in a REPL on a TTY, a primitive structure editor is pretty simple to write (you basically only need a pretty printer). However, the DEdit style editor where you can see the whole of the function or other data-structure you're working on while operating on some small part of it is vastly preferable, but rather more complex to write. Not /that/ difficult, however, if you can pretty-print source into a Swing textbox. Chouser, when you have some code you'd be willing to share I would be extremely interested in poking at it. And yes, Scott, this is a step towards Smalltalk-style (or old- fashioned Lisp style) image based development. You may well be right that this is a bad idea - but we won't know until we try... and in the end we may disagree. The next step, of course, it to write SYSOUT and its counterpart, SYSIN ;-) --~--~-~--~~~---~--~~ 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: why can't I set! stuff in user.clj?
>> I think clojure.lang.Repl should translate its args to the new
>> format and
>> call clojure.main/-main:
>>
>> old: clojure.lang.Repl file1 file2 -- a b c
>> new: clojure.main -i file1 -i file2 -r a b c
>>
>> Similarly for clojure.lang.Script:
>>
>> old: clojure.lang.Script file1 file2 file3 -- a b c
>> new: clojure.main -i file1 -i file2 file3 a b c
>>
>
> Ok, so calls to them won't change but they will delegate to main/tell.
They will delegate to clojure.main/-main. Then we'll document only
clojure.main as the way to run a script or launch Clojure's repl.
>>
>>
>>
>>
>>
>
>> [2] A single "-e" or "--eval" option should be allowed to contain
>> multiple
>> forms and it should evaluate them sequentially. There are cases where
>> wrapping multiple forms in a "do" does not work and writing
>>
>> -e (this) -e (that) -e (the-other)
>>
>> is tedious compared to
>>
>> -e "(this) (that) (the-other)"
>>
>
> This (-e) seems rather unimportant, but I wonder when does 'do' not
> work?
'do' doesn't work when an early form uses a namespace and a later form
depends on that.
java -cp clojure.jar clojure.main -e "(use 'clojure.set)" -e "(union
#{:a} #{:b})"
works.
java -cp clojure.jar clojure.main -e "(do (use 'clojure.set) (union
#{:a} #{:b}))"
fails.
--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: why can't I set! stuff in user.clj?
On Fri, Dec 12, 2008 at 11:03 AM, Stephen C. Gilardi wrote:
>
>>> I think clojure.lang.Repl should translate its args to the new
>>> format and
>>> call clojure.main/-main:
>>>
>>> old: clojure.lang.Repl file1 file2 -- a b c
>>> new: clojure.main -i file1 -i file2 -r a b c
>>>
>>> Similarly for clojure.lang.Script:
>>>
>>> old: clojure.lang.Script file1 file2 file3 -- a b c
>>> new: clojure.main -i file1 -i file2 file3 a b c
>>>
>>
>> Ok, so calls to them won't change but they will delegate to main/tell.
>
> They will delegate to clojure.main/-main. Then we'll document only
> clojure.main as the way to run a script or launch Clojure's repl.
>
>>>
>>>
>>>
>>>
>>>
>>
>>> [2] A single "-e" or "--eval" option should be allowed to contain
>>> multiple
>>> forms and it should evaluate them sequentially. There are cases where
>>> wrapping multiple forms in a "do" does not work and writing
>>>
>>> -e (this) -e (that) -e (the-other)
>>>
>>> is tedious compared to
>>>
>>> -e "(this) (that) (the-other)"
>>>
>>
>> This (-e) seems rather unimportant, but I wonder when does 'do' not
>> work?
>
> 'do' doesn't work when an early form uses a namespace and a later form
> depends on that.
>
> java -cp clojure.jar clojure.main -e "(use 'clojure.set)" -e "(union
> #{:a} #{:b})"
>
> works.
>
> java -cp clojure.jar clojure.main -e "(do (use 'clojure.set) (union
> #{:a} #{:b}))"
>
> fails.
>
I have to say I find calls to use and other multi-step operations as
command-line args baffling. Who needs this?
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: why can't I set! stuff in user.clj?
On Fri, Dec 12, 2008 at 11:08 AM, Rich Hickey wrote:
> On Fri, Dec 12, 2008 at 11:03 AM, Stephen C. Gilardi wrote:
>>
>> 'do' doesn't work when an early form uses a namespace and a later form
>> depends on that.
>>
>> java -cp clojure.jar clojure.main -e "(use 'clojure.set)" -e "(union
>> #{:a} #{:b})"
>>
>> works.
>>
>> java -cp clojure.jar clojure.main -e "(do (use 'clojure.set) (union
>> #{:a} #{:b}))"
>>
>> fails.
>
> I have to say I find calls to use and other multi-step operations as
> command-line args baffling. Who needs this?
I don't know that it's necessary, but I found it convenient when
throwing together a script to launch the repl:
kant[~/src/clojure]$ cat ~/bin/iclj
#!/bin/sh
rlwrap clojure -e "(use 'clojure.contrib.repl-ln)" \
-e "(repl)" \
-e "(set! *print-length* 20)"
- J.
--~--~-~--~~~---~--~~
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: distributing a clojure application as self contained .jar - guide
+ 1 on curiosity re: this question. In my limited Java experience, I find it more common to see a directory full of jars accompanying an application, but the benefits of a self-contained executable jar seem pretty self-evident, especially for an app who's only dependencies are clojure.jar & clojure-contrib.jar. Perry --~--~-~--~~~---~--~~ 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: why can't I set! stuff in user.clj?
On Dec 12, 2008, at 11:08 AM, Rich Hickey wrote:
>
> On Fri, Dec 12, 2008 at 11:03 AM, Stephen C. Gilardi
> wrote:
>>
I think clojure.lang.Repl should translate its args to the new
format and
call clojure.main/-main:
old: clojure.lang.Repl file1 file2 -- a b c
new: clojure.main -i file1 -i file2 -r a b c
Similarly for clojure.lang.Script:
old: clojure.lang.Script file1 file2 file3 -- a b c
new: clojure.main -i file1 -i file2 file3 a b c
>>>
>>> Ok, so calls to them won't change but they will delegate to main/
>>> tell.
>>
>> They will delegate to clojure.main/-main. Then we'll document only
>> clojure.main as the way to run a script or launch Clojure's repl.
>>
>>>
[2] A single "-e" or "--eval" option should be allowed to contain
multiple
forms and it should evaluate them sequentially. There are cases
where
wrapping multiple forms in a "do" does not work and writing
-e (this) -e (that) -e (the-other)
is tedious compared to
-e "(this) (that) (the-other)"
>>>
>>> This (-e) seems rather unimportant, but I wonder when does 'do' not
>>> work?
>>
>> 'do' doesn't work when an early form uses a namespace and a later
>> form
>> depends on that.
>>
>> java -cp clojure.jar clojure.main -e "(use 'clojure.set)" -e "(union
>> #{:a} #{:b})"
>>
>> works.
>>
>> java -cp clojure.jar clojure.main -e "(do (use 'clojure.set) (union
>> #{:a} #{:b}))"
>>
>> fails.
>>
> I have to say I find calls to use and other multi-step operations as
> command-line args baffling. Who needs this?
The general use case is Clojure acting as a provider of capabilities
that can be leveraged by a larger, external scripting system or
environment. With precedent from other similarly useful languages/
platforms like python and perl, the desire is to be flexible in how
clojure.main can be given requests to do work or evaluation.
There are at least three (arguably) natural ways for clujure.main to
get (batch-style) input from the outside world: from a file, from
stdin, or from one or more command line args.
Only one is strictly necessary as one can always produce a temporary
file and use it instead of stdin or command line args. Providing more
options makes using Clojure in this role more convenient.
I think providing all three is easy to code correctly and easy to
explain in docs, so I recommend it.
--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: jEdit Mode for Clojure
Which highlighting does it use? Daniel On Dec 12, 5:10 am, blackdog wrote: > If anyone on this thread is interested I uploaded clj-jedit.tar.gz to > the group file section on an incompletejeditplugin for clojure. It > has the hilighting, repl, and namespace browser (courtesy of enclojure) > - anyone want to take it on and improve it, I don't have time right > now?? It was based on the scheme plugin. > > bd > > On Thu, 11 Dec 2008 17:30:37 -0800 (PST) > > > > Daniel Spiewak wrote: > > > I merged in all the interesting stuff from David Moss's ClojurejEdit > > mode. We do highlight things in very different colors, but all of the > > elements that his recognizes are also recognized by mine now. Also, I > > fixed the annoying issue with def: > > > (def this)(def that) > > > The above now highlights correctly. > > > Feedback is welcome. I'm certainly willing to change the way things > > are highlighted, add highlighting or remove it. > > > Daniel > > > On Dec 11, 2:58 pm, Daniel Spiewak wrote: > > > > Hi, just saw this thread. I had made some modifications to the > > > > edit mode and uploaded it for inclusion (as a patch) > > > > here:http://sourceforge.net/tracker/index.php?func=detail&aid=2201893&grou... > > > > . > > > > > I haven't checked the status in a while as my internet is very > > > > intermittent ATM. Please let me know if there is anything missing > > > > from it or if I can in any way enhance the mode. > > > > I'll have to take a closer look at your new version. We probably > > > should merge our efforts. Your mode does do some things that mine > > > doesn't, and it doesn't really benefit anyone to have three > > > competing Clojure modes. :-) My mode is pretty convoluted in the > > > way it uses some tricks to highlight things like (def > > > blah), so it's probably easier if I steal your improvements and > > > merge them into mine. I'll give that a try later today and post > > > back with the results. > > > > Daniel > > -- > None are more hopelessly enslaved than those who falsely believe they > are free — Goethe --~--~-~--~~~---~--~~ 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: Lisp/Clojure doesn't have syntax?
On Fri, Dec 12, 2008 at 1:38 PM, Mark Volkmann wrote: > > I really have trouble understanding the idea that punctuation and > syntactic sugar shouldn't be considered syntax. S-Expressions and its counterparts are technically a syntax. I guess the distinction was made to stress that the Clojure's "syntax" is only a small subset of what is called syntax in other languages - namely data literals. But then, I agree with you that any text format has associated syntax. Just like XML or HTTP protocol do. > To me, syntax is > anything that a human reader has to comprehend in order to understand > the structure of the code. I say "structure" because that excludes > having to understand what every function and macro does. The trick is that the source code is not really represents "code" at all. It just a text description (literal) of ordinary Clojure data that happen to describe the "code". Regards, -r. --~--~-~--~~~---~--~~ 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: Running out of memory when using filter?
On Dec 12, 6:37 am, Rich Hickey wrote: > I'm appreciate the time you and others have spent on this, and will > improve filter, but I'm not sure where you are getting your > presumptions about lazy sequences. They are not a magic bullet that > makes working with data bigger than memory transparent. They do make > it possible in some cases, but that is not their intent. Latent > runtime memory consumption is a fact of life of laziness, and is > present in Haskell etc. I can make it go away for the specific case of > filter and the rest of the library, but not generally. I think some people have been assuming (perhaps partially motivated by my own questions in the initial post regarding the lifetime or extent of the caching of lazy-conses), but I actually think an issue that seems more fundamental here is being able to state with confidence what variables are being closed over and when. Perhaps it should be obvious to me, but presumably clojure's model is not (for example) like scheme's typical simple model of nested environments, because in the above example, I'd assume that the lazy- cons would capture the environment introduced by let, which presumably extends the environment of the when-let, which extends the environment of the function which itself includes coll. Does clojure analyze the expression and close over any bound identifiers in the expression? Is that why the version of filter that Rich posted works and manages not to capture coll ? Is there any documentation for clojure which describes clojure's closure or environment semantics, and are there are interactive ways to examine a function and determine what it is closing over? Thanks for your patience - I'm looking forward to understanding clojure better. --~--~-~--~~~---~--~~ 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: re-seq and other functions
Right, the outer parenthesis denote a list. That list contains only
one element. The element is the vector ["qui" "ui" "i"]
On Thu, Dec 11, 2008 at 9:43 PM, Stephen C. Gilardi wrote:
>
> In the latter case the result is a seq containing a single element:
> the vector. There is nothing to sort/it us sorted.
>
> --Steve
>
>
> On Dec 12, 2008, at 12:14 AM, Oscar Picasso
> wrote:
>
>>
>> user> (sort (re-seq #"\w+" "the quick brown fox"))
>> ("brown" "fox" "quick" "the")
>>
>> but
>> user> (sort (re-seq #"q(u(i))?" "the quick brown fox"))
>> (["qui" "ui" "i"])
>>
>> Why it's not sorted on the later case?
>>
>>
>> >
>
> >
>
--~--~-~--~~~---~--~~
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: Misplaced doc strings in clojure.contrib.seq-utils
Here's the patch: http://clojure.googlegroups.com/web/seq-utils-doc-strings.patch Perry --~--~-~--~~~---~--~~ 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: Why allow both ({:map 'example} :map) and (:map {:map 'example})?
Maps are functions of their keys because that's what maps are.
Keywords are functions of their maps because it is useful.
(def foo [{:name "Bob", :age 20}, {:name "Sue", :age 19}])
(sort-by :age foo)
(sort-by :name foo)
Note that sort-by doesn't specifically take a keyword or know what
maps are.
It just runs (keyfn x) on each thing to produce something it can
hopefully sort on. Since keywords are functions on maps, this works
out well.
On Dec 11, 3:29 pm, "Aaron Cohen" wrote:
> Isn't it just asking for confusion?
>
> I really like that maps are functions of their keys though.
--~--~-~--~~~---~--~~
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: jEdit Mode for Clojure
Daniel, To be honest, the colours are the least important, much more relevant is that structures are recursed properly and that the base language is defined. Let me know how you get on refining your mode and I'll have a look. When we have agreed on something I can update the jedit patch so we have the best superset in the editor. Does it sound like a plan? Kind Regards, David. 2008/12/12 Daniel Spiewak > > Which highlighting does it use? > > Daniel > > On Dec 12, 5:10 am, blackdog wrote: > > If anyone on this thread is interested I uploaded clj-jedit.tar.gz to > > the group file section on an incompletejeditplugin for clojure. It > > has the hilighting, repl, and namespace browser (courtesy of enclojure) > > - anyone want to take it on and improve it, I don't have time right > > now?? It was based on the scheme plugin. > > > > bd > > > > On Thu, 11 Dec 2008 17:30:37 -0800 (PST) > > > > > > > > Daniel Spiewak wrote: > > > > > I merged in all the interesting stuff from David Moss's ClojurejEdit > > > mode. We do highlight things in very different colors, but all of the > > > elements that his recognizes are also recognized by mine now. Also, I > > > fixed the annoying issue with def: > > > > > (def this)(def that) > > > > > The above now highlights correctly. > > > > > Feedback is welcome. I'm certainly willing to change the way things > > > are highlighted, add highlighting or remove it. > > > > > Daniel > > > > > On Dec 11, 2:58 pm, Daniel Spiewak wrote: > > > > > Hi, just saw this thread. I had made some modifications to the > > > > > edit mode and uploaded it for inclusion (as a patch) > > > > > here: > http://sourceforge.net/tracker/index.php?func=detail&aid=2201893&grou... . > > > > > > > I haven't checked the status in a while as my internet is very > > > > > intermittent ATM. Please let me know if there is anything missing > > > > > from it or if I can in any way enhance the mode. > > > > > > I'll have to take a closer look at your new version. We probably > > > > should merge our efforts. Your mode does do some things that mine > > > > doesn't, and it doesn't really benefit anyone to have three > > > > competing Clojure modes. :-) My mode is pretty convoluted in the > > > > way it uses some tricks to highlight things like (def > > > > blah), so it's probably easier if I steal your improvements and > > > > merge them into mine. I'll give that a try later today and post > > > > back with the results. > > > > > > Daniel > > > > -- > > None are more hopelessly enslaved than those who falsely believe they > > are free — Goethe > > > --~--~-~--~~~---~--~~ 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: Lisp/Clojure doesn't have syntax?
On Dec 11, 6:19 pm, Rich Hickey wrote: > Yes, the critical point is that the text-based representation of code > is completely secondary: > (def x (list (list (symbol "fn") (vector) "Hello World"))) > > (class (second (first x))) > -> clojure.lang.PersistentVector > > (class (first (first x))) > -> clojure.lang.Symbol > > x > -> ((fn [] "Hello World")) > > (eval x) > -> "Hello World" > > You could build code via Java calls to the Clojure lib: > > (import '(clojure.lang RT Symbol PersistentVector)) > > (def y (RT/list (RT/list (Symbol/create "fn") > (PersistentVector/EMPTY) > (Symbol/create "Hello World") > > Parens, square brackets, #, "", etc are reader syntax for data > structures. You could define a different reader and completely > different text-based syntax for the language. > > The language syntax is defined in terms of data structures, not text, > and in that respect doesn't have (text-based) syntax. The reader has > text-based syntax for data. > > Rich Ok, so it's fair to say the Clojure Reader has syntax. I don't see how this is fundamentally different than how Ruby works, for example: http://www.igvita.com/2008/12/11/ruby-ast-for-fun-and-profit/ The clojure.lang.LispReader parses an input stream of text into a Java Object, the same way that the Ruby parser parses code into an AST. One nice thing I will say about the Clojure syntax, as in all lisps, is that is there are no reserved words. Most languages, Java, Ruby, Python, JavaScript, etc. have whole list of words you can't use for variables. This is cool: user=> (def def 4) #'user/def user=> def 4 user=> (def x 5) #'user/x user=> x 5 Stuart, this might be a good point to mention in the book, in that you will never see a page like these for clojure: http://java.sun.com/docs/books/tutorial/java/nutsandbolts/_keywords.html http://www.zenspider.com/Languages/Ruby/QuickRef.html#3 http://www.python.org/doc/2.5.2/ref/keywords.html --~--~-~--~~~---~--~~ 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: jEdit Mode for Clojure
Sounds like a good plan. :-) At the moment, I think that what's in the mode is pretty solid, meaning I don't have anything planned to refine it further. (except for regexp syntax, which I don't know anything about) So, if you want to evaluate it now, that'd be great! As a minor aside, I don't actually recursively parse S-expressions. It's not a bad idea, but jEdit's weird treatment of eager-vs-lazy matching sometimes gets in the way. Instead, I just define ( and ). I don't really know when I'm in an S-exp, but I don't think that's too much of a limitation. The only exception to the above is my highlighting of "blah" in (def blah 123). That's done with an EOL_SPAN_REGEXP which delegates to a new ruleset. This ruleset then in turn delegates back to main in the case where the S-exp is closed prior to the end-of- line. It's not a normal idiom for jEdit highlighting modes, but it seems to work fine. At least I didn't have to resort to *really* bizarre tricks like I did in my SASyLF and ReST modes (opening a SPAN that terminates on an assumed non-existent character, etc). Daniel On Dec 12, 1:15 pm, "David Moss" wrote: > Daniel, > > To be honest, the colours are the least important, much more relevant is > that structures are recursed properly and that the base language is defined. > > Let me know how you get on refining your mode and I'll have a look. When we > have agreed on something I can update the jedit patch so we have the best > superset in the editor. > > Does it sound like a plan? > > Kind Regards, > > David. > > 2008/12/12 Daniel Spiewak > > > > > Which highlighting does it use? > > > Daniel > > > On Dec 12, 5:10 am, blackdog wrote: > > > If anyone on this thread is interested I uploaded clj-jedit.tar.gz to > > > the group file section on an incompletejeditplugin for clojure. It > > > has the hilighting, repl, and namespace browser (courtesy of enclojure) > > > - anyone want to take it on and improve it, I don't have time right > > > now?? It was based on the scheme plugin. > > > > bd > > > > On Thu, 11 Dec 2008 17:30:37 -0800 (PST) > > > > Daniel Spiewak wrote: > > > > > I merged in all the interesting stuff from David Moss's ClojurejEdit > > > > mode. We do highlight things in very different colors, but all of the > > > > elements that his recognizes are also recognized by mine now. Also, I > > > > fixed the annoying issue with def: > > > > > (def this)(def that) > > > > > The above now highlights correctly. > > > > > Feedback is welcome. I'm certainly willing to change the way things > > > > are highlighted, add highlighting or remove it. > > > > > Daniel > > > > > On Dec 11, 2:58 pm, Daniel Spiewak wrote: > > > > > > Hi, just saw this thread. I had made some modifications to the > > > > > > edit mode and uploaded it for inclusion (as a patch) > > > > > > here: > >http://sourceforge.net/tracker/index.php?func=detail&aid=2201893&grou... . > > > > > > > I haven't checked the status in a while as my internet is very > > > > > > intermittent ATM. Please let me know if there is anything missing > > > > > > from it or if I can in any way enhance the mode. > > > > > > I'll have to take a closer look at your new version. We probably > > > > > should merge our efforts. Your mode does do some things that mine > > > > > doesn't, and it doesn't really benefit anyone to have three > > > > > competing Clojure modes. :-) My mode is pretty convoluted in the > > > > > way it uses some tricks to highlight things like (def > > > > > blah), so it's probably easier if I steal your improvements and > > > > > merge them into mine. I'll give that a try later today and post > > > > > back with the results. > > > > > > Daniel > > > > -- > > > None are more hopelessly enslaved than those who falsely believe they > > > are free — Goethe --~--~-~--~~~---~--~~ 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: Dr. Dobbs: "It's Time to Get Good at Functional Programming"
On Dec 10, 1:28 pm, Randall R Schulz wrote: > There seems to be a bit of an oversight. I recall at least one other article on (Common) Lisp in Dr. Dobb's Journal which was disastrously poorly written (misleading, outdated, irrelevant information, even though the article was "pro-Lisp"). It's not clear to me whether it's worthwhile to try to improve the articles by comments, because the overall quality is so low. (I think I tried but it didn't get anywhere.) mfh --~--~-~--~~~---~--~~ 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: Working combination of .emacs, Aquamacs, swank-clojure, clojure-mode?
Thanks Bill for posting such detailed Clojure+SLIME setup instructions on your blog! :-D One thing that tripped me up was that my .emacs was loading a custom SLIME (since I use the .emacs for Emacs 21 as well as Emacs 22, and Emacs 21 does not come with SLIME by default). The custom SLIME was an older version and so _everything_ was messed up ;-P but not requiring 'slime also caused troubles. I ended up inserting the following (require 'slime) (slime-setup) before the following lines in your .emacs: (require 'clojure-auto) (require 'swank-clojure-autoload) That seemed to help matters. Now I'm using Clojure a lot more because I don't have to cut and paste between Emacs and the shell prompt ;-) Many thanks! mfh --~--~-~--~~~---~--~~ 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: reduction
I was sure it was a job for iterate: (defn reductions "Returns a lazy seq of the intermediate values of the reduction (as per reduce) of coll by f, starting with init." ([f coll] (if (seq coll) (for [s (iterate (fn [[x & s]] (if s (lazy-cons (f x (first s)) (rest s coll) :while s] (first s)) (list (f ([f val coll] (reductions f (cons val coll It's interesting that the general case is [f coll] and not [f val coll]. Christophe Chouser a écrit : > How about this one? Same results as in my previous post. Still as > lazy as possible. Plus it's so cute! > > (defn reduction > "Returns a lazy seq of the intermediate values of the reduction (as > per reduce) of coll by f, starting with init." > ([f coll] >(if (seq coll) > (lazy-cons (first coll) (map f (reduction f coll) (rest coll))) > (cons (f) nil))) > ([f init coll] >(lazy-cons init (map f (reduction f init coll) coll > > --Chouser > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
compile and gen-class don't seem to work for me
For the first time I tried to use gen-class (using svn r1156), but
unfortunately compilation fails:
u...@computer /tmp $ mkdir test
u...@computer /tmp $ cd test/
u...@computer /tmp/test $ mkdir -p clojure/examples
u...@computer /tmp/test $ gvim clojure/examples/instance.clj ;copied
the source from http://clojure.org/compilation into the editor and
saved it [1]
u...@computer /tmp/test $ mkdir classes
u...@computer /tmp/test $ java -cp
.:classes:/opt/clojure/clojure/trunk/clojure.jar clojure.main
Clojure
user=> (compile 'clojure.examples.instance)
java.lang.RuntimeException: java.lang.ClassNotFoundException:
clojure.examples.instance$_init__4 (NO_SOURCE_FILE:0)
user=> (.printStackTrace *e)
java.lang.RuntimeException: java.lang.ClassNotFoundException:
clojure.examples.instance$_init__4 (NO_SOURCE_FILE:0)
at clojure.lang.Compiler.eval(Compiler.java:4147)
at clojure.core$eval__3542.invoke(core.clj:1486)
at clojure.main$repl__5154$fn__5169.invoke(main.clj:100)
at clojure.main$repl__5154.doInvoke(main.clj:96)
at clojure.lang.RestFn.invoke(RestFn.java:426)
at clojure.main$repl_opt__5194.invoke(main.clj:153)
at clojure.main$_main__5218.doInvoke(main.clj:228)
at clojure.lang.RestFn.invoke(RestFn.java:402)
at clojure.lang.AFn.applyToHelper(AFn.java:191)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.main.main(Unknown Source)
Caused by: java.lang.RuntimeException:
java.lang.ClassNotFoundException: clojure.examples.instance$_init__4
at clojure.lang.Compiler$FnExpr.getCompiledClass(Compiler.java:3211)
at clojure.lang.Compiler$FnExpr.emit(Compiler.java:3223)
at clojure.lang.Compiler$DefExpr.emit(Compiler.java:318)
at clojure.lang.Compiler.compile(Compiler.java:4560)
at clojure.lang.RT.compile(RT.java:362)
at clojure.lang.RT.load(RT.java:404)
at clojure.lang.RT.load(RT.java:376)
at clojure.core$load__4555$fn__4557.invoke(core.clj:3427)
at clojure.core$load__4555.doInvoke(core.clj:3426)
at clojure.lang.RestFn.invoke(RestFn.java:413)
at clojure.core$load_one__4518.invoke(core.clj:3271)
at clojure.core$compile__4561$fn__4563.invoke(core.clj:3437)
at clojure.core$compile__4561.invoke(core.clj:3436)
at user$eval__1.invoke(Unknown Source)
at clojure.lang.Compiler.eval(Compiler.java:4136)
... 10 more
Caused by: java.lang.ClassNotFoundException: clojure.examples.instance$_init__4
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at clojure.lang.DynamicClassLoader.findClass(DynamicClassLoader.java:52)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at clojure.lang.RT.classForName(RT.java:1504)
at clojure.lang.Compiler$FnExpr.getCompiledClass(Compiler.java:3202)
... 24 more
nil
Did I miss anything?
Many thanks,
nt
---
[1] For reference here is the code from instance.clj
(ns clojure.examples.instance
(:gen-class
:implements [java.util.Iterator]
:init init
:constructors {[String] []}
:state state))
(defn -init [s]
[[] (ref {:s s :index 0})])
(defn -hasNext [this]
(let [{:keys [s index]} @(.state this)]
(< index (count s
(defn -next [this]
(let [{:keys [s index]} @(.state this)
ch (.charAt s index)]
(dosync (alter (.state this) assoc :index (inc index)))
ch))
--~--~-~--~~~---~--~~
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: compile and gen-class don't seem to work for me
Ignore me. I forgot to set *compile-path*. Everything works fine after
that. Sorry for the noise.
On Dec 12, 9:39 pm, ntu...@googlemail.com wrote:
> For the first time I tried to use gen-class (using svn r1156), but
> unfortunately compilation fails:
>
> u...@computer /tmp $ mkdir test
> u...@computer /tmp $ cd test/
> u...@computer /tmp/test $ mkdir -p clojure/examples
> u...@computer /tmp/test $ gvim clojure/examples/instance.clj ;copied
> the source fromhttp://clojure.org/compilationinto the editor and
> saved it [1]
> u...@computer /tmp/test $ mkdir classes
> u...@computer /tmp/test $ java -cp
> .:classes:/opt/clojure/clojure/trunk/clojure.jar clojure.main
> Clojure
> user=> (compile 'clojure.examples.instance)
> java.lang.RuntimeException: java.lang.ClassNotFoundException:
> clojure.examples.instance$_init__4 (NO_SOURCE_FILE:0)
> user=> (.printStackTrace *e)
> java.lang.RuntimeException: java.lang.ClassNotFoundException:
> clojure.examples.instance$_init__4 (NO_SOURCE_FILE:0)
> at clojure.lang.Compiler.eval(Compiler.java:4147)
> at clojure.core$eval__3542.invoke(core.clj:1486)
> at clojure.main$repl__5154$fn__5169.invoke(main.clj:100)
> at clojure.main$repl__5154.doInvoke(main.clj:96)
> at clojure.lang.RestFn.invoke(RestFn.java:426)
> at clojure.main$repl_opt__5194.invoke(main.clj:153)
> at clojure.main$_main__5218.doInvoke(main.clj:228)
> at clojure.lang.RestFn.invoke(RestFn.java:402)
> at clojure.lang.AFn.applyToHelper(AFn.java:191)
> at clojure.lang.RestFn.applyTo(RestFn.java:137)
> at clojure.main.main(Unknown Source)
> Caused by: java.lang.RuntimeException:
> java.lang.ClassNotFoundException: clojure.examples.instance$_init__4
> at clojure.lang.Compiler$FnExpr.getCompiledClass(Compiler.java:3211)
> at clojure.lang.Compiler$FnExpr.emit(Compiler.java:3223)
> at clojure.lang.Compiler$DefExpr.emit(Compiler.java:318)
> at clojure.lang.Compiler.compile(Compiler.java:4560)
> at clojure.lang.RT.compile(RT.java:362)
> at clojure.lang.RT.load(RT.java:404)
> at clojure.lang.RT.load(RT.java:376)
> at clojure.core$load__4555$fn__4557.invoke(core.clj:3427)
> at clojure.core$load__4555.doInvoke(core.clj:3426)
> at clojure.lang.RestFn.invoke(RestFn.java:413)
> at clojure.core$load_one__4518.invoke(core.clj:3271)
> at clojure.core$compile__4561$fn__4563.invoke(core.clj:3437)
> at clojure.core$compile__4561.invoke(core.clj:3436)
> at user$eval__1.invoke(Unknown Source)
> at clojure.lang.Compiler.eval(Compiler.java:4136)
> ... 10 more
> Caused by: java.lang.ClassNotFoundException:
> clojure.examples.instance$_init__4
> at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
> at
> clojure.lang.DynamicClassLoader.findClass(DynamicClassLoader.java:52)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:247)
> at clojure.lang.RT.classForName(RT.java:1504)
> at clojure.lang.Compiler$FnExpr.getCompiledClass(Compiler.java:3202)
> ... 24 more
> nil
>
> Did I miss anything?
>
> Many thanks,
> nt
>
> ---
> [1] For reference here is the code from instance.clj
>
> (ns clojure.examples.instance
> (:gen-class
> :implements [java.util.Iterator]
> :init init
> :constructors {[String] []}
> :state state))
>
> (defn -init [s]
> [[] (ref {:s s :index 0})])
>
> (defn -hasNext [this]
> (let [{:keys [s index]} @(.state this)]
> (< index (count s
>
> (defn -next [this]
> (let [{:keys [s index]} @(.state this)
> ch (.charAt s index)]
> (dosync (alter (.state this) assoc :index (inc index)))
> ch))
--~--~-~--~~~---~--~~
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: Misplaced doc strings in clojure.contrib.seq-utils
Thanks, Perry. It's fixed now (SVN 292). -Stuart Sierra On Dec 8, 11:02 am, Perry Trolard wrote: > In clojure.contrib.seq-utils, partition-by & group-by have docstrings > following their arglists, so (doc parition-by) prints > > - > clojure.contrib.seq-utils/partition-by > ([f coll]) > nil > nil > > I'd submit a patch, but I'm sure it's easier if Stuart Sierra or > another of the contrib committers just swith 'em around. > > Best, > Perry --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Safe to delete namespace dirs in clojure-contrib?
Hi folks, When I patch files in clojure-contrib, I only modify the new namespace- is-filename versions, not the older namespace-is-directory ones. It's been a month since Clojure rev. 1094 introduced the namespace-is- file change. Are people still using releases that require the old contrib directories, or can we safely delete them? -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: Why allow both ({:map 'example} :map) and (:map {:map 'example})?
On Dec 11, 3:29 pm, "Aaron Cohen" wrote: > Isn't it just asking for confusion? It's useful to have it both ways: (map :one-key bunch-of-maps) (map one-map bunch-of-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: Safe to delete namespace dirs in clojure-contrib?
On Fri, Dec 12, 2008 at 4:24 PM, Stuart Sierra wrote: > > Hi folks, > When I patch files in clojure-contrib, I only modify the new namespace- > is-filename versions, not the older namespace-is-directory ones. > > It's been a month since Clojure rev. 1094 introduced the namespace-is- > file change. Are people still using releases that require the old > contrib directories, or can we safely delete them? +1 The dirs are a bit confusing, and people can always get an old svn revision if they really must. --Chouser --~--~-~--~~~---~--~~ 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: Safe to delete namespace dirs in clojure-contrib?
On Dec 12, 2008, at 3:24 PM, Stuart Sierra wrote: > It's been a month since Clojure rev. 1094 introduced the namespace-is- > file change. Are people still using releases that require the old > contrib directories, or can we safely delete them? I was confused yesterday as to why my copy of test-is seemed out of date, until I realized I was looking at the wrong file. I think it's probably safe to get rid of them. :dudley --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Gorilla: Release of Version 1.1.0
Dear vimming Clojurians, (or was the name changed?) I'd like to announce the next release of Gorilla. New Features: - - Open the javadoc of the class under the cursor. This is currently very basic. - "Show" information about the class (or instance) under the cursor. This is included with permission of Chouser. Thanks. :) - Go to the source definition of the symbol under the cursor. The sources must be locally available and reachable via the 'path' option. - Evaluate a visual block or the whole file. - Require the namespace of the current file with the :reload option. Might need copying of files for remote Clojure servers before invocation of the function. - First test balloon for omni completion ( in insert mode): Dynamically completes static members of the class under the cursor. Vim Repl: - The previously included socketrepl is obsolete. Gorilla now uses the repl-ln from Clojure Contrib. This change should make the Repl much more robust than before. Also sending multiple expressions is not a problem anymore. Thanks to Stephen C. Gilardi! This is really awesome! :) Breaking Changes: - I decided to introduce some breaking changes. But since they concern the keybindings this should be done as soon as possible. All keybindings working on a word under the cursor, eg. lw - "lookup word", also have an interactive counterpart. In this case ld - "lookup doc". However this was a very bad choice, since it doesn't work for non-documentation related bindings. So I changed the bindings from *d to *i for "interactive". This allows a more consistent mnemoic: go word - go interactive, lookup word - lookup interactive. Furthermore the development repository is now hosted on bitbucket. The old link will redirect to the new location but might become obsolete in the future. Acknowledgements: - Thanks for their feedback and patches go to (in no particular order): - Mark Feeney - J. McConnell - Juergen Gmeiner - Drew Olson - Jeff Rose - Jedi_Stannis on #clojure The release may be found at the usual place: http://kotka.de/projects/clojure/gorilla.html Sincerely Meikel smime.p7s Description: S/MIME cryptographic signature
Re: Swing GUI Builder and Clojure
My vote is for Swing. Despite its flaws, it's the Java standard - there's no need to worry about compatibility (SWT) or licensing (Jambi) issues, and there's a wealth of material online to study it further. It's included with Java, which is a huge plus in a tutorial setting - personally, I'd be very turned off if I had to download and configure an additional library just to follow the examples in a book. And a lot more programmers are going to be familiar with Swing than any of the others. Plus, in 15 pages, you're not going to be able to cover any reasonable amount of any library, so really, the library itself doesn't matter as much. What's more important is showing how to use Clojure to interact with Java in a variety of more complex UI scenarios, which Swing offers. Once those concepts are grasped, the actual library is immaterial. Just my two cents. -Luke On Nov 4, 10:32 am, Stuart Halloway wrote: > For the book would people rather see Swing or Qt Jambi examples? Or > something else? The book won't spend more than 10 of 250 pages on UI > stuff, so I'd rather do one reasonably interesting example than skim > several. > > Stuart > > > On Tue, Nov 4, 2008 at 10:01 AM, Rock wrote: > > >> Anyway, where I work, I've done a lot of programming in Python on > >> Linux as well. I've used Glade and LibGlade extensively in this > >> respect, and I've come to appreciate the ease with which one can put > >> together a GUI application with these tools. Especially, I like the > >> fact that one can load the XML of the GUI in runtime and set up all > >> the signals to the callbacks almost automagically. > > > One possible approach is with Qt Jambi. They have a nice GUI builder > > called "designer" that generates an xml file that can be loaded at > > runtime. He's a rough example: > > >http://paste.lisp.org/display/69450 > > > --Chouser --~--~-~--~~~---~--~~ 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: Gorilla: Release of Version 1.1.0
On Friday 12 December 2008 13:43, Meikel Brandmeyer wrote: > Dear vimming Clojurians, (or was the name changed?) > > I'd like to announce the next release of Gorilla. > > ... > Meikel Great news, thanks! I think I may have asked this before, but what Vim version requirements does Gorilla have? Randall Schulz --~--~-~--~~~---~--~~ 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: Gorilla: Release of Version 1.1.0
Hi Randall, Am 12.12.2008 um 22:54 schrieb Randall R Schulz: I think I may have asked this before, but what Vim version requirements does Gorilla have? To be honest: I don't know. My MacVim claims to be 7.2. So this is what I tested Gorilla with. It may work with earlier version or it may not. I'm not aware of some kind of list of when a particular feature was introduced. I simply don't have the time to test it on all Vims back to 6.something. So if you encounter an issue, I'll will try to solve it together with you, and include a fix, but I'm not actively checking that everything works with older vims... Sincerely Meikel smime.p7s Description: S/MIME cryptographic signature
Re: Lisp/Clojure doesn't have syntax?
Paul Barry schreef: > Ok, so it's fair to say the Clojure Reader has syntax. I don't see > how this is fundamentally different than how Ruby works, for example: > > http://www.igvita.com/2008/12/11/ruby-ast-for-fun-and-profit/ > > The clojure.lang.LispReader parses an input stream of text into a Java > Object, the same way that the Ruby parser parses code into an AST. Note that there is no standard whatsoever to guarantee that different ruby implementations generate the same AST from the same source code. The difference is that Lisps in general are defined in terms of their AST, not in terms of syntax/source file structure. All reader macros/ syntactic sugar translates directly into defined data structures, and the language is defined in terms of those data structures. Since clojure doesn't allow for user defined reader macros, and has more built-in reader constructs, the "no syntax" mantra is a bit harder to maintain, at least superficially, but Common Lisp programs for example, can completely do away with S-expressions and still be the same language. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
rev.1054 question
First, thanks for the great work with Clojure. Second, I found some code I was working on didn't work with rev.1054. Paring things down I got the following which reproduces the behaviour: (defstruct A :a) (defn t [] (let [ A (struct A 0.0) ] (loop [i 0 l '()] (if (< i 5) (recur (inc i) (cons i l)) l This produces a list of float's not integer's as I'd expect. Taking out the "A" line in the let, or even just using an integer instead of the "0.0" there works ok. This seems to happen on rev.1054 and up. Mayes --~--~-~--~~~---~--~~ 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: Lisp/Clojure doesn't have syntax?
On Dec 12, 4:13 pm, Joost wrote: > Paul Barry schreef: > > > Ok, so it's fair to say the Clojure Reader has syntax. I don't see > > how this is fundamentally different than how Ruby works, for example: > > >http://www.igvita.com/2008/12/11/ruby-ast-for-fun-and-profit/ > > > The clojure.lang.LispReader parses an input stream of text into a Java > > Object, the same way that the Ruby parser parses code into an AST. > > Note that there is no standard whatsoever to guarantee that different > ruby implementations generate the same AST from the same source code. > > The difference is that Lisps in general are defined in terms of their > AST, not in terms of syntax/source file structure. All reader macros/ > syntactic sugar translates directly into defined data structures, and > the language is defined in terms of those data structures. Since > clojure doesn't allow for user defined reader macros, and has more > built-in reader constructs, the "no syntax" mantra is a bit harder to > maintain, at least superficially, but Common Lisp programs for > example, can completely do away with S-expressions and still be the > same language. I'm not sure Clojure has more built-in reader constructs than Common Lisp, which has reader syntax for vectors, arrays, pathnames, dotted pairs, bitvectors, read-time evaluation, labels, label references, read-time conditionals, many kinds of numbers, functions, balanced comments and uninterned symbols, in addition to the usual lists, symbols, strings, numbers and characters. 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: Gorilla: Release of Version 1.1.0
On Friday 12 December 2008 13:59, Meikel Brandmeyer wrote: > Hi Randall, > > Am 12.12.2008 um 22:54 schrieb Randall R Schulz: > > I think I may have asked this before, but what Vim version > > requirements > > does Gorilla have? > > .. I guess what you should say at least is that it requires Ruby and the Vim Ruby module / extension / whatever. Unfortunately, neither of the systems I use have that in their Vim builds. SuSE Linux 10.0: % vim --version |head -1 VIM - Vi IMproved 6.3 (2004 June 7, compiled Aug 15 2007 23:30:49) % vim --version |egrep ruby +path_extra -perl +postscript +printer -python +quickfix +rightleft -ruby openSUSE Linux 10.3: % vim --version |head -1 VIM - Vi IMproved 7.1 (2007 May 12, compiled Dec 12 2007 14:09:38) % vim --version |egrep ruby -python +quickfix +reltime +rightleft -ruby +scrollbind +signs +smartindent > Sincerely > Meikel Randall Schulz --~--~-~--~~~---~--~~ 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: rev.1054 question
On Dec 12, 4:01 pm, mayes wrote: > First, thanks for the great work with Clojure. > > Second, I found some code I was working on didn't work with > rev.1054. Paring things down I got the following which > reproduces the behaviour: > > (defstruct A :a) > (defn t [] > (let [ > A (struct A 0.0) > ] > (loop [i 0 l '()] > (if (< i 5) > (recur (inc i) (cons i l)) > l > > This produces a list of float's not integer's as I'd expect. > Taking out the "A" line in the let, or even just using an integer > instead of the "0.0" there works ok. > > This seems to happen on rev.1054 and up. Fixed (svn 1157) - thanks for the report. 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 -~--~~~~--~~--~--~---
iteration idioms
A very large chunk of iteration is done for the sake of producing a new collection based on an existing collection, hence functional constructs like list comprehensions and map. However, I'm not sure about how to functionally handle cases of iteration which seem to require: 1) keeping around values from previous iterations 2) producing a collection of more values than exist in the original (or sometimes fewer values, though such cases usually require just straight forward filtering) For (1), it seems you generally resort to some kind of recursion with loop/recur. Say we wish to find the max value in a list (without using 'max'): (def foo [35 -7 8 2 100 56]) (loop [max (first foo) nums (rest foo)] (if (nil? nums) max (recur (if (> (first nums) max) (first nums) max) (rest nums For (2), say I want to insert 3 before every item less than or equal to 5 in a seq: (def bar [24 6 5 5 7 5 8 2]) (defn prepend3 [s val] (if (<= val 5) (concat s [3 val]) (concat s [val]))) (loop [old (rest bar) new (prepend3 [] (first bar))] (if (nil? old) new (recur (rest old) (prepend3 new (first old) user=> (24 6 3 5 3 5 7 3 5 3 2) Again, hardly elegant. Maybe there's a cleaner way to use loop in these cases, or maybe I'm just forgetting some function(s) to use. Hopefully someone can demonstrate better idioms to handle these common cases. --Brian Will --~--~-~--~~~---~--~~ 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: iteration idioms
> > For (1), it seems you generally resort to some kind of recursion with > loop/recur. Say we wish to find the max value in a list (without using > 'max'): I can do this with reduce: user=> (defn my-max [lst] (reduce (fn [x a] (if (> x a) x a)) (first lst) (rest lst))) #'user/my-max user=> (my-max '(2 4 12 3 4)) 12 For more complex data that you need to bring along, use a list or map. > For (2), say I want to insert 3 before every item less than or equal > to 5 in a seq: Again reduce to the rescue: (reduce into (map (fn [i] (if (<= i 5) [3 i] [i])) [24 6 5 5 7 5 8 2])) This is still O(n) - though it needs to iterate the vector twice. The second version shows off Clojure's nice improvement to reduce (vis-a- vis fold in Scheme): grabbing the first item from the head of the list/ vec/seq. The down side is I can't write multi-sequence reduce calls like Scheme, but c'est la vie. I could write O(n) versions with continuations in Scheme, but I think loop/recur would be required in Clojure. Cheers, -Mark --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: Running out of memory when using filter?
On Fri, Dec 12, 2008 at 6:37 AM, Rich Hickey wrote: > I'm appreciate the time you and others have spent on this, and will > improve filter, but I'm not sure where you are getting your > presumptions about lazy sequences. They are not a magic bullet that > makes working with data bigger than memory transparent. They do make > it possible in some cases, but that is not their intent. Latent > runtime memory consumption is a fact of life of laziness, and is > present in Haskell etc. I can make it go away for the specific case of > filter and the rest of the library, but not generally. I think this is a great discussion to have, so let me see if I can articulate my thoughts a little better. First, let's talk about laziness, because I think we're in agreement here. Laziness is undoubtedly a very powerful tool. In Haskell, laziness is the default. Every single function call is automatically lazy. In LISP/Scheme, laziness is optional. It's something you have to specifically opt into using delay and force. Which is better? Peter Van Roy, the designer of the Oz programming language, has argued in many places that laziness is not a good default for a general-purpose programming language. This is also a point he discusses in his excellent book "Concepts, Techniques, and Models of Computer Programming". He has probably explained this point better than I can, so I won't belabor it here, but in a nutshell, it all comes down to the fact that laziness makes the performance (especially space performance) of your program much harder to analyze. It is all too easy to write a Haskell program that blows up or performs poorly, and you have no idea why. You can get back some performance by opting-out of the laziness with strictness annotations, but it can be difficult to figure out how or where to do this. To put it simply, it's easier to write high-performing code when you opt-in to laziness when you need it, rather than trying to figure out how to opt out when it's wrecking things for you. I assume that you agree with this, since you have chosen the explicit force/delay "opt-in laziness" model for Clojure. So now let's talk about sequences, specifically the behavior of lazily-generated sequences. A similar choice needs to be considered. It is easy to imagine two possible implementations of lazy-cons. lazy-cons-cached would work exactly as lazy-cons currently does. lazy-cons-uncached would be similar, but would not cache its first and rest values when computed. Sequences built with either version of lazy-cons would both respond to the same sequence interface, and would therefore behave the same, producing the same results as long as the generating functions don't refer to mutable data, but possibly with different performance profiles. lazy-cons-cached sequences might run faster when traversing the same lazy list more than once, but also might crash your program by consuming too much memory in places where lazy-cons-uncached would not. It's a tradeoff, and both versions of lazy-cons are potentially useful, but which should be the default, or more specifically, which should be the default used by all of Clojure's library functions like map, filter, etc.? Should these lazily-generated sequences be automatically cached, or not? The first question is, does it matter? I would say that yes, this design decision matters a great deal. I think I remember you saying somewhere (in a post here, or possibly in one of your presentations) that sequences, especially lazy sequences, have become a far more important part of Clojure programming than you envisioned at the outset. And it is easy to see why lazy sequences take on a significant role in a fairly pure functional programming language: People coming from imperative languages often ask how you code up certain kinds of for/while loops that are used to traverse data structures and build up new ones. Let's say you want to build a list of all the even squares of whole numbers up to 100, inclusively. One literal way to formulate this problem in an imperative language (taking Python 2.6 syntax as a sample) would be: l = [] for i in xrange(100): square = i*i if (square%2 == 0): l.append(square) Now in Clojure, things like this can be written using loop/recur. But any newcomer to Clojure will certainly be told that there's a more elegant way to express this concept: (def l (filter even? (map #(* % %) (range 100 or the equivalent comprehension. The newcomer's first reaction is to say, "Whoa, but won't that have poor performance? You're generating an awful lot of big, intermediate lists." And the answer is usually, "Well, it's lazy, so no, in fact, this elegant form behaves like the iterative version. You can have your cake and eat it too." You said, "I'm not sure where you are getting your presumptions about lazy sequences. They are not a magic bullet that makes working with data bigger than memory transparent." Well, actually, I know that cached
Patch to get test-clojure up-to-date [Was: Re: clojure.contrib.test-is: first major rewrite]
On Sun, Dec 7, 2008 at 10:51 AM, Stuart Sierra wrote: > > As of clojure-contrib SVN 283, there's a new clojure.contrib.test-is. > This is a pretty major rewrite of the library. I've tried to > streamline the code and make it easier to plug in custom reporting and > assertion functions. Unfortunately, this introduces several breaking > changes: > > I realize this breaks a lot of the tests in clojure.contrib.test- > clojure. Sorry about that; if I have time I'll go through and fix > those. Attached is a patch that updates test-clojure to run with the new test-is. All tests pass. For the test-clojure.evaluation tests, I just had to replace (throws ...) with (is (thrown? ...)). For the test-clojure.numbers tests, I replaced (all-true ...) with (are all-true? ...) with all-true? defined as: (defn all-true? [& args] (apply = (cons true (map #(true? (boolean %)) args That may not be great for accurately and specifically reporting failures, but I figured it would work for now, until (are ...) is modified as you say it probably will be. It's better than tests that won't compile at least :) I also took out the binding form in test-clojure.clj, since *test-out* is gone and we weren't using it for anything other than directing to *out*. Let me know if you have any questions or see any issues with the patch. Regards, - J. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- Index: src/clojure/contrib/test_clojure/numbers.clj === --- src/clojure/contrib/test_clojure/numbers.clj (revision 292) +++ src/clojure/contrib/test_clojure/numbers.clj (working copy) @@ -14,9 +14,12 @@ (ns clojure.contrib.test-clojure.numbers (:use clojure.contrib.test-is)) +(defn all-true? [& args] + (apply = (cons true (map #(true? (boolean %)) args + (deftest Coerced-Byte (let [v (byte 3)] -(all-true +(are all-true? (instance? Byte v) (number? v) (integer? v) @@ -24,7 +27,7 @@ (deftest Coerced-Short (let [v (short 3)] -(all-true +(are all-true? (instance? Short v) (number? v) (integer? v) @@ -32,7 +35,7 @@ (deftest Coerced-Integer (let [v (int 3)] -(all-true +(are all-true? (instance? Integer v) (number? v) (integer? v) @@ -40,7 +43,7 @@ (deftest Coerced-Long (let [v (long 3)] -(all-true +(are all-true? (instance? Long v) (number? v) (integer? v) @@ -48,7 +51,7 @@ (deftest Coerced-BigInteger (let [v (bigint 3)] -(all-true +(are all-true? (instance? BigInteger v) (number? v) (integer? v) @@ -56,21 +59,21 @@ (deftest Coerced-Float (let [v (float 3)] -(all-true +(are all-true? (instance? Float v) (number? v) (float? v (deftest Coerced-Double (let [v (double 3)] -(all-true +(are all-true? (instance? Double v) (number? v) (float? v (deftest Coerced-BigDecimal (let [v (bigdec 3)] -(all-true +(are all-true? (instance? BigDecimal v) (number? v) (decimal? v) Index: src/clojure/contrib/test_clojure/evaluation.clj === --- src/clojure/contrib/test_clojure/evaluation.clj (revision 292) +++ src/clojure/contrib/test_clojure/evaluation.clj (working copy) @@ -136,7 +136,7 @@ (test-that "If a symbol is package-qualified, it is an error if there is no Class named by the symbol" -(throws Compiler$CompilerException (eval 'java.lang.FooBar))) +(is (thrown? Compiler$CompilerException (eval 'java.lang.FooBar (test-that "If a symbol is not qualified, the following applies, in this order: @@ -161,9 +161,9 @@ ; First (doall (for [form '(def if do let quote var fn loop recur throw try monitor-enter monitor-exit)] - (throws Compiler$CompilerException (eval form + (is (thrown? Compiler$CompilerException (eval form) (let [if "foo"] - (throws Compiler$CompilerException (eval 'if))) + (is (thrown? Compiler$CompilerException (eval 'if ; Second (is (= (eval 'Boolean) (class-for-name "java.lang.Boolean"))) @@ -175,10 +175,10 @@ ; Fourth (in-test-ns (is (= (eval 'foo) "abc"))) -(throws Compiler$CompilerException (eval 'bar)) ; not in this namespace +(is (thrown? Compiler$CompilerException (eval 'bar))) ; not in this namespace ; Fifth -(throws Compiler$CompilerException (eval 'foobar +(is (thrown? Compiler$CompilerException (eval '
Re: Running out of memory when using filter?
On Friday 12 December 2008 15:15, Mark Engelberg wrote: > ... > > --Mark Not being nearly sophisticated enough in Clojure, FP or the relevant concepts to say anything other than "that all makes complete sense to me," I wonder only what would be the impact on existing programs were the default to be switched as you suggest? Or, relatedly, how would you go about making this transition while simultaneously minimizing breaking changes? And lastly, has Clojure reached the point where breaking changes are taboo? Randall Schulz --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
(use '[... and classpath
I can write a): user> (use '[clojure.contrib.str-utils :only (str-join)]) nil and b) user> clojure.xml/parse # But not c) (use '[closure.xml :only (parse)]) java.io.FileNotFoundException: Could not locate closure/ xml__init.class or closure/xml.clj on classpath: (NO_SOURCE_FILE:0) [Thrown class clojure.lang.Compiler$CompilerException] I don't understand. Since I could write b), I didn't expect a classpath problem with closure.xml since I could write b). I use emacs + slime. --~--~-~--~~~---~--~~ 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: Running out of memory when using filter?
On Dec 12, 6:15 pm, "Mark Engelberg" wrote: > On Fri, Dec 12, 2008 at 6:37 AM, Rich Hickey wrote: > > I'm appreciate the time you and others have spent on this, and will > > improve filter, but I'm not sure where you are getting your > > presumptions about lazy sequences. They are not a magic bullet that > > makes working with data bigger than memory transparent. They do make > > it possible in some cases, but that is not their intent. Latent > > runtime memory consumption is a fact of life of laziness, and is > > present in Haskell etc. I can make it go away for the specific case of > > filter and the rest of the library, but not generally. > > I think this is a great discussion to have, so let me see if I can > articulate my thoughts a little better. > > First, let's talk about laziness, because I think we're in agreement > here. Laziness is undoubtedly a very powerful tool. In Haskell, > laziness is the default. Every single function call is automatically > lazy. In LISP/Scheme, laziness is optional. It's something you have > to specifically opt into using delay and force. Which is better? > > Peter Van Roy, the designer of the Oz programming language, has argued > in many places that laziness is not a good default for a > general-purpose programming language. This is also a point he > discusses in his excellent book "Concepts, Techniques, and Models of > Computer Programming". He has probably explained this point better > than I can, so I won't belabor it here, but in a nutshell, it all > comes down to the fact that laziness makes the performance (especially > space performance) of your program much harder to analyze. It is all > too easy to write a Haskell program that blows up or performs poorly, > and you have no idea why. You can get back some performance by > opting-out of the laziness with strictness annotations, but it can be > difficult to figure out how or where to do this. To put it simply, > it's easier to write high-performing code when you opt-in to laziness > when you need it, rather than trying to figure out how to opt out when > it's wrecking things for you. > > I assume that you agree with this, since you have chosen the explicit > force/delay "opt-in laziness" model for Clojure. > > So now let's talk about sequences, specifically the behavior of > lazily-generated sequences. A similar choice needs to be considered. > It is easy to imagine two possible implementations of lazy-cons. > lazy-cons-cached would work exactly as lazy-cons currently does. > lazy-cons-uncached would be similar, but would not cache its first and > rest values when computed. Sequences built with either version of > lazy-cons would both respond to the same sequence interface, and would > therefore behave the same, producing the same results as long as the > generating functions don't refer to mutable data, but possibly with > different performance profiles. lazy-cons-cached sequences might run > faster when traversing the same lazy list more than once, but also > might crash your program by consuming too much memory in places where > lazy-cons-uncached would not. It's a tradeoff, and both versions of > lazy-cons are potentially useful, but which should be the default, or > more specifically, which should be the default used by all of > Clojure's library functions like map, filter, etc.? Should these > lazily-generated sequences be automatically cached, or not? > > The first question is, does it matter? I would say that yes, this > design decision matters a great deal. I think I remember you saying > somewhere (in a post here, or possibly in one of your presentations) > that sequences, especially lazy sequences, have become a far more > important part of Clojure programming than you envisioned at the > outset. And it is easy to see why lazy sequences take on a > significant role in a fairly pure functional programming language: > > People coming from imperative languages often ask how you code up > certain kinds of for/while loops that are used to traverse data > structures and build up new ones. Let's say you want to build a list > of all the even squares of whole numbers up to 100, inclusively. One > literal way to formulate this problem in an imperative language > (taking Python 2.6 syntax as a sample) would be: > l = [] > for i in xrange(100): > square = i*i > if (square%2 == 0): > l.append(square) > > Now in Clojure, things like this can be written using loop/recur. But > any newcomer to Clojure will certainly be told that there's a more > elegant way to express this concept: > > (def l (filter even? (map #(* % %) (range 100 > > or the equivalent comprehension. > > The newcomer's first reaction is to say, "Whoa, but won't that have > poor performance? You're generating an awful lot of big, intermediate > lists." And the answer is usually, "Well, it's lazy, so no, in fact, > this elegant form behaves like the iterative version. You can have > your cake and eat it too."
Re: (use '[... and classpath
On Fri, Dec 12, 2008 at 6:37 PM, Oscar Picasso wrote: > > java.io.FileNotFoundException: Could not locate closure/ You've got cloSure instead of cloJure. - J. --~--~-~--~~~---~--~~ 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: (use '[... and classpath
s/closure/clojure/ On Fri, Dec 12, 2008 at 3:37 PM, Oscar Picasso wrote: > > I can write a): > user> (use '[clojure.contrib.str-utils :only (str-join)]) > nil > > and b) > user> clojure.xml/parse > # > > But not c) > (use '[closure.xml :only (parse)]) > java.io.FileNotFoundException: Could not locate closure/ > xml__init.class or closure/xml.clj on classpath: (NO_SOURCE_FILE:0) > [Thrown class clojure.lang.Compiler$CompilerException] > > I don't understand. Since I could write b), I didn't expect a > classpath problem with closure.xml since I could write b). > > I use emacs + slime. > > > --~--~-~--~~~---~--~~ 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: Gorilla: Release of Version 1.1.0
On Dec 12, 2:29 pm, Randall R Schulz wrote: > > > I think I may have asked this before, but what Vim version > > > requirements > > > does Gorilla have? > > > .. > > I guess what you should say at least is that it requires Ruby and the > Vim Ruby module / extension / whatever. Unfortunately, neither of the > systems I use have that in their Vim builds. > > SuSE Linux 10.0: > > % vim --version |head -1 > VIM - Vi IMproved 6.3 (2004 June 7, compiled Aug 15 2007 23:30:49) > > % vim --version |egrep ruby > +path_extra -perl +postscript +printer -python +quickfix +rightleft -ruby > > openSUSE Linux 10.3: > > % vim --version |head -1 > VIM - Vi IMproved 7.1 (2007 May 12, compiled Dec 12 2007 14:09:38) > > % vim --version |egrep ruby > -python +quickfix +reltime +rightleft -ruby +scrollbind +signs +smartindent I believe that you can get ruby support in Vim in openSUSE 10.3 by installing the gvim or vim-enhanced packages. I would guess that something similar should work for SuSE 10.0. -- Nathan --~--~-~--~~~---~--~~ 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: Running out of memory when using filter?
On Dec 12, 1:03 pm, Paul Mooser wrote: > On Dec 12, 6:37 am, Rich Hickey wrote: > > > I'm appreciate the time you and others have spent on this, and will > > improve filter, but I'm not sure where you are getting your > > presumptions about lazy sequences. They are not a magic bullet that > > makes working with data bigger than memory transparent. They do make > > it possible in some cases, but that is not their intent. Latent > > runtime memory consumption is a fact of life of laziness, and is > > present in Haskell etc. I can make it go away for the specific case of > > filter and the rest of the library, but not generally. > > I think some people have been assuming (perhaps partially motivated by > my own questions in the initial post regarding the lifetime or extent > of the caching of lazy-conses), but I actually think an issue that > seems more fundamental here is being able to state with confidence > what variables are being closed over and when. > > Perhaps it should be obvious to me, but presumably clojure's model is > not (for example) like scheme's typical simple model of nested > environments, because in the above example, I'd assume that the lazy- > cons would capture the environment introduced by let, which presumably > extends the environment of the when-let, which extends the environment > of the function which itself includes coll. > > Does clojure analyze the expression and close over any bound > identifiers in the expression? Is that why the version of filter that > Rich posted works and manages not to capture coll ? Is there any > documentation for clojure which describes clojure's closure or > environment semantics, and are there are interactive ways to examine a > function and determine what it is closing over? > > Thanks for your patience - I'm looking forward to understanding > clojure better. Clojure has normal lexical scope and closures do what you expect, although there aren't reified environments like you might find in an interpreter. Because it uses lazy sequences and doesn't have tail calls, it does local variable and argument nulling prior to tail calls, to prevent any lingering references on the stack. In particular, you can normally hold on to a seq head in a local or argument and pass it to a tail call without retaining the head. Closures are lexical and visible, only capturing references from the enclosing scope actually used in their bodies, not entire environments, and each individually releasable. 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: Running out of memory when using filter?
On Dec 12, 3:15 pm, "Mark Engelberg" wrote: >And in fact, it turns out that in those languages, uncached lazy lists end up >rarely used. Did you mean that the cached lazy lists are rarely used? Or does everyone actually choose to use the cached ones? --~--~-~--~~~---~--~~ 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: Lisp/Clojure doesn't have syntax?
Rich Hickey schreef: > I'm not sure Clojure has more built-in reader constructs than Common > Lisp, which has reader syntax for vectors, arrays, pathnames, dotted > pairs, bitvectors, read-time evaluation, labels, label references, > read-time conditionals, many kinds of numbers, functions, balanced > comments and uninterned symbols, in addition to the usual lists, > symbols, strings, numbers and characters. Let's just say that clojuire has more *useful* (as in actually used) built-in reader constructs than CL. I'm not complaining (much) - I think most of the clojure constructs are sound. --~--~-~--~~~---~--~~ 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: iteration idioms
Thanks, Mark. I don't suppose (reduce into ...) is a common enough idiom that it deserves its own function? Perhaps (into x) should do (reduce into x), e.g. (into [[3 5] [6 7]]) => [3 5 6 7]. This makes sense to me, but maybe it's too semantically different from (into x y). If not, though, you could do the same with concat. On Dec 12, 3:10 pm, Mark Fredrickson wrote: > > For (1), it seems you generally resort to some kind of recursion with > > loop/recur. Say we wish to find the max value in a list (without using > > 'max'): > > I can do this with reduce: > user=> (defn my-max [lst] (reduce (fn [x a] (if (> x a) x a)) (first > lst) (rest lst))) > #'user/my-max > user=> (my-max '(2 4 12 3 4)) > 12 > > For more complex data that you need to bring along, use a list or map. > > > For (2), say I want to insert 3 before every item less than or equal > > to 5 in a seq: > > Again reduce to the rescue: > > (reduce into (map (fn [i] (if (<= i 5) [3 i] [i])) [24 6 5 5 7 5 8 2])) > > This is still O(n) - though it needs to iterate the vector twice. The > second version shows off Clojure's nice improvement to reduce (vis-a- > vis fold in Scheme): grabbing the first item from the head of the list/ > vec/seq. The down side is I can't write multi-sequence reduce calls > like Scheme, but c'est la vie. > > I could write O(n) versions with continuations in Scheme, but I think > loop/recur would be required in Clojure. > > Cheers, > -Mark --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: Swing GUI Builder and Clojure
Hi Geoffrey, Thanks for the tip. I put . for every command within the doto. Also looking forward to having a look at the Qt work you are currently doing. Cheers, Sun On Dec 12, 4:32 am, "Geoffrey Teale" wrote: > 2008/12/12 Geoffrey Teale > > > > > Hi, > > > Depending on which version of Clojure you are using you may find that you > > need to change: > > > (doto button > > (resize 250 100)) > > > to: > > > (doto button > > Argh.. goddam google mail... I meant to say: > > (doto button > (.resize 250 100)) > > Note the additional dot in the notation. There are a number of gotchas > using QtJambi with post AOT versions of Clojure. I have spent a few > weekends converting a program. I will blog when my code reaches a useful > stage and my current Qt branch is checked into github. > > -- > Geoffrey Teale > Freelance Software and Technology Consultant > Munich, Germany --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Functional programming newbie question
So, I'm trying to understand functional programming, particularly as it relates to the seq abstraction, and I'm hitting a slight difficulty as I'm playing around - something that seems as if it ought to be simple, is not. I'm playing with copying one seq into another. I've found several different ways to do it, but the most obvious one, in my opinion, is missing. Here's the straight-up, high performance tail recursive version that was my first thought: (defn copy-seq-r [source] (loop [so-far '() to-go source] (if (nil? to-go) so-far (recur (cons (first to-go) so-far) (rest to-go) The obvious problem with this is that because seqs are last-in first- out, this returns the seq in reverse order. Obviously not what we wanted. And using (reverse) or consing the (last) is awful for performance. The next implementation is simpler, and uses recursion quite elegantly: (defn copy-seq [source] (if (nil? source) '() (cons (first source) (copy-seq (rest source) The obvious fault with this is that it's non tail-recursive and blows the stack with seqs of greater than 200-300 elements. This can be fixed by making the cons a lazy-cons. This creates a lazily-called function that closes over the source parameter, thus removing the call from the stack. This works fine in Clojure, and seems to be the best solution for actual use in a program. (One question... Is the reference to the lazy function maintained after the function is realized? I don't want to have thousands seqs hanging around in memory while they're not needed. Also, I'm not 100% sure of the semantics of lazy-cons... the above code implemented with lazy- cons IS O(n) in both time and space, correct? Or does lazy-cons do something different than I'm thinking of) However, there is a sense in which using lazy-cons feels rather like a cheat. It feels like there ought to be a straightforward functional way to copy a seq/list, in order, in O(n) time, without using laziness. Or is this seemingly simple task an impossibility due to the nature of the singly-linked list? That's beginning to be what I'm thinking. What would one do in a language like Scheme, without lazy- cons? (Of course, another solution in Clojure would be to copy to a vec instead of a list and then seq it... But I'm more interested in the theory, here). Thanks in advance for the help - I know this is probably a stupid question, but I'm curious and want to make sure the way I'm thinking about lists and seqs is correct. --~--~-~--~~~---~--~~ 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: Running out of memory when using filter?
On Fri, Dec 12, 2008 at 5:28 PM, Paul Mooser wrote: > > On Dec 12, 3:15 pm, "Mark Engelberg" wrote: >>And in fact, it turns out that in those languages, uncached lazy lists end up >>rarely used. > > Did you mean that the cached lazy lists are rarely used? Or does > everyone actually choose to use the cached ones? Sorry, in that particular sentence I said the opposite of what I meant. I meant that cached lazy lists are rarely used in those languages. Although I'm a relative newbie to Clojure, I've spent a lot of time using a wide variety of languages. When Rich's reaction was "everything mutable breaks without caching", my initial reaction was astonishment that he perceives that to be the common case in a language where mutability is mostly shunned. I have trouble thinking of a case where I'd want to put something mutable in a lazy list. But of course, he's spent more time with Clojure than anyone, so I don't doubt his experience on this matter. So then the question becomes, why is my experience so different in other languages? Taking Scala as an example, I can think of two things that might make it more suitable in that language to work with non-cached lazy lists as a default. First, in Scala there is richer syntactic support for mutable, imperative-style programming when you need it. So you mostly use laziness, comprehensions, etc. with your immutable, functional-style code. But when you're working with mutable stuff (like interop with Java), you go ahead and code with for/while loops, assignment, and it doesn't feel particularly gross. Second, Scala has a more polymorphic approach to things like map and filter. If you map a vector, you get back a vector. If you filter a concrete list, you get back a concrete list. Comprehension syntax is essentially a macro that expands to combinations of map, filter, and flatMap (analogous to Clojure's mapcat, I think), so your comprehension output is also determined by the type of the first collection in the comprehension. So if you're working with mutable data, you'd be storing it in a different kind of collection anyway (like a vector, or a cached lazy list), and all the map, filter, etc. would work the way you'd expect it to. The first point can just be chalked up to rather fundamental design differences in the two languages. Incorporating this kind of "imperative subsystem" would clutter up Clojure's elegance. As to the second point, it's not inconceivable to do something like that in Clojure. Clojure's multimethods can certainly support such a thing. But certainly Scala's approach has a downside because sometimes you don't want a comprehension to build the same thing as the source collection, and converting between them can be inefficient. There's something rather nice about the way Clojure always returns a bland sequence that can essentially be "realized" into anything you want. It just seems unfortunate to me that a consequence of this is that all these output sequences are automatically of the cached variety. Perhaps there's some sort of middle ground where Clojure can always return a lazy sequence, but be a bit more intelligent about choosing the right variety depending on the nature of the input, but it's not immediately apparent to me how one would do that. If I get a chance, I'll definitely play around with some of these ideas, as Rich suggested, although my "common case" programming seems to be different from his. I got burned by the filter issue on my very first Clojure program, when I tried to filter a lazy stream of 10-digit permutations to find all the permutations with a certain property. The permutations which satisfied the property were far enough apart that it caused a problem. This is the kind of program I typically write. In the meantime, I'm definitely looking forward to seeing Rich's new generator approach. Maybe having another way to tackle the problem cases will make a lot of my worries about this issue go away. --Mark P.S. I don't want to sound too negative, so I'll mention here that there are several things I *love* about Clojure. First, the way operations on so many of the data structures are unified through the sequence interface. Second, multimethods (haven't seen much multimethod action since Dylan, and I've always loved them). Third, many little touches like making maps, sets, vectors, and keys also act like function, which contribute to readable brevity. --~--~-~--~~~---~--~~ 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: Functional programming newbie question
I guess one answer to your question would be: If the seq is persistent (immutable) why would you need to make a copy of it? On Dec 12, 8:51 pm, levand wrote: > So, I'm trying to understand functional programming, particularly as > it relates to the seq abstraction, and I'm hitting a slight difficulty > as I'm playing around - something that seems as if it ought to be > simple, is not. > > I'm playing with copying one seq into another. I've found several > different ways to do it, but the most obvious one, in my opinion, is > missing. > > Here's the straight-up, high performance tail recursive version that > was my first thought: > > (defn copy-seq-r [source] > (loop [so-far '() to-go source] > (if (nil? to-go) > so-far > (recur (cons (first to-go) so-far) > (rest to-go) > > The obvious problem with this is that because seqs are last-in first- > out, this returns the seq in reverse order. Obviously not what we > wanted. And using (reverse) or consing the (last) is awful for > performance. > > The next implementation is simpler, and uses recursion quite > elegantly: > > (defn copy-seq [source] > (if (nil? source) > '() > (cons (first source) (copy-seq (rest source) > > The obvious fault with this is that it's non tail-recursive and blows > the stack with seqs of greater than 200-300 elements. > > This can be fixed by making the cons a lazy-cons. This creates a > lazily-called function that closes over the source parameter, thus > removing the call from the stack. This works fine in Clojure, and > seems to be the best solution for actual use in a program. (One > question... Is the reference to the lazy function maintained after the > function is realized? I don't want to have thousands seqs hanging > around in memory while they're not needed. Also, I'm not 100% sure of > the semantics of lazy-cons... the above code implemented with lazy- > cons IS O(n) in both time and space, correct? Or does lazy-cons do > something different than I'm thinking of) > > However, there is a sense in which using lazy-cons feels rather like a > cheat. It feels like there ought to be a straightforward functional > way to copy a seq/list, in order, in O(n) time, without using > laziness. Or is this seemingly simple task an impossibility due to the > nature of the singly-linked list? That's beginning to be what I'm > thinking. What would one do in a language like Scheme, without lazy- > cons? > > (Of course, another solution in Clojure would be to copy to a vec > instead of a list and then seq it... But I'm more interested in the > theory, here). > > Thanks in advance for the help - I know this is probably a stupid > question, but I'm curious and want to make sure the way I'm thinking > about lists and seqs is correct. --~--~-~--~~~---~--~~ 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: Functional programming newbie question
On Fri, Dec 12, 2008 at 6:51 PM, levand wrote: > The next implementation is simpler, and uses recursion quite > elegantly: > (defn copy-seq [source] >(if (nil? source) > '() > (cons (first source) (copy-seq (rest source) > What would one do in a language like Scheme, without lazy- > cons? In PLT Scheme, you'd write it just like your elegant recursive version. This is such a common pattern that the runtime is optimized in such a way that there's no real stack limitations and you never have to worry about blowing the stack (unless the actual result list is too big for your computer's memory, of course). In environments with a limited call stack, you'd do the accumulator version and reverse it at the end. In implementations that support mutable lists, it is not uncommon to reverse the copy destructively to save a bit of space. I'm a relative newbie to Clojure, but I would think that in Clojure, using lazy-cons would probably be the preferred approach, although the accumulator version followed by an accumulator version of reverse is not unreasonable if you have some concerns about being lazy. --Mark --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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: re-gsub improvement
On Dec 6, 1:29 pm, Juergen Gmeiner wrote:
> Hi List,
>
> a little thing I have grown quite fond of:
>
> (re-gsub#"\b(?:word|expr|whatever)\b"
> {"word" "A WORD"
> "expr" "An Expression"
> "whatever" "WHATEVER!"}
> "welcome to the united states of whatever")
>
> Patch athttp://groups.google.at/group/clojure/web/re-gsub.patch
>
> For completeness, I also implemented re-sub with a function as
> replacement. Never needed it though.
This is good! Please send in your Contributor Agreement so this patch
can be checked in.
http://clojure.org/contributing
--Chouser
--~--~-~--~~~---~--~~
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: Running out of memory when using filter?
On Fri, Dec 12, 2008 at 10:09 PM, Mark Engelberg wrote: > > On Fri, Dec 12, 2008 at 5:28 PM, Paul Mooser wrote: >> >> On Dec 12, 3:15 pm, "Mark Engelberg" wrote: >>>And in fact, it turns out that in those languages, uncached lazy lists end >>>up rarely used. >> >> Did you mean that the cached lazy lists are rarely used? Or does >> everyone actually choose to use the cached ones? > > Sorry, in that particular sentence I said the opposite of what I > meant. I meant that cached lazy lists are rarely used in those > languages. > > Although I'm a relative newbie to Clojure, I've spent a lot of time > using a wide variety of languages. When Rich's reaction was > "everything mutable breaks without caching", my initial reaction was > astonishment that he perceives that to be the common case in a > language where mutability is mostly shunned. I have trouble thinking > of a case where I'd want to put something mutable in a lazy list. But > of course, he's spent more time with Clojure than anyone, so I don't > doubt his experience on this matter. I wasn't talking at all about lists of mutable things. In Clojure, people often build a sequence from an imperative/ephemeral source. The caching becomes very important in these cases. > As to the second point, it's not inconceivable to do something like > that in Clojure. Clojure's multimethods can certainly support such a > thing. But certainly Scala's approach has a downside because > sometimes you don't want a comprehension to build the same thing as > the source collection, and converting between them can be inefficient. > There's something rather nice about the way Clojure always returns a > bland sequence that can essentially be "realized" into anything you > want. It just seems unfortunate to me that a consequence of this is > that all these output sequences are automatically of the cached > variety. > > Perhaps there's some sort of middle ground where Clojure can always > return a lazy sequence, but be a bit more intelligent about choosing > the right variety depending on the nature of the input, but it's not > immediately apparent to me how one would do that. If I get a chance, > I'll definitely play around with some of these ideas, as Rich > suggested, although my "common case" programming seems to be different > from his. I got burned by the filter issue on my very first Clojure > program, when I tried to filter a lazy stream of 10-digit permutations > to find all the permutations with a certain property. The > permutations which satisfied the property were far enough apart that > it caused a problem. This is the kind of program I typically write. > I'm sorry you encountered a bug, and will fix, but that's not an indictment of Clojure's approach. Scala et al have had their own problems: http://lampsvn.epfl.ch/trac/scala/ticket/692 http://lampsvn.epfl.ch/trac/scala/ticket/498 http://groups.google.com/group/cal_language/browse_thread/thread/728a3d4ff0f77b00 Note that Clojure does do locals nulling on tail calls. It certainly has paid attention to laziness implementation issues, a bug notwithstanding. > In the meantime, I'm definitely looking forward to seeing Rich's new > generator approach. Maybe having another way to tackle the problem > cases will make a lot of my worries about this issue go away. > I think it's very important not to conflate different notions of sequences. Clojure's model a very specific abstraction, the Lisp list, originally implemented as a singly-linked list of cons cells. It is a persistent abstraction, first/second/third/rest etc, it is not a stream, nor an iterator. Lifting that abstraction off of cons cells doesn't change its persistent nature, nor does lazily realizing it. After my experimentation with a non-caching version, I am convinced it is incompatible with the abstraction. If a seq was originally generated from an imperative source, you need it to be cached in order to get repeatable read persistence, if it was calculated at some expense, you need to cache it in order to get the performance characteristics you would expect from a persistent list. An abstraction is more than just an interface. That said, I think there is certainly room for a stream/generator model, especially for I/O, but also for more efficient collection processing. Such a thing is explicitly one-pass and ephemeral. It will not have the interface of first/rest, nor Java's thread-unsafe hasNext/next iterator model (shared by Scala). You can obviously build seqs from streams/generators, and in my model, with a single definition you will get both a stream and seq version of functions like map and filter, as I showed here: http://groups.google.com/group/clojure/msg/53227004728d6c54 Note also that filter/map etc are not part of these abstractions, though they can be defined on top of both. Stream/generators and a corresponding map/filter library on them will give you other options for one-pass processing, but lazy seqs work pretty well ri
Updated 'show' and 'source'
I've added updated versions of 'show' and 'source' to a new lib named clojure.contrib.repl-utils 'show' is for exploring classes at the REPL. What's new is that it now displays the modifiers of the class and the parameter types for each method. 'source' tries to display the Clojure source for any Var. It now sports more robust logic for finding the source file and determining the end of the Var's definition. user=> (show 1/2) === public clojure.lang.Ratio === [ 0] (BigInteger,BigInteger) [ 1] denominator : BigInteger [ 2] numerator : BigInteger [ 3] byteValue : byte () [ 4] compareTo : int (Object) [ 5] doubleValue : double () [ 6] equals : boolean (Object) [ 7] floatValue : float () [ 8] getClass : Class () [ 9] hashCode : int () [10] intValue : int () [11] longValue : long () [12] notify : void () [13] notifyAll : void () [14] shortValue : short () [15] toString : String () [16] wait : void () [17] wait : void (long) [18] wait : void (long,int) Note that 'show' takes instances or classes. Members are sorted by kind: static fields, static methods, constructors, instance fields, instance methods. Note that parameter package names and method modifiers are not displayed for brevity. For complete details on a member, append its number to the call: user=> (show 1/2 3) # This actually returns the method itself, and so can be used to construct more complex introspection expressions: user=> (show (.getType (show 1/2 1))) === public java.math.BigInteger === [ 0] static ONE : BigInteger [ 1] static TEN : BigInteger [ 2] static ZERO : BigInteger ...etc... Use of 'source' couldn't be simpler: user=> (source filter) (defn filter "Returns a lazy seq of the items in coll for which (pred item) returns true. pred must be free of side-effects." [pred coll] (when (seq coll) (if (pred (first coll)) (lazy-cons (first coll) (filter pred (rest coll))) (recur pred (rest coll) nil user=> (source clojure.zip/node) (defn node "Returns the node at loc" [loc] (loc 0)) nil --Chouser --~--~-~--~~~---~--~~ 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: Running out of memory when using filter?
On Fri, Dec 12, 2008 at 9:28 PM, Rich Hickey wrote: > I think it's very important not to conflate different notions of > sequences. Clojure's model a very specific abstraction, the Lisp list, > originally implemented as a singly-linked list of cons cells. It is a > persistent abstraction, first/second/third/rest etc, OK, I think I see where you're going with this. It sounds like you're saying that one of the key ideas here is that the first/rest interface is meant to guarantee a certain kind of persistence. If I say (first (rest coll)), it should aways give me the same thing. If you designed first/rest to work on uncached sequences, most would work this way, but there is certainly no guarantee, depending on the nature of the generating function. Since you want the interface to imply this sort of guarantee, you have no choice but to cache anything involving first/rest (not including things like "seq"ified vectors which are inherently cached). This makes sense. So the piece you're working on is to provide better support for things that are determined by their generating functions. You are intentionally avoiding using the terms first/rest for these "streams" for the reasons above. Since streams will be easily convertable to seqs, we'll be able to get the best of both words. We can manipulate streams, and eventually when we pass the stream to a function that requires seqs, it will do the conversion, and stability will be guaranteed. It sounds like a very promising approach, and I'm looking forward to seeing the results. It seems like ideally, it should be as easy as possible to manipulate the streams in stream form, so if you're working with a stream source you can go as long as possible without converting a stream to seq. Having map/filter/mapcat/comprehensions work fluidly over streams as well as seqs could be hugely beneficial. > That said, I think there is certainly room for a stream/generator > model, especially for I/O, but also for more efficient collection > processing. Such a thing is explicitly one-pass and ephemeral. It will > not have the interface of first/rest, nor Java's thread-unsafe > hasNext/next iterator model (shared by Scala). You can obviously build > seqs from streams/generators, and in my model, with a single > definition you will get both a stream and seq version of functions > like map and filter, as I showed here: > http://groups.google.com/group/clojure/msg/53227004728d6c54 OK, looking back over your sneak preview example, I have a couple quick comments/questions. 1. You are using stream-seq to convert streams to seqs. Can't you just make the seq function work automatically on streams to produce the sequence, just like it does on vectors, sets, etc., rather than have a special name for converting streams to sequences? That way, you can pass streams to all the functions that begin with (seq coll) and you'll get the desired behavior. 2. After you've added streams, what will the range function produce? Consider making range produce a stream rather than a sequence. (Somewhat relatedly, in Python, range produced a concrete list and xrange produced a generated stream. range was so rarely used that one of the breaking changes they made in Python 3.0 was to get rid of the list-producing range, and start using the name "range" for the generator-variant rather than "xrange"). 3. In your sneak-preview filter function, it always produces a seq. In the spirit of making it easy to work with streams as long as possible without conversion, how about making filter return a stream in the case that the input is a stream, rather than having separate filter-stream and filter public functions? Or is it not in the spirit of Clojure to have functions overloaded in this way? --Mark --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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 -~--~~~~--~~--~--~---
