Re: Clojure 1.3 wonky behavior
Right Rich, Thanks. But that was a simplified reduction of real usage. Typically the declare is found in a nested structure: (describe something (context fooey (with bar 42) ; declare comes from this macro (it works (should= 42 @bar ; here bar be unbound I'll see if I can restructure Speclj to get all the Vars declared at the root level. But I'd still like to know…. Is this defined behavior? Or am I jumping through hoops to avoid behavior that doesn't belong? Micah On Oct 24, 2011, at 7:23 PM, Rich Hickey wrote: You should use 'do' for that kind of thing, not list. Rich On Oct 20, 2011, at 1:53 PM, Micah Martin wrote: I recently tried to get Speclj running on Clojure 1.3 and came across the following problem: (list (declare ^:dynamic p) (defn q [] @p)) (binding [p (atom 10)] (q)) java.lang.ClassCastException: clojure.lang.Var$Unbound cannot be cast to clojure.lang.IDeref Thanks to @cemerick for helping me condense the snippet, and thanks to both @cemerick and @chouser for the lively discussion on IRC. Yet the discussion was inconclusive. Is the above expected behavior? Micah -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure 1.3 wonky behavior
Thanks for the explanation All. I have a much better grasp of what's going on
now.
Just one more question: It is defined behavior, or should I submit a patch for
Clojure 1.3?
Micah
On Oct 20, 2011, at 7:55 PM, Chouser wrote:
On Thu, Oct 20, 2011 at 4:31 PM, Chris Perkins chrisperkin...@gmail.com
wrote:
Note: I forgot to preface that with I think... :) Upon experimenting
briefly, it turns out I was wrong about how Clojure works (that seems to
happen a lot with me). A declare/def defines a var even when it's not
executed!
user (defn xxx [] (declare yyy))
#'user/xxx
user yyy
#Unbound Unbound: #'user/yyy
Well, I learned something today.
But it only interns the Var, it doesn't fully set it up. Particularly
relevant to the OP's example is that the metadata from the name symbol
is not transferred to the Var (and the changes to the Var based on
:dynamic are not applied) until runtime for the 'def', even though the
Var exists at compile time.
Here's a macro that expands at compile time to the *compile* time
metadata of the var named in its argument:
(defmacro compile-time-meta [x] (meta (resolve x)))
Now observe how it behaves differently than a runtime call to 'meta':
(vector
(declare ^:dynamic *myvar*)
(meta #'*myvar*)
(compile-time-meta #'*myvar*)))
The above returns:
[#'user/*myvar*
{:ns #Namespace user, :name *myvar*, :dynamic true, :declared true, ...}
{:ns #Namespace user, :name #Unbound Unbound: #'user/*myvar*}]
First is the Var itself.
Next is the metadata of the Var at runtime, after the entire form has
been compiled and therefore the metadata from the name has been
applied to the Var, including the :dynamic flag.
Finally we see that when our macro was expanded the Var existed but
had minimal metadata. This was after the declare was compiled but
before any part of the 'vector' form was run. There is no :dynamic
flag, and anything that depends on that flag at compile time to work
correctly (such as a function that refers the for Var) will fail to
work correctly.
--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
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Clojure 1.3 wonky behavior
I recently tried to get Speclj running on Clojure 1.3 and came across the following problem: (list (declare ^:dynamic p) (defn q [] @p)) (binding [p (atom 10)] (q)) java.lang.ClassCastException: clojure.lang.Var$Unbound cannot be cast to clojure.lang.IDeref Thanks to @cemerick for helping me condense the snippet, and thanks to both @cemerick and @chouser for the lively discussion on IRC. Yet the discussion was inconclusive. Is the above expected behavior? Micah -- 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
possible (try (finally)) bug
Hi All, I stumbled across this strange behavior... user= (try (finally (doseq [_ [1 2]]))) java.lang.UnsupportedOperationException: Cannot recur from catch/finally (NO_SOURCE_FILE:79) It doesn't seem right to me. Is it a bug? Micah -- 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
macro help
Hey all, I'm having trouble writing a macro and I hoping some one here can help. My desired result is the following: (defroutes all-routes (GET /one (foo one)) (GET /two (foo two)) (GET /three (foo three))) But I'd like to write it like so: (defroutes all-routes (make-foos one two three)) How do I write make-foos? Does if have to be a macro, or can it be a function? Thanks, Micah -- 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: newbie hiccup with hiccup
Yup. 0.2.3 solves the problem. Thanks. Micah On Apr 13, 2010, at 8:38 AM, James Reeves wrote: On 13 April 2010 14:13, Nurullah Akkaya nurul...@nakkaya.com wrote: 0.2.2 fixes this issue. Yes, and currently Hiccup 0.2.3 is the latest version. I'd recommend using 0.2.3, as it has no known bugs as of this post. - James -- 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 To unsubscribe, reply using remove me as the subject. -- 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
