Metadata is perhaps most frequently used on vars:
user=> (meta #'comp)
{:arglists ([] [f] [f g] [f g & fs]),
:doc
"Takes a set of functions and returns a fn that is the composition\n of
those fns. The returned fn takes a variable number of args,\n applies the
rightmost of fns to the args, the
Codox looks for ^no-doc when it is generating documentation to elide docs
for that function or namespace.
On Thu, 6 Aug 2015 at 12:24 AM Eric Le Goff wrote:
> The page http://clojure.org/metadata states that it "can also be used by
> application developers for many purposes, annotating data sourc
Thank you very much to all!
Now I completely understand the metadata behavior with the reader. I'll try
to adopt eastwood, thanks for the suggestion.
Is clearly that the documentation confuses a little bit.
Cheers!
Andrey
2015-05-05 23:25 GMT+02:00 James Reeves :
> The documentation is rather
In reference to [1]:
I do feel like the metadata loss on many macros is undesirable though and I
wish it were addressed. It certainly feels "unhygienic", just in a new sense
of the term.
[1] https://github.com/jonase/eastwood#unused-meta-on-macro
--
You received this message because you are
+1 to Eastwood. It is great.
--
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 t
The Eastwood [1] Clojure lint tool has a few warnings in it that warn about
unused metadata in your code.
The :unused-meta-on-macro warns about metadata on macro invocations, which
is usually ignored by Clojure [2].
The :wrong-tag warns about unused type tag metadata on Vars, and
non-fully-qualif
What you wanted here was
(meta '^:abc some-symbol)
It's a little weird but the reader attaches the metadata to the symbol. Then
the quote just evaluates directly to the same symbol, so the metadata is
preserved.
I agree that metadata can be confusing though. Especially around where AND HOW
>From your comments, I suspect this may be a source of confusion as well:
When you have something like (defn ^{:doc "Increments"} a-fn [x] (+ x 1))
the metadata is attached to the symbol at read time. However, during the
compilation process, the metadata on the symbol is transferred to the Var
Because ' is a reader macro which expands to the list (quote some-symbol),
so the metadata is applied to the list, and not the symbol. You can verify
this in the REPL - (meta (quote ^:abc 'some-symbol))
On Tuesday, May 5, 2015 at 5:43:19 PM UTC-4, Andy- wrote:
>
> Frankly, I would've (meta ^:abc
I expect because 'some-symbol is shorthand for (quote some-symbol), so
you're attaching the metadata to a list that disappears once it's evaluated.
- James
On 5 May 2015 at 22:43, Andy- wrote:
> Frankly, I would've (meta ^:abc 'some-symbol) expected to work. Maybe
> somebody else can weigh in o
Frankly, I would've (meta ^:abc 'some-symbol) expected to work. Maybe
somebody else can weigh in on why this one is a no-go.
On Tuesday, May 5, 2015 at 5:01:19 PM UTC-4, Andrey Antukh wrote:
>
> Thanks to both for the responses, but I stil not clearly understand.
>
> The documentation says very c
The documentation is rather misleading, as it implies that "obj" can be a
symbol. However, because ^ is a reader macro, it is applied to "obj" before
it is evaluated.
Clojure maps, vectors and sets all evaluate to themselves, so attaching
metadata to the unevaluated expression via the ^ reader mac
Thanks to both for the responses, but I stil not clearly understand.
The documentation says very clearly that:
In addition to with-meta, there are a number of reader macros (The Reader:
Macro Characters) for applying metadata to the expression following it:
^{:doc "How obj works!"} obj - Sets the
In addition to James comment: IMO clojure.org/metadata should be clearer
about this. It's mentioned more clearly on the reader page:
http://clojure.org/reader#The%20Reader--Macro%20characters
"The metadata reader macro first reads the metadata and attaches it to the
next form read (see with-meta
When dealing with metadata, it's important to understand the difference
between these two expressions:
^{:foo :bar} baz
(with-meta baz {:foo :bar})
The first expression attaches metadata to the 'baz' symbol at compile time.
The second expression attaches metadata to the data held in 'baz
Since there seems to be interest in the exact mechanics:
For every special form there exists a subclass of Expr in the clojure
compiler, which represents the special form in the analysis result. Every
such class directly implements the behavior of the special form in terms of
compiler infrastructu
Ummm... Jean, I don't understand.
Recapitulation. As Herwig showed, the symbol has its metadata WITHOUT
evaluation:
user=> (meta (second (read-string "(def ^{:key (+ 1 1)} foo)")))
{:key (+ 1 1)}
"second", in the above expression, retrieves the symbol "foo", and reader
already set its metadata W
On Tuesday, March 19, 2013 11:49:45 AM UTC+1, ajlopez wrote:
>
> Thanks Jean!
>
> Yes, I did that test before my email.
>
> But my doubt is:
>
> What part is in charge of metadata evaluation?
>
As Herwig commented: The part which evaluates metadata is without doubt the
lisp evaluator's work, th
The evaluation of meta data happens when the def form is evaluated:
user=> (meta (second (read-string "(def ^{:key (+ 1 1)} foo)")))
{:key (+ 1 1)}
vis a vis
user=> (meta (eval (read-string "(def ^{:key (+ 1 1)} foo)")))
{:ns #, :name foo, :file "NO_SOURCE_PATH", :line 1, :key 2}
The reader doe
On Tuesday, March 19, 2013 9:49:09 AM UTC+1, ajlopez wrote:
>
> Hi everyone!
Hi!
The easiest thing to find out of this would be to check it out:
(def ^{:a (+ 1 1)} two 2)
;=> user/two
(meta #'two)
;=> { :a 2}
So indeed, the forms within metadata is evaluated.
-- Jean Niklas L'orange
Hi,
Am 28.12.2011 um 10:32 schrieb liulei:
> I write one function,example:
>
> (defn #^{:return String} shout [#^{:tag String} s #^{:tag String} s1]
> (.toUpperCase s))
>
> The function has two parameters: s and s1, I hope the two parameters
> are both String type.
> But I run the command: (sh
Hi LiuLei,
Clojure's type hints are just that, hints. They're only there to help the
compiler emit more efficient bytecode without using Java reflection. They
are not type declarations, and they are not enforced by the compiler.
-Stuart Sierra
clojure.com
--
You received this message because
Relevant IRC thread -
http://clojure-log.n01se.net/date/2011-03-01.html#12:41
On Tue, Oct 11, 2011 at 8:53 PM, Brian Marick wrote:
>
> On Oct 11, 2011, at 7:48 PM, Stuart Sierra wrote:
>
> > I suppose you could iterate over all known Vars and construct a map from
> fns to the Vars that contain t
This. Metadata on functions in 1.2 was mostly accidental, from what I
can tell.
On Oct 11, 6:39 pm, Sam Ritchie wrote:
> I remember not really understanding the way defn hung metadata off of its
> functions. In 1.2, it returned different responses on successive calls to
> defn. for example:
>
> u
I remember not really understanding the way defn hung metadata off of its
functions. In 1.2, it returned different responses on successive calls to
defn. for example:
user> (clojure-version)
"1.2.1"
user> (defn my-func "a docstring!" [x] x)
#'user/my-func
user> (meta #'my-func) ;; var first
{:ns #
On Oct 11, 2011, at 8:53 PM, Brian Marick wrote:
>
> On Oct 11, 2011, at 7:48 PM, Stuart Sierra wrote:
>
>> I suppose you could iterate over all known Vars and construct a map from fns
>> to the Vars that contain them. Then, given a fn, you can look up the Var and
>> get its metadata. It woul
On Oct 11, 2011, at 7:48 PM, Stuart Sierra wrote:
> I suppose you could iterate over all known Vars and construct a map from fns
> to the Vars that contain them. Then, given a fn, you can look up the Var and
> get its metadata. It would break if anyone redefines or binds the Var, of
> course.
I suppose you could iterate over all known Vars and construct a map from fns
to the Vars that contain them. Then, given a fn, you can look up the Var and
get its metadata. It would break if anyone redefines or binds the Var, of
course.
-S
--
You received this message because you are subscribe
On Tue, Oct 11, 2011 at 5:22 PM, Brian Marick wrote:
> I understand that. Useful code is sometimes given a function object to work
> with, not a Var.
Ah, I get your point now...
What about:
(meta (var odd?))
(meta (resolve 'odd?))
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- h
On Oct 11, 2011, at 7:20 PM, Sean Corfield wrote:
> user=> (meta #'clojure.core/odd?)
> {:ns #, :name odd?, :arglists ([n]), :added
> "1.0", :static true, :doc "Returns true if n is odd, throws an
> exception if n is not an integer", :line 1323, :file
> "clojure/core.clj"}
I understand that. Usef
On Tue, Oct 11, 2011 at 5:13 PM, Brian Marick wrote:
> In 1.3, this metadata is missing:
>
> user=> (meta odd?)
> nil
user=> (meta #'clojure.core/odd?)
{:ns #, :name odd?, :arglists ([n]), :added
"1.0", :static true, :doc "Returns true if n is odd, throws an
exception if n is not an integer", :li
Razvan Rotaru wrote:
> Is there a way to attach metadata to defrecord ?
Is this what you are looking for?
(defrecord MyRecord [a b])
(let [r (with-meta (MyRecord. 1 2) {:extra 100})]
(meta r))
;;-> {:extra 100}
-David
--
You received this message because you are subscribed to the Google
Gro
I upgraded lein from 1.3.1 to 1.4.2, which fixed the problem.
:)
On Jan 10, 6:47 am, Stefan Kamphausen wrote:
> Hi,
>
> I can't verify that a REPL created by lein behaves differently. Did you
> perhaps update an old project.el without running lein deps?
>
> In addition to that: your defproject h
Hi,
I can't verify that a REPL created by lein behaves differently. Did you
perhaps update an old project.el without running lein deps?
In addition to that: your defproject has too many ]'s
Regards,
Stefan
--
You received this message because you are subscribed to the Google
Groups "Clojur
Hi,
On 10 Jan., 14:36, Tim Robinson wrote:
> Interesting.
Suspicious, I'd say.
> My downloaded version of clojure 1.2.0 acts exactly as you describe.
>
> However my basic lein project with only
>
> (defproject prj "1.0.0-SNAPSHOT"
> :dependencies [[org.clojure/clojure "1.2.0"]]])
>
> act
Interesting.
My downloaded version of clojure 1.2.0 acts exactly as you describe.
However my basic lein project with only
(defproject prj "1.0.0-SNAPSHOT"
:dependencies [[org.clojure/clojure "1.2.0"]]])
acts differently.
Well as I said, I can never sure about anything :)
Cheers
Tim
On J
Hi Meikel,
On 10 Jan., 01:09, Meikel Brandmeyer wrote:
> Because 'o expands to (quote o) and you actually hint this list. You might
> try (meta ' ^:k o).
Very interesting, this works! I did not know that syntax and none of
my books or the reader section of clojure.org mentioned it.
Thanks a lo
Hi,
On 10 Jan., 04:17, Tim Robinson wrote:
> How does this happen when :tag is not even in the expression?
> If you launch a brand new repl and run it what happens?
What I posted in the previous email is exactly a fresh repl session
and what happens there with 1.2. And in fact, that it is what
user=> (meta '^:k o)
{:tag :k}
How does this happen when :tag is not even in the expression?
If you launch a brand new repl and run it what happens?
On Jan 9, 5:17 pm, Meikel Brandmeyer wrote:
> Hi,
>
> Am 10.01.2011 um 01:10 schrieb Tim Robinson:
>
> > You must have something messed up:
>
> > I
Am I sure?.. No, I'm never sure :)
But I am using 1.2 and when I run (meta ^:k []) or even (meta '^:k o)
I get nil.
Plus:
app=> (doc meta)
-
clojure.core/meta
([obj])
Returns the metadata of obj, returns nil if there is no metadata.
nil
I could be missing something?
Hi,
Am 10.01.2011 um 01:10 schrieb Tim Robinson:
> You must have something messed up:
>
> In line 1 (meta ^:k []) does not return {:tag :k} it returns nil and
> I am using Clojure 1.2.
>
> Both lines 1 and 2, shouldn't return meta, because 'meta' only takes
> an object as an input argument.
>
You must have something messed up:
In line 1 (meta ^:k []) does not return {:tag :k} it returns nil and
I am using Clojure 1.2.
Both lines 1 and 2, shouldn't return meta, because 'meta' only takes
an object as an input argument.
And only if the object already has metadata will metadata will retu
Hi,
Am 09.01.2011 um 22:52 schrieb mdzaebel:
> (meta ^:k []) --> {:tag :k}
> (meta ^:k 'o) --> nil
> (meta(with-meta 'o {:tag :k})) --> {:tag :v}
>
> Why doesn't the second line return the metadata?
Because 'o expands to (quote o) and you actually hint this list. You might try
(meta ' ^:k
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)
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 se
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 d
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, wher
That's perfect. Thanks a lot, everyone.
On Sep 20, 11:35 am, Jarkko Oranen wrote:
> > > (def b #^{:b 2} (quote (1 2 3)))
>
> > ... and #^{} applies read-time to the following *form* rather than the
> > value they evaluate to, so that is why neither (list ...) nor (quote
> > ...) work.
>
> Yep. #
> > (def b #^{:b 2} (quote (1 2 3)))
>
> ... and #^{} applies read-time to the following *form* rather than the
> value they evaluate to, so that is why neither (list ...) nor (quote
> ...) work.
Yep. #^ is for read-time metadata. Note though that the following will
work:
(def b '#^{:b 2} (1 2 3)
On Sun, Sep 20, 2009 at 7:25 PM, Christian Vest Hansen
wrote:
> On Sun, Sep 20, 2009 at 6:20 PM, samppi wrote:
>>
>> I was messing with the REPL when I found this happens:
>>
>> Clojure 1.0.0-
>> user=> (def a #^{:a 5} [1 2 3])
>> #'user/a
>> user=> ^a
>> {:a 5}
>> user=> (def b #^{:b 2} '(1 2 3
On Sun, Sep 20, 2009 at 6:20 PM, samppi wrote:
>
> I was messing with the REPL when I found this happens:
>
> Clojure 1.0.0-
> user=> (def a #^{:a 5} [1 2 3])
> #'user/a
> user=> ^a
> {:a 5}
> user=> (def b #^{:b 2} '(1 2 3))
You have a quote symbol in there, so that line can also be written as:
I just checked against the latest 1.1 snapshot. It
returns the same result as you outlined here.
On Sun, Sep 20, 2009 at 12:20 PM, samppi wrote:
>
> I was messing with the REPL when I found this happens:
>
> Clojure 1.0.0-
> user=> (def a #^{:a 5} [1 2 3])
> #'user/a
> user=> ^a
> {:a 5}
> user=
Hmm, I also note that:
(def b #^{:b 2} (quote (1 2 3))) ; ^b -> {:line 1}
(def b #^{:b 2} (list 1 2 3)) ; ^b -> nil
On Sun, Sep 20, 2009 at 12:20 PM, samppi wrote:
>
> I was messing with the REPL when I found this happens:
>
> Clojure 1.0.0-
> user=> (def a #^{:a 5} [1 2 3])
> #'user/a
> user=>
On Thu, Apr 30, 2009 at 9:46 AM, Rich Hickey wrote:
> However, there isn't a list, and metadata propagation could use an
> audit. If there's a specific case where you think it should and it
> doesn't please let me know.
I think it just took me a while to figure out that cons does not
preserve me
On Apr 30, 12:34 pm, Mark Engelberg wrote:
> On Thu, Apr 30, 2009 at 6:01 AM, Rich Hickey wrote:
> > Then, you need to know which operations require metadata propagation.
> > That's built into the Clojure data structures but can't be retrofitted
> > to arbitrary types.
>
> Is there a list of w
On Thu, Apr 30, 2009 at 6:01 AM, Rich Hickey wrote:
> Then, you need to know which operations require metadata propagation.
> That's built into the Clojure data structures but can't be retrofitted
> to arbitrary types.
Is there a list of which operations propagate metadata? I know I've
been sur
On Apr 30, 1:41 am, Laurent PETIT wrote:
> Hi,
>
> 2009/4/30 Stuart Sierra :
>
>
>
> > On Apr 29, 5:58 pm, Stu Hood wrote:
> >> Instead of attaching the metadata directly to the object, what if the
> >> metadata was stored outside the object, in a global map of {object
> >> metadata,
> >> ...
Hi,
2009/4/30 Stuart Sierra :
>
> On Apr 29, 5:58 pm, Stu Hood wrote:
>> Instead of attaching the metadata directly to the object, what if the
>> metadata was stored outside the object, in a global map of {object metadata,
>> ...}? In order to handle garbage collection, something similar to Java
On Apr 29, 5:58 pm, Stu Hood wrote:
> Instead of attaching the metadata directly to the object, what if the
> metadata was stored outside the object, in a global map of {object metadata,
> ...}? In order to handle garbage collection, something similar to Java's
> WeakHashMap could be used, with t
On Mar 4, 11:31 pm, Meikel Brandmeyer wrote:
> (ns foo.bar
> "docstring goes here"
> ...)
Thanks a lot, this works for me. (Perhaps this should be mentioned in
the documentation of the ns-form.)
--~--~-~--~~~---~--~~
You received this message because you are
Hi,
Am 04.03.2009 um 23:24 schrieb pmf:
is there a way to attach metadata (especially a docstring) to
namespaces? The Namespace-class implements (via AReference ->
IReference -> IMeta) the IMeta-interface, but the obvious way of using
the reader-macro to attach metadata does not work and I don'
On Mar 4, 10:46 am, Konrad Hinsen wrote:
> On Mar 4, 2009, at 15:09, Rich Hickey wrote:
>
> > Supporting with-meta for fns requires they be copyable with
> > new metadata (as are all the persistent collections and symbols). I
> > haven't decided how best to support that copyability for fns that
On Mar 4, 2009, at 15:09, Rich Hickey wrote:
> Supporting with-meta for fns requires they be copyable with
> new metadata (as are all the persistent collections and symbols). I
> haven't decided how best to support that copyability for fns that are
> closures while minimizing the overhead for fns
On Mar 4, 2009, at 7:50 AM, Konrad Hinsen wrote:
>
> Rich,
>
> is there a reason why metadata is explicitly disabled on function
> objects?
>
> I find myself wanting to put metadata on functions frequently. It
> seems even more important for functions than for anything else, given
> that there i
On Wed, Mar 4, 2009 at 12:50 PM, Konrad Hinsen wrote:
>
> Rich,
>
> is there a reason why metadata is explicitly disabled on function
> objects?
>
> I find myself wanting to put metadata on functions frequently. It
> seems even more important for functions than for anything else, given
> that ther
On Jan 7, 10:37 am, Rich Hickey wrote:
> On Jan 7, 1:01 am, "rzeze...@gmail.com" wrote:
>
> > Looking at how the #^ macro is used in core.clj confuses me even more.
>
> > For example:
>
> > user=> (def #^{:arglist '([name]) :doc "Say hello."} hello (fn hello
> > [name] (println (str "Hello, "
On Jan 7, 1:01 am, "rzeze...@gmail.com" wrote:
> Looking at how the #^ macro is used in core.clj confuses me even more.
>
> For example:
>
> user=> (def #^{:arglist '([name]) :doc "Say hello."} hello (fn hello
> [name] (println (str "Hello, " name
> #'user/hello
> user=> (hello "ryan")
> He
rzeze...@gmail.com a écrit :
> Looking at how the #^ macro is used in core.clj confuses me even more.
>
> For example:
>
> user=> (def #^{:arglist '([name]) :doc "Say hello."} hello (fn hello
> [name] (println (str "Hello, " name
> #'user/hello
> user=> (hello "ryan")
> Hello, ryan
> nil
>
> I
Looking at how the #^ macro is used in core.clj confuses me even more.
For example:
user=> (def #^{:arglist '([name]) :doc "Say hello."} hello (fn hello
[name] (println (str "Hello, " name
#'user/hello
user=> (hello "ryan")
Hello, ryan
nil
I mean I kind of follow it, but not totally. Is th
On Jan 6, 11:35 pm, wubbie wrote:
> Hi,
> Here is the question on differences between with-meta and #^
> Specifically 1) and 2) are different in that 1) has meta info carried
> over
> to jumping-wubbie, while 2) has not.
> What's the rationale behind this?
>
> user=> (def wubbie {:name "Wubbie"
On Oct 11, 2:33 am, Jeff V <[EMAIL PROTECTED]> wrote:
> Do multimethods support doc strings or other metadata?
defmulti had been replacing any metadata on the name with a type hint.
I've changed it (SVN rev 1060) so that it adds to any metadata on the
name.
So, for now, defmulti doesn't have the
71 matches
Mail list logo
