Re: Clojure Jobs in White Plains, NY
On Thu, Feb 4, 2010 at 10:29 PM, Eric Thorsen wrote: > ThorTech Solutions > care...@thotech-solutions.com Is the missing 'r' in the mail address a kind of pre-selection of applicants? ;-) Michael -- 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: Dutch Clojure users
I'm closer to Utrecht (Ede) but the train reaches both places directly. And I work closer to Rotterdam. 2010/2/7 Jeff Rose > There is a group of us hacking Clojure in Amsterdam and Utrecht. > Where are you? Join the Amsterdam Clojurians Google group, and we'll > meet for a pizza. > > -Jeff > > On Feb 6, 12:26 pm, Joop Kiefte wrote: > > Hello folks! > > > > I am from the Netherlands and I am learning Clojure now, using it at > work, > > and loving it so far. Are there any more dutch Clojure programmers on > this > > list so we can meet? I am also interested to know about > Clojure-programmers > > from any country in a reasonable distance from Strasbourg. > > > > Joop Kiefte > > > > -- > > Communication is essential. So we need decent tools when communication is > > lacking, when language capability is hard to acquire... > > > > -http://esperanto.net -http://esperanto-jongeren.nl > > > > Linux-user #496644 (http://counter.li.org) - first touch of linux in > 2004 > > -- > 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 > -- Communication is essential. So we need decent tools when communication is lacking, when language capability is hard to acquire... - http://esperanto.net - http://esperanto-jongeren.nl Linux-user #496644 (http://counter.li.org) - first touch of linux in 2004 -- 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: Dutch Clojure users
Great to hear that there is Clojure group around. For ease of finding it: http://groups.google.com/group/amsterdam-clojurians?hl=en Cheers, Hubert On Sun, Feb 7, 2010 at 4:37 AM, Jeff Rose wrote: > There is a group of us hacking Clojure in Amsterdam and Utrecht. > Where are you? Join the Amsterdam Clojurians Google group, and we'll > meet for a pizza. > > -Jeff > > On Feb 6, 12:26 pm, Joop Kiefte wrote: >> Hello folks! >> >> I am from the Netherlands and I am learning Clojure now, using it at work, >> and loving it so far. Are there any more dutch Clojure programmers on this >> list so we can meet? I am also interested to know about Clojure-programmers >> from any country in a reasonable distance from Strasbourg. >> >> Joop Kiefte >> >> -- >> Communication is essential. So we need decent tools when communication is >> lacking, when language capability is hard to acquire... >> >> -http://esperanto.net -http://esperanto-jongeren.nl >> >> Linux-user #496644 (http://counter.li.org) - first touch of linux in 2004 > > -- > 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
Cartesian product of map pairs w/labels
Imagine a map m {
"foo" [1 2 3 4]
"bar" [\a \b \c]
"baz" [true false]
}
How could I transform that into a seq s (
{"foo" 1 "bar" \a "baz" true}
{"foo" 1 "bar" \a "baz" false}
{"foo" 1 "bar" \b "baz" true}
{"foo" 1 "bar" \b "baz" false}
{"foo" 1 "bar" \c "baz" true}
{"foo" 1 "bar" \c "baz" false}
{"foo" 2 "bar" \a "baz" true}
...
)
I've made a macro to expand the map over a for:
(defmacro cartesian-map [m]
`(for ~(vec (reduce #(concat %1 %2) (map #(identity [(symbol %)
(list 'coordinates %)]) (keys coordinates
~(apply hash-map (flatten (map #(identity [% (symbol %)]) (keys
coordinates))
and expands correctly:
(clojure.core/for [foo (coordinates "foo") bar (coordinates "bar") baz
(coordinates "baz")] {"foo" foo, "bar" bar, "baz" baz})
but when I run it, I only get (), which doesn't make any sense because
if I run the expansion against the map m, it performs correctly.
Why would the macro expand correctly, but no run correctly in the
REPL? Also, are there any ways to simplify my macro?
Rob
--
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: Cartesian product of map pairs w/labels
On 7 February 2010 16:10, Robert Campbell wrote:
> Imagine a map m {
> [ snip ]
> }
>
> How could I transform that into a seq s (
> [ snip ]
> )
To answer this part of the question:
You could (use 'clojure.contrib.combinatorics) (for cartesian-product), then do
(map #(interleave (keys coordinates) %)
(apply cartesian-product (vals coordinates)))
Note that you could parametrise it to make it into a function -- no
macro needed here.
Sincerely,
Michał
--
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: Dutch Clojure users
I'm only 1.5hr flight away in Prague. I'd be happy to host any Clojure users to trade notes over our famous beer. On Sat, Feb 6, 2010 at 12:26 PM, Joop Kiefte wrote: > Hello folks! > I am from the Netherlands and I am learning Clojure now, using it at work, > and loving it so far. Are there any more dutch Clojure programmers on this > list so we can meet? I am also interested to know about Clojure-programmers > from any country in a reasonable distance from Strasbourg. > Joop Kiefte > -- > Communication is essential. So we need decent tools when communication is > lacking, when language capability is hard to acquire... > > - http://esperanto.net - http://esperanto-jongeren.nl > > Linux-user #496644 (http://counter.li.org) - first touch of linux in 2004 > > -- > 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: Cartesian product of map pairs w/labels
Ouch, sorry, I misread your specs... Use this instead:
(map #(zipmap (keys coordinates) %)
(apply cartesian-product (vals coordinates)))
With coordinates bound to your example map, this produces
({"baz" true, "bar" \a, "foo" 1}
{"baz" false, "bar" \a, "foo" 1}
...)
(which is your example output with the keys ordered differently in the
small maps).
Sincerely,
Michał
--
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: Cartesian product of map pairs w/labels
Hi Michał,
That works perfectly and is much simpler, thank you.
On Sun, Feb 7, 2010 at 4:23 PM, Michał Marczyk wrote:
> Ouch, sorry, I misread your specs... Use this instead:
>
> (map #(zipmap (keys coordinates) %)
> (apply cartesian-product (vals coordinates)))
>
> With coordinates bound to your example map, this produces
>
> ({"baz" true, "bar" \a, "foo" 1}
> {"baz" false, "bar" \a, "foo" 1}
> ...)
>
> (which is your example output with the keys ordered differently in the
> small maps).
>
> Sincerely,
> Michał
>
> --
> 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
metadata and defn: why meta returns a non nil value on a function value ?
Hello everyone,
I came upon a weird behaviour of Clojure. Weird as far as I understand
what is going on with metadata. Maybe not very far.
I understand that the reader macro #^ associates metadata with a form,
for use by macros or the compiler as illustrated below.
user=> (defmacro m [form] `(println (meta (quote ~form
#'user/m
user=> (m #^{:foo "bar"} '(1 2 3))
{:line 7, :foo bar}
nil
user=> (m #^{:foo "bar"} x)
{:foo bar}
nil
I think using a macro like m is the only way to get the metadata
associated with the symbol because symbols are different everytime we
construct one, even if their spelling is the same. That explains why
(defn ff [#^Integer x] (println (meta 'x)) x) fails to display the
metadata associated with formal argument x.
But when I define a function with defn augmenting the definition with
metadata, I observe two things I don't understand. I will comment on
the code below to illustrate my problem.
mac:clojure ludo$ clj
Clojure 1.2.0-master-SNAPSHOT
user=> (defn #^{:doc "doubles argument" :tag Integer} f [#^Integer x]
(* x 2))
#'user/f
user=> (meta f)
{:ns #, :name f}
user=> (defn #^{:doc "doubles argument" :tag Integer} f [#^Integer x]
(* x 2))
#'user/f
user=> (meta f)
{:ns #, :name f, :file "NO_SOURCE_PATH", :line
1, :arglists ([x]), :doc "doubles argument", :tag java.lang.Integer}
user=> (meta #'f)
{:ns #, :name f, :file "NO_SOURCE_PATH", :line
3, :arglists ([x]), :doc "doubles argument", :tag java.lang.Integer}
The first defn defines a fuction called f with metadata provided by
the reader for the symbol f and the symbol x. Thus the special form
def (hidden behind the macro defn) takes the metadata and associates
it with the var #'f.
1) When I call (meta f), I get something. I thought there can't be any
metadata on a function value. But I see :ns and :name in the map.
2) If a redefine f with the same call to defn, I get full metadata on
the value of f as well as #'f. As meta is an ordinary function, the
argument f gets evaluated, producing a function value and then I
retrieve the metadata associated with the value and get the whole
stuff as if I called it on #'f.
Point 1 is weird but point 2 is even weirder.
I would be thankful if anyone could provide insights on this problem.
Ludovic Kuty
--
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: Cartesian product of map pairs w/labels
On 7 February 2010 16:28, Robert Campbell wrote: > That works perfectly and is much simpler, thank you. Sure thing! As for your macro producing (), note that it never uses its argument in its body. What it does use instead is something called 'coordinates' -- my guess would be that you had that bound to an empty map (or possibly an empty set -- wouldn't really make a difference) and thus the result was hard-wired to be (). Also, you're using something called flatten in your code to process the result of a call to map -- check out mapcat for a shorter way to do what I think this does. :-) Sincerely, Michał -- 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: metadata and defn: why meta returns a non nil value on a function value ?
My conjecture would be that the Var gets constructed and assigned its
name in the current namespace first, then the function is constructed,
then metadata gets attached to the Var. Thus the first defn pulls
metadata to be attached to the newly constructed function from a newly
constructed Var, whereas the second defn re-uses the Var which was in
place earlier...
This would appear to support the above:
user> (def #^{:foo "bar"} x 5)
#'user/x
user> (meta #'x)
{:ns #, :name x, :file "NO_SOURCE_FILE", :line 1, :foo "bar"}
user> (defn x [] 5)
#'user/x
user> (x)
5
user> (meta x)
{:ns #, :name x, :file "NO_SOURCE_FILE", :line 1, :foo "bar"}
Sincerely,
Michał
--
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: metadata and defn: why meta returns a non nil value on a function value ?
Oh, and of course the final line of the above REPL interaction is this:
user> (meta #'x)
{:ns #, :name x, :file "NO_SOURCE_FILE", :line 1,
:arglists ([])}
Thus there's a sort of an off-by-one error in that the function
created by defn gets the metadata which was attached to its Var
*before* the defn form was evaluated (which will be the metadata of a
newborn Var if the defn form is the first one to have it constructed),
whereas the Var is subsequently given the correct metadata for the
function. Ouch. :-)
Sincerely,
Michał
--
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
Inheriting from IDeref - good idea or bad practise?
Hi folks,
Would those more knowledgable about Clojure care to weigh in on
whether it be a good idea to create a custom class inheriting from
IDeref? I've been considering creating session proxy objects (to be
later replaced with protocols) that would respond to deref calls, e.g.
(def session
(proxy [IDeref] []
(deref [this]
(read-session (.store this)))
(store [this]
{:type ::memory-store})))
Is this a good idea, or is it considered bad practice to use IDeref in
anything apart from core Clojure concurrently primitives?
- 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
Re: Inheriting from IDeref - good idea or bad practise?
I don't know, but it seems like a bad smell that you can't find your
joy by using the built-in state management constructs
( a bad smell in general, not saying on your side or on clojure side )
2010/2/7 James Reeves :
> Hi folks,
>
> Would those more knowledgable about Clojure care to weigh in on
> whether it be a good idea to create a custom class inheriting from
> IDeref? I've been considering creating session proxy objects (to be
> later replaced with protocols) that would respond to deref calls, e.g.
>
> (def session
> (proxy [IDeref] []
> (deref [this]
> (read-session (.store this)))
> (store [this]
> {:type ::memory-store})))
>
> Is this a good idea, or is it considered bad practice to use IDeref in
> anything apart from core Clojure concurrently primitives?
>
> - 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
--
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: Inheriting from IDeref - good idea or bad practise?
On Feb 7, 4:06 pm, Laurent PETIT wrote: > I don't know, but it seems like a bad smell that you can't find your > joy by using the built-in state management constructs The build-in state management constructs only deal with data in memory. I'm thinking "deref" could potentially be more general. For instance, derefing a session object might fetch the corresponding session map from a SQL database. The alternative would be to write some deref-like function with a different name. However, I'm wondering if deref is currently generic enough that it could be used instead. - 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
Re: Inheriting from IDeref - good idea or bad practise?
I can't comment on style, but I can say I successfully made a protocol to implement SoftReferences: (deftype SoftRefHolder [#^java.lang.ref.Reference ref] clojure.lang.IDeref (deref [] (.get ref))) (defn soft-reference "returns a soft reference to x. Access using deref" [x] (let [reference (SoftReference. x) obj (SoftRefHolder reference)] obj)) It works great, and I haven't encountered any problems yet. My interpretation of the clojure source code is that Rich intentionally made "things that can be dereferenced" (IDeref) orthogonal to "things that participate in clojure concurrency" (IRef / Atom / Agent) My one concern about fetching the session map from a database is the cost in time. All the other deref operations take about as much time as grabbing a lock. Going to the DB is an order of magnitude longer. Typically, I use the session data multiple times per request. Maybe if it were cached / memoized, that would be better. Allen On Feb 7, 3:12 pm, James Reeves wrote: > On Feb 7, 4:06 pm, Laurent PETIT wrote: > > > I don't know, but it seems like a bad smell that you can't find your > > joy by using the built-in state management constructs > > The build-in state management constructs only deal with data in > memory. I'm thinking "deref" could potentially be more general. For > instance, derefing a session object might fetch the corresponding > session map from a SQL database. > > The alternative would be to write some deref-like function with a > different name. However, I'm wondering if deref is currently generic > enough that it could be used instead. > > - 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
Re: Inheriting from IDeref - good idea or bad practise?
IMO Anything that implements IDeref should adhere to Clojure's vision
for identity, e.g. reads need to be thread safe, cheap, require no
coordination, and block no one.
Stu
Hi folks,
Would those more knowledgable about Clojure care to weigh in on
whether it be a good idea to create a custom class inheriting from
IDeref? I've been considering creating session proxy objects (to be
later replaced with protocols) that would respond to deref calls, e.g.
(def session
(proxy [IDeref] []
(deref [this]
(read-session (.store this)))
(store [this]
{:type ::memory-store})))
Is this a good idea, or is it considered bad practice to use IDeref in
anything apart from core Clojure concurrently primitives?
- 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
--
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: metadata and defn: why meta returns a non nil value on a function value ?
On 7 February 2010 16:40, Ludovic Kuty wrote: > 1) When I call (meta f), I get something. I thought there can't be any > metadata on a function value. But I see :ns and :name in the map. I completely forgot about the first point... Metadata on functions has been introduced some time ago, can't seem to remember when exactly. Also, I've researched the second issue a little bit more and will post my findings in a second while changing the title of this thread in hope of bringing extra attention to what I think may be a bug in Compiler.java... Sincerely, Michał -- 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
An off-by-one error in attaching metadata to functions defined with defn
Apparently the fn objects constructed with defn will have attached to
them the metadata which was attached to the Var named by the `name'
symbol in the defn form *prior* to the evaluation of defn form -- or
else the metadata of a freshly created Var when the Var did not exist
previously.
I think this is due to DefExpr's eval method binding the Var to
init.eval() first and attaching the supplied metadata to the Var later
-- see Compiler.java lines 341-352. (Note the Var is always already in
place when init.eval() is called, regardless of whether it existed
prior to the evaluation of the def / defn.) Thus the init expression
supplied by defn sees the old (and wrong) metadata on the Var.
Simply switching the if(initProvided) and if(meta != null) around
seems to produce some weird error, though, and my Java-fu is
regrettably too limited for me to be able to suggest a solution. :-(
Please find below a sample interaction at the REPL illustrating the
above (quoted from my earlier answer to Ludovic Kuty).
Sincerely,
Michał
> user> (def #^{:foo "bar"} x 5)
> #'user/x
> user> (meta #'x)
> {:ns #, :name x, :file "NO_SOURCE_FILE", :line 1, :foo "bar"}
> user> (defn x [] 5)
> #'user/x
> user> (x)
> 5
> user> (meta x)
> {:ns #, :name x, :file "NO_SOURCE_FILE", :line 1, :foo "bar"}
> user> (meta #'x)
> {:ns #, :name x, :file "NO_SOURCE_FILE", :line 1,
> :arglists ([])}
--
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
Parallel version of list comprehension
Is there a straight-forward way to get parallelization when using list comprehension? The form of "for" syntax is much preferable to the closest I could come up with using pmap. I also was having trouble getting the correct level of nesting down when using pmap, though probably because I'm tired. If there's nothing like a "pfor", is there a way to algorithmically convert a list comp. into some nested pmaps? -- 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: metadata and defn: why meta returns a non nil value on a function value ?
Thanks for having shared your findings. I saw a post where Rich Hickey mentionned that he was planning to add metadata to functions but I didn't know it was already done from what I saw on the net. On Feb 8, 2:54 am, Michał Marczyk wrote: > On 7 February 2010 16:40, Ludovic Kuty wrote: > > > 1) When I call (meta f), I get something. I thought there can't be any > > metadata on a function value. But I see :ns and :name in the map. > > I completely forgot about the first point... Metadata on functions has > been introduced some time ago, can't seem to remember when exactly. > > Also, I've researched the second issue a little bit more and will post > my findings in a second while changing the title of this thread in > hope of bringing extra attention to what I think may be a bug in > Compiler.java... > > Sincerely, > Michał -- 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 ad on StackOverflow.com
Hi, This is an interesting attempt by the StackOverflow people to promote FOSS projects http://meta.stackoverflow.com/questions/31913/open-source-advertising sidebar-1h-2010/31972 (http://bit.ly/so-foss-ads) I think we should create a couple of Clojure ads and vote them up. Regards, BG -- Baishampayan Ghose oCricket.com -- 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
