Re: probable bug in transients ..
http://clojure.org/transients
mentions that transients are not designed to be bashed in place like mutable
datastructures.
The following produces the correct result.
(loop [x (transient {}) i 0]
(if (< i 10)
(recur (assoc! x i (* i i)) (inc i))
(persistent! x)))
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Native Clojure
> > Lazy-seq's are often handy in Clojure to subvert the stack limit imposed > > by the the JVM, but it's not quite the same problem that TCO solves. > > Having recently converted some Scheme that leaned heavily on the presence > of TCO, I'm curious as to what situations you think could not be solved > with lazy-seqs? > > David As I understand it, indirect tail calls are the case where TCO is most difficult to emulate in languages without goto. Of course, we have trampolines, and (as demonstrated in Nicolas's example) there's a correspondence between lazy-seqs and trampolines. So, I don't mean to claim that there's anything you *can't* do with lazy-seq. Although I do wonder how to translate cps-code to use lazy-seqs (as opposed to trampolines). (apologies in advance for this silly example) (defn [f k x] (if (time-to-return? x) (k x) (g (fn [x*] (k (do-stuff-to x*))) x))) (defn [g k x] (if (time-to-return? x) (k x) (f (fn [x*] (k (do-other-stuff-to x*))) x))) so with TCO, assuming k doesn't exhaust memory, f and g will operate in constant space, and the eventual call to k will also unwind in constant space. cheers, Andy -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Native Clojure
> With TCO mutually recursive functions do not consume the stack. The same is > true for well constructed lazy sequences. If the functions were: (defn f [x] (g x)) (defn g [x] (f x)) They would operate in constant space with tail-call optimization. (defn f [x] (cons x (g x))) (defn g [x] (cons x (f x))) Will run out of memory even in languages that support tail call optimization. (assuming we're evaluating them eagerly) Lazy-seq's are often handy in Clojure to subvert the stack limit imposed by the the JVM, but it's not quite the same problem that TCO solves. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Symbol substitution in macro
Hi, > because the symbol's namespace is then nil, and you still can't tell if > they're shadowing it with a let binding, or have renamed it with :as. > If the namespace is nil then its either been :used or :required. You could check ns-refers to see if its been :used. If its been shadowed the symbol will appear in &env. But, as you suggested, checking for the var may be easier and sufficient as well. That said, neither method is really composable. If the symbol usually represents a normal function, the user may wrap it in a helper or otherwise use it in a way that the symbol is not visible. In that case a macro will never be able to find it. It may be easier (for the implementor and consumers) to make it a special form, like recur when used in a loop or function body. YMMV. - Andy On Tuesday 03 August 2010 23:39:46 Kyle Schaffrick wrote: > On Mon, 2 Aug 2010 07:23:12 -0400 > > Andrew Boekhoff wrote: > > On Sunday 01 August 2010 21:34:16 Kyle Schaffrick wrote: > > > Hello, > > > > > > I'm trying to write a library with two main parts. The first is a > > > macro, I'll call it 'with-feature, that walks through forms passed > > > inside it, and any time it sees a call to another function in my > > > library, 'feature, do some transformations. > > > > > > The problem I'm concerned about is as follows: When my macro sees > > > the forms that are passed into it, the symbols come in however the > > > consumer of the library wrote them. So say I :require my library and > > > alias it to 'mylib', then the call 'with-feature is looking for > > > appears as 'mylib/feature. Or, I could :use the library, and then it > > > would appear as 'feature, or I could alias 'feature to 'banana--you > > > get the idea. > > > > > > I don't want to reserve some magic symbol name that defies namespace > > > rules, so that if the library consumer code uses the symbol 'feature > > > to mean something different, they get bizarre results. > > > > > > What is a good pattern for writing the "matching" logic in such a > > > selectively-transforming macro so that it can properly find the > > > magic call it's looking for in the presence of normal namespacing > > > behavior? > > > > > > Thanks, > > > > > > -Kyle > > > > Hi, > > > > The following technique seems to work for finding out if you've > > > > been aliased: > > > > (ns somewhere.trial) > > > > (let [here *ns*] > > > > (defmacro whats-my-name [] > > > > (some (fn [[k v]] (when (= here v) `(quote ~k))) > > > > (ns-aliases *ns* > > > > user> (require '[somewhere.trial :as aliased]) => > > user> (aliased/whats-my-name) => aliased > > > > So at the top of with-feature the parser could check for an alias and > > construct the appropriate predicate from the result. > > > > -Andy > > I originally had something similar to this actually, but it doesn't work > for the case when the library is referred in the consumer code with :use > because the symbol's namespace is then nil, and you still can't tell if > they're shadowing it with a let binding, or have renamed it with :as. > > However, this idea occurred to me yesterday. What if I check to see if > the symbol is pointing to the *var* containing my magic function, > instead of trying to examine the symbol itself? e.g.: > > (= (resolve symbol-i-am-scanning-in-my-macro) > #'function-i-am-looking-for) > > It seems to work, since at macro-expand time *ns* is bound to the > consumer code's namespace. Does this seem like a reasonable way to deal > with this? > > -Kyle -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Symbol substitution in macro
On Sunday 01 August 2010 21:34:16 Kyle Schaffrick wrote: Hi, The following technique seems to work for finding out if you've been aliased: (ns somewhere.trial) (let [here *ns*] (defmacro whats-my-name [] (some (fn [[k v]] (when (= here v) `(quote ~k))) (ns-aliases *ns* user> (require '[somewhere.trial :as aliased]) => user> (aliased/whats-my-name) => aliased So at the top of with-feature the parser could check for an alias and construct the appropriate predicate from the result. -Andy > Hello, > > I'm trying to write a library with two main parts. The first is a > macro, I'll call it 'with-feature, that walks through forms passed > inside it, and any time it sees a call to another function in my > library, 'feature, do some transformations. > > The problem I'm concerned about is as follows: When my macro sees the > forms that are passed into it, the symbols come in however the consumer > of the library wrote them. So say I :require my library and alias it to > 'mylib', then the call 'with-feature is looking for appears as > 'mylib/feature. Or, I could :use the library, and then it would appear > as 'feature, or I could alias 'feature to 'banana--you get the idea. > > I don't want to reserve some magic symbol name that defies namespace > rules, so that if the library consumer code uses the symbol 'feature > to mean something different, they get bizarre results. > > What is a good pattern for writing the "matching" logic in such a > selectively-transforming macro so that it can properly find the magic > call it's looking for in the presence of normal namespacing behavior? > > Thanks, > > -Kyle -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Remove-first function
Hi, One way to prevent the stack overflows is to wrap it in a lazy seq. For example: (defn remove-first [x coll] (lazy-seq (when (seq coll) (let [[y & ys] coll] (if (= target y) ys (cons y (remove-first x ys))) On Saturday 24 July 2010 11:41:58 nickikt wrote: > Hallo all, > > I'm working trough Essentials of Programming Languages. I'm trying to > right a function like this one: > > (defn scheme-remove-first [syb lst] > (if (empty? lst) > '() > (if (= (first lst) syb) > (rest lst) > (cons (first lst) (scheme-remove-first syb (rest lst)) > > in a idiomatic clojure way (this is just a scheme to clojure 1:1 > version). I don't like that this function produces stack overflows. > > I tried some stuff but I it (almost) semantically correct working but > I didn't like my code. Can anyone come up with a good version? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: congomongo memory leak?
Hi. Congomongo is a fairly thin wrapper around the MongoDB java driver. All fetch requests are proxied through the driver which handles all opening and closing of connections automatically. Its main utility is providing a smooth(er) interface between Clojure's immutable types and the mutable types that the driver deals in. It also tries to unify various similar methods on collections into a few parameterizable functions. It does tend to give the garbage collector a workout on large (for some value of large) reads and writes. That seems to have been the case with regards to the discussion from IRC that you mentioned. Cheers, Andy A couple days ago, on IRC, I observed some folks talking about a possible memory leak in the somnium congomongo clojure interface to mongoDB. The discussion suggested that each fetch opens the file without closing it, and pretty soon you get an error. Does anyone know what happened with this? Is it a real problem, and if so, is it being addressed? I'm about to start a project using clojure/mongoDB but don't want to use it if there's a known problem without a known fix. 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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Lift equivalent
> > As for the OO vs functional . . . a web server is a function from a > > request to a response. How is that functional view any less natural > > than an OO view? > > I think someone steeped in the controller/action viewpoint (a la > Rails) would disagree: they see requests as being parameterized > actions taken on/by controllers, with those requests being described > by URI templates and routed by a route specification. The controller/action viewpoint could as well be described as a hashmap of routes to functions, all of which accept an optional map of parameters, and all of which return an http response. For me at least, this makes for a clearer mental picture than 'personifying' the pattern with objects. > Me, I'm happy with the functional approach :) In complete agreement here :) Cheers, Andy -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Better documentation and error messages are needed for the ns macro
With clojure-in-clojure on the horizon (if not around the corner) I wonder if an imports clause would be appropriate, and solve some of the complexities of discerning between clojure and java/clr/javascript/objectivec/(go?) (ns foo (uses clojure.contrib.repl-utils) (imports java.util [List Map Set])) For the case of host-libraries import * is not even available, so a single symbol for a class or a prefix symbol followed by a vector is syntax simple enough for even myself to implement. It might add some consistency if the above 'uses also worked at the repl as-is (import already works as a beginner would anticipate). So, user> (uses clojure.contrib.Math) just worked without quoting. As for how many options are allowed with keywords, as long the essential cases are provided for it will always be possible to layer on a my-better-ns* macro that adds more sugar (like recursive prefix lists etc.) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Better documentation and error messages are needed for the ns macro
> > (:uses [clojure.core :exclude [read]) > > [clojure.contrib.graph] > > [clojure.contrib.fcase] > > [clojure.contrib.stream-utils :as su] > > [clojure.contrib.def :refer-all true] > > [clojure.contrib.except :refer-all true] > > [clojure.contrib.server-socket :refer-all true] > > [clojure.contrib.lazy-xml :refer-all true] > > [clojure.contrib.java-utils :only [as-str]] > > [clojure.stacktrace :only [root-cause]] > > [clojure.walk :only [postwalk]]) +1 As a thought (which may offend some fans of explicit delimiters), dropping the brackets and delimiting on symbols could be an option. (ns foo (uses clojure.contrib.graph clojure.contrib.stream-utils :as su clojure.contrib.java-utils :only [as-str])) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Iterative collections.
Hi. > And gives very different results. 'for' iterates over it's sequences > in a nested fasion. For your particular example, it will return the > sequence from (+ 31 1) (+ 31 2) and so on, and never get to the second > element of the first vector. I like it. I was recently wondering about a convenient expression for this type of iteration. I wonder if it could be supported with a new keyword in for? maybe: (for [ x [42 17 25] :with [ y (iterate inc 1)]] (+ x y)) Unfortunately I have no suggestions for an implementation, but it would complement all the syntactical niceties already offered by for. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
