> necessarily, but potentially surprising and worth mentioning. The comment
> reader macro #_ works just fine as long as nothing breaks the reader. The
> surprise happens when you don't consider that for namespaced keywords using
> ns aliases, the namespace resolution happens at rea
I wouldn't consider this a bug or even an unfortunate behavior necessarily,
but potentially surprising and worth mentioning. The comment reader macro
#_ works just fine as long as nothing breaks the reader. The surprise
happens when you don't consider that for namespaced keywords using ns
Many thanks Alex.
Craig
--
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 appears to be a more general issue that can be reproduced by sending
" " as a single command to the REPL. I was able
to get similar behavior by sending in other types of malformed expressions.
When I hit enter the second time, the valid form came through.
user=> :) 1
RuntimeException
nREPL server started on port 37885 on host 127.0.0.1 -
nrepl://127.0.0.1:37885
REPL-y 0.3.7, nREPL 0.2.12
Clojure 1.9.0-alpha11
OpenJDK 64-Bit Server VM 1.8.0_91-8u91-b14-0ubuntu4~14.04-b14
Docs: (doc function-name-here)
(find-doc "part-of-name-here")
Source: (source
I think this comes down to learning to speak Lisp.
Everyone's first few months of learning to speak Lisp are painful. And then
quite suddenly it becomes natural. Yes, it's possible to write infix
notation for Lisp - I first saw this in InterLisp's CLISP (I think) back in
1985 or so, but it's
bother with a reader macro, when you can use a normal macro?
(infix (2 * x1 * x2) / (x1 + x2))
IMO, the times when it makes sense to use infix notation are fairly few,
anyway. One could write the above as:
(/ (* 2 x1 x2)
(+ x1 x2))
Which to me actually seems more readable than
On 6 April 2014 21:50, Joshua Brulé jtcbr...@gmail.com wrote:
But it still seems to me that in the case *exactly three forms* - binary
function and arguments - curly infix can be a solid improvement on
readability.
(map (fn [x] (cond (zero? {x mod 15}) FizzBuzz
(zero? {x
Though if I was going to write the above, I'd probably write:
(divides-exactly? x 5)
I didn't think of that, and yes, I'd agree that that's better.
I think my main problem with this proposed syntax is that it doesn't
represent a data structure.
And *now *I'm convinced. I was thinking of
Proposal:
For an *odd* number of forms a, x, b, ...
{a x b x c ...} = (x a b c ...)
{a x b y c ...} = (*nfx* a x b y c ...)
Reasoning:
Even after a lot of practice, prefix math is still harder (at least for
me...) to read than non-prefix math. The [], () and matching delimiters
are already
The desire (and rejection) of infix notation for Lisp is as old as the hills.
Therefore we expect future generations of Lisp programmers to continue to
reinvent Algol-style syntax for Lisp, over and over and over again, and we are
equally confident that they will continue, after an initial
Odd-entry-count maps would have corner cases: One would need to use an even
number of unary operators. If an odd number of unary operators were used,
what looked like a valid expression would become a map, and that might be
hard to figure out.
Also, since the order of entries in a map is not
Incanter supports this with the $= prefix:
($= 7 + 8 - 2 * 6 / 2)
http://data-sorcery.org/2010/05/14/infix-math/
Might be worth looking at...
On Thursday, April 3, 2014 11:17:32 PM UTC-5, Joshua Brulé wrote:
Proposal:
For an *odd* number of forms a, x, b, ...
{a x b x c ...} = (x a b c
Why bother with a reader macro, when you can use a normal macro?
(infix (2 * x1 * x2) / (x1 + x2))
IMO, the times when it makes sense to use infix notation are fairly few,
anyway. One could write the above as:
(/ (* 2 x1 x2)
(+ x1 x2))
Which to me actually seems more readable
I prefer Unfix -- http://fogus.me/fun/unfix/ ;-)
On Fri, Apr 4, 2014 at 12:45 PM, Alex Miller a...@puredanger.com wrote:
Incanter supports this with the $= prefix:
($= 7 + 8 - 2 * 6 / 2)
http://data-sorcery.org/2010/05/14/infix-math/
Might be worth looking at...
On Thursday, April 3,
I knew there was another one out there, but couldn't remember whose... !
Thanks...
On Friday, April 4, 2014 2:36:59 PM UTC-5, Fogus wrote:
I prefer Unfix -- http://fogus.me/fun/unfix/ ;-)
On Fri, Apr 4, 2014 at 12:45 PM, Alex Miller
al...@puredanger.comjavascript:
wrote:
Incanter
and / or eval it with a custom eval function in a sandbox. It's easier
to do this in Clojure than in JavaScript because it's easier to write a
custom eval in Clojure than in JavaScript.
One problem with my plan is that the #= reader macro evaluates the code at
read-time, before I have a chance
is that the #= reader macro evaluates the code at
read-time, before I have a chance to analyze or sandbox it. The workarounds
seem to be disabling or removing the #= reader macro or writing my own
custom reader (in addition to a custom evaluator).
I'd be grateful for guidance and advice.
#= was an issue
Also - take a look at:
https://github.com/flatland/clojail
--
Dave
--
--
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
On Tue, Apr 9, 2013 at 10:03 AM, rebcabin bc.beck...@gmail.com wrote:
The workarounds seem to be disabling or removing the #= reader macro or
writing my own custom reader (in addition to a custom evaluator).
Disabling #= by binding *read-eval* to false would cause an exception
Hi,
I'm trying to wrap my head around the role of the #_ macro and how it's
used in core.cljs.
Can some explain, why it is used to prefix (throw.. ) in
(deftype EmptyList [meta]
...
...
IStack
(-peek [coll] nil)
(-pop [coll] #_(throw (js/Error. Can't pop empty list)))
or in
(deftype Vector
The #_ reader macro simply comments out the form, so it's a no op.
Sent from phone, please excuse brevity.
On Mar 26, 2012 10:23 AM, László Török ltoro...@gmail.com wrote:
Hi,
I'm trying to wrap my head around the role of the #_ macro and how it's
used in core.cljs.
Can some explain, why
behavior as in
clojure)?
Las
Baishampayan Ghose 2012. március 26., hétfő napon a következőt írta:
The #_ reader macro simply comments out the form, so it's a no op.
Sent from phone, please excuse brevity.
On Mar 26, 2012 10:23 AM, László Török
ltoro...@gmail.comjavascript:_e({}, 'cvml
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: (shout 1 2), the command print 1, why
the command don't
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
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: (shout 1
I realized that I got the anaphora idiom wrong after I posted. I
changed it in my test code.
Thanks.
On Jun 20, 6:31 am, Jonathan Fischer Friberg odysso...@gmail.com
wrote:
You should use ~' for anaphora.
If for example `~this is used, 'this' is going to be unquoted, and the
content of this
You should use ~' for anaphora.
If for example `~this is used, 'this' is going to be unquoted, and the
content of this will be backquoted.
With ~'this , the symbol this is first quoted, and then that symbol is
unquoted, resulting in the symbol this.
Backquote should by the way definitely not be
I just discovered the #= reader macro from a post on Stackoverflow
and it solves a problem. How likely is this reader macro to become an
official (documented) part of the language? How about deprecated or
changed behavior?
I am trying to use Stuart Sierra's do-template inside a
defprotocol
Check out Seesaw http://github.com/daveray/seesaw. It's a Clojure Swing
wrapper that really cuts back on boilerplate, and will probably serve you
better than rolling your own making-swing-manageable macros.
Happy hacking!
--
You received this message because you are subscribed to the Google
On Wed, Jun 15, 2011 at 10:47 PM, Alex Baranosky
alexander.barano...@gmail.com wrote:
IS it possible to use the regex reader macro # with generated code? What
I mean is do something like:
#${(join | (range 1 1))}
I'm using ${...} to mean string interpolation, though I know Clojure doesn't
2011/6/16 Alex Baranosky alexander.barano...@gmail.com:
IS it possible to use the regex reader macro # with generated code? What
I mean is do something like:
#${(join | (range 1 1))}
I'm using ${...} to mean string interpolation, though I know Clojure doesn't
have that syntax
On Jun 16, 4:47 am, Alex Baranosky alexander.barano...@gmail.com
wrote:
IS it possible to use the regex reader macro # with generated code? What
I mean is do something like:
#${(join | (range 1 1))}
I'm using ${...} to mean string interpolation, though I know Clojure doesn't
have
IS it possible to use the regex reader macro # with generated code? What
I mean is do something like:
#${(join | (range 1 1))}
I'm using ${...} to mean string interpolation, though I know Clojure doesn't
have that syntax. Is there a way to get this effect or must I use
(re-pattern (join
One useful reader macro would be do the analog of a syntax-quote in an
ignored sexp ( #- is the analog of ~ ):
#_(ignore
(continuing to ignore
#-except do not ignore this
and ignore this))
Another language feature that I think many wish for to have some way of
specifying a string
Not an argument against the request, just a reminder: heredocs are subtly
different from quoting. In the traditional shell implementation, a heredoc
starts on the line following the , so you can have stuff like this:
some_command EOF -arg 1 -arg 2
Text of the heredoc.
EOF
You
Also I can try to implement them by myself. I have some ideas how to
do this.
--
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
.
The reader macro above is more concise, yes, but it's also harder to
read and find documentation for anyone else who's reading your code,
because it obeys nonstandard language rules. And that's assuming that
reader macros are even limited to your namespaces rather than globally—
if they happen
hmm...interesting view.
Now I don't have really expressive examples of using reader macro.
Also it seems that I find another way to achieve the functionality
that I need.
So all thanks for discussion.
--
You received this message because you are subscribed to the Google
Groups Clojure group
Well, clojure provides a variety of reader macro. In fact I don't
think that I would need different ones, but I would like to have them
available, simply because I
like concise, purpose-built languages. Besides I don't think that
user created reader macro would damage because
http://briancarper.net/blog/clojure-reader-macros
might interest you.
On 2 February 2010 19:19, A.Rost aravanc...@gmail.com wrote:
I would like to have them available, simply because I
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this
some rationale behind it. So far the only reason I can
think of to have a reader macro is to affect the *reader*.
--
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
with functions and macros. That may be the case, but I'd
like to see some rationale behind it. So far the only reason I can
think of to have a reader macro is to affect the *reader*.
That should read: with *only* functions and macros.
--
You received this message because you are subscribed
2 ataggart
Ok. I don't explain coorect why I want to have build-in ability to
create reader macro.
In my study and job I very often use different spesific data
structures. It's very useful to have reader macro to work with them,
because it makes my code easilier to perception: work with data
a look on Clojure. It's a very
expressive, elegant language, but user-defined reader macro are
prohibited.
I've read all discussions about this. I realize that using user-
defined reader macro can be evil, but I think there is no point to
restrict them. I suppose that using them in the right way can
De gustibus non est disputandum.
That said, I'd be interested in seeing a clojure example which
benefits from a currently-non-existant reader macro.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure
On Mon, Oct 12, 2009 at 01:31, James Reeves weavejes...@googlemail.com wrote:
What if you need to use braces? It seems to me that any syntax for
representing long strings needs a terminator that is unlikely to occur
within the string itself. For example, Python uses , and XML CDATA
uses ]],
2009/10/13 B Smith-Mannschott bsmith.o...@gmail.com
On Mon, Oct 12, 2009 at 01:31, James Reeves weavejes...@googlemail.com
wrote:
What if you need to use braces? It seems to me that any syntax for
representing long strings needs a terminator that is unlikely to occur
within the string
(0) I'm not feeling the itch for verbatim strings, seeing as clojure
already does multi-line literals (with escaping) and has special
syntax for regex patterns.
That's unfortunate, as I think it would be an important addition to
the language. I didn't know Clojure's # doesn't require extra
Perl and Ruby do something similar with regular expressions, where the
character following 'm' or 's' becomes the delimiter for that
expression, making 'm/\/some\/path/' identical to 'm!/some/path!'. The
delimeter can be 'smart' as well, where the closing delimiter is
dependent upon the opening
I'm aware that this already has been discussed, and until recently I
was content with clojure not exposing the readtable, because of the
inherent modular problems. However, for CL, a nice approach to
readtables was lately released:
I'm not sure I follow what John is saying (some of the terminology is
unfamiliar to me, what the heck's a digraph? :p), but is he suggesting
that $+ not be followed by a whitespace to count as a string? If so, I
think that's undesirable as that is 1) confusing, and 2) limits the
sorts of
Forgive me, but I'm unfamiliar with the readtable, are you just
referring to where this syntax might be implemented? Or are you
suggesting an alternative syntax?
- Greg
On Oct 12, 2009, at 11:20 AM, DanL wrote:
I'm aware that this already has been discussed, and until recently I
was
On 12 Okt., 20:46, Greg g...@kinostudios.com wrote:
Forgive me, but I'm unfamiliar with the readtable, are you just
referring to where this syntax might be implemented? Or are you
suggesting an alternative syntax?
I'm suggesting that the readtable might be exposed to user changes as
it
2009/10/12 Greg g...@kinostudios.com:
I'm not sure I follow what John is saying (some of the terminology is
unfamiliar to me, what the heck's a digraph? :p), but is he suggesting
My understanding of a digraph is basically two characters that
together represent one real character. e.g. if you
On Oct 12, 2009, at 3:29 PM, Michael Wood wrote:
No, he's saying you could use $+ some string + or $% some string % or
$* some string * etc. to mean the same as some string , so the
thing immediately following the $ sign must not be a space, but could
be basically anything else.
Ah, so
Ah, I think I understand... but if you're saying that this should be
something that can be done on an individual basis I think that's a bad
idea, it would lead to confusing looking code and inconsistencies.
There should be an officially sanctioned .. whatever it is this thing
is called.
Lua's solution to long strings is having multiple levels of
delimiters. [[ is the opening delimiter of level 0, and is closed
by ]] . [=[ is of level 1, closed by ]=] , etc.
No matter what string you are trying to represent, it can always be
literally represented that way.
On 12 out, 17:25, Greg
On Mon, Oct 12, 2009 at 4:21 PM, Greg g...@kinostudios.com wrote:
My only concern, and perhaps John could elaborate on this because he
touched on it, would be how are Java nested classes protected from
this? Wouldn't it interfere with them? Or will the delimiters be
restricted to
If a keeping syntax simple and singular is the goal, the reader macro could use
the proposed #s{ ... } form, while supporting balanced braces in the verbatim
text. The text literal would close when the number of closing braces matches
the number of opening braces. Strings containing unmatched
What if you need to use braces? It seems to me that any syntax for
representing long strings needs a terminator that is unlikely to occur
within the string itself. For example, Python uses , and XML CDATA
uses ]], both of which are character sequences unlikely to turn up in
a string. By contrast,
True, and it is why newLISP uses two delimiters for this purpose, {}
and [text][/text]. The latter might not work well in clojure though
because of its use of arrays.
The former is used for short strings, often for the purpose of regular
expressions or to avoid quoting quotes, and the
-quotes to be nicer than #s{}, which is
(IMO) visually repellent.
The reader macro approach has no significant advantage over triple
quotes, because either way involves a change to Clojure's Java code.
Indeed, it might be impossible to escape } within the reader macro
version, which defeats
syntax will require escaping *something*, whether it be
quotes or curly braces -- so don't view this as me championing
anything.
I certainly consider triple-quotes to be nicer than #s{}, which is
(IMO) visually repellent.
The reader macro approach has no significant advantage over triple
On Oct 11, 2009, at 9:01 PM, Greg wrote:
The purpose of which would be primarily to make writing regular
expressions easier, but also to deal with strings that have quotes
in time
Sorry, that should read quotes in them. ;-)
--~--~-~--~~~---~--~~
You
Ignore that, replied before reading fully to see #s{...} :(
On Mon, Oct 12, 2009 at 3:18 PM, Mark Derricutt m...@talios.com wrote:
{quoted text} is also a map, so conflicts with existing syntax.
On Mon, Oct 12, 2009 at 10:38 AM, Greg g...@kinostudios.com wrote:
(replace {quoted text}
{quoted text} is also a map, so conflicts with existing syntax.
On Mon, Oct 12, 2009 at 10:38 AM, Greg g...@kinostudios.com wrote:
(replace {quoted text} my-str {quoted string})
--~--~-~--~~~---~--~~
You received this message because you are subscribed
How about borrowing a page from LaTeX? That has a \verb+text+ which can use
any desired delimiter character. My thought is to have something like
$+.+ turning whatever was between the character following $ (here, +)
until the next occurrence of that character into a literal string. A way to
On Wed, Aug 26, 2009 at 1:13 PM, John Harrop jharrop...@gmail.com wrote:
This is important to know about for security reasons, also. Specifically,
if you are receiving Clojure data structures in text form over the network,
and don't set *read-eval* to false, you're vulnerable to a Clojure
This is important to know about for security reasons, also. Specifically, if
you are receiving Clojure data structures in text form over the network, and
don't set *read-eval* to false, you're vulnerable to a Clojure injection
attack. Someone could send you (+ 5 #=(System/exit 0)) as a
On Wed, Aug 26, 2009 at 1:13 PM, John Harropjharrop...@gmail.com wrote:
This is important to know about for security reasons, also. Specifically, if
you are receiving Clojure data structures in text form over the network, and
don't set *read-eval* to false, you're vulnerable to a Clojure
#= is a real Clojure reader macro. It often shows up when using *print-
dup*:
Clojure 1.0.0-
user= (binding [*print-dup* true] (println {:a 3, :b 2}))
#=(clojure.lang.PersistentArrayMap/create {:a 3, :b 2})
nil
user= #=(clojure.lang.PersistentArrayMap/create {:a 3, :b 2})
{:b 2, :a 3}
It's
It's undocumented in http://clojure.org/reader. What is its name? What
does it precisely do?
It's EvalReader. What it does is cause the expression to be
evaluated at read time:
user= (read-string (+ 5 #=(* 9 9)))
(+ 5 81)
You can prevent this occurring by binding *read-eval*:
user=
Incidentally, you can find this stuff out by reading the source, if
you know where to look. It's a reader macro, so LispReader.java is the
best place to start. Look for the metachar '=', which crops up on line
91:
http://github.com/richhickey/clojure/blob
That's great! Thanks a lot for the explanation.
On Aug 25, 2:58 pm, Richard Newman holyg...@gmail.com wrote:
Incidentally, you can find this stuff out by reading the source, if
you know where to look. It's a reader macro, so LispReader.java is the
best place to start. Look
I am trying to do the equivalent of a syntax-quote (converting
unqualified symbols to namespace-qualified symbols) inside a macro,
but it seems there is no built-in function to do this. Am I
overlooking something?
At the moment I am using the following function, which does a syntax-
quote
On Feb 26, 2009, at 13:04, Konrad Hinsen wrote:
Of course that should better be
...
so that it doesn't mess up already qualified symbols.
And even that is not good enough: it won't handle symbols/vars from
other namespaces that are referred to. And that's where I am lost. I
can't find
On Thu, Feb 26, 2009 at 9:36 AM, Konrad Hinsen
konrad.hin...@laposte.net wrote:
I figured out one way to do it, but it relies on features that are
perhaps not safe to rely on: I get var first, and then I get the
var's namespace from its public attribute ns:
(defn qualified-symbol
[s]
On 26.02.2009, at 20:25, Chouser wrote:
I've got essentially the same thing for use in error-kit:
(defn- qualify-sym [sym]
(let [v (resolve sym)]
(assert v)
(apply symbol (map #(str (% ^v)) [:ns :name]
Except that you get the information from the metadata. I wonder
Following up on my own post:
Jan Rychter j...@rychter.com writes:
Rich Hickey richhic...@gmail.com writes:
On Jan 26, 11:15 am, Cosmin Stejerean cstejer...@gmail.com wrote:
On Mon, Jan 26, 2009 at 6:34 AM, Rich Hickey richhic...@gmail.com wrote:
On Jan 25, 4:10 pm, Laurent PETIT
On Feb 22, 2009, at 4:41 AM, Jan Rychter wrote:
Following up on my own post:
Jan Rychter j...@rychter.com writes:
Rich Hickey richhic...@gmail.com writes:
On Jan 26, 11:15 am, Cosmin Stejerean cstejer...@gmail.com wrote:
On Mon, Jan 26, 2009 at 6:34 AM, Rich Hickey
richhic...@gmail.com
Rich Hickey richhic...@gmail.com writes:
[...]
How about #_ ?
I would prefer #-, but if you think you might want to have a reader
conditional system similar to CL in the future, #_ is fine as well.
Actually, any character is better than plucking out multi-line
forms and
commenting them
On Jan 25, 4:10 pm, Laurent PETIT laurent.pe...@gmail.com wrote:
#- makes sense (CL didn't always make things the wrong way :-)
And indeed, #; *could* break a lot of already existing editors for a while
Yes, the issues are:
#; is bad for editors
#- would be incompatible with CL's #-, and
On Mon, Jan 26, 2009 at 6:34 AM, Rich Hickey richhic...@gmail.com wrote:
On Jan 25, 4:10 pm, Laurent PETIT laurent.pe...@gmail.com wrote:
#- makes sense (CL didn't always make things the wrong way :-)
And indeed, #; *could* break a lot of already existing editors for a
while
Yes,
Rich Hickey wrote:
On Jan 25, 4:10 pm, Laurent PETIT laurent.pe...@gmail.com wrote:
#- makes sense (CL didn't always make things the wrong way :-)
And indeed, #; *could* break a lot of already existing editors for a while
Yes, the issues are:
#; is bad for editors
#- would be
Rich Hickey richhic...@gmail.com writes:
On Jan 26, 11:15 am, Cosmin Stejerean cstejer...@gmail.com wrote:
On Mon, Jan 26, 2009 at 6:34 AM, Rich Hickey richhic...@gmail.com wrote:
On Jan 25, 4:10 pm, Laurent PETIT laurent.pe...@gmail.com wrote:
#- makes sense (CL didn't always make things
Clojure has that in the comment form: (comment (do (not (eval this
--~--~-~--~~~---~--~~
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
Hi,
Am 25.01.2009 um 17:11 schrieb Zak Wilson:
Clojure has that in the comment form: (comment (do (not (eval this
No. That's not equivalent. comment leaves a nil behind, while #*
would not.
[:a (comment :b) :c] = [:a nil :c]
[:a #* :b :c] = [:a :c]
Sincerely
Meikel
smime.p7s
]
Exactly. In CL you can use #-(and) for anything, for example function
arguments. I use it like that way regularly while developing code. It
has to be a reader macro.
--J.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
On Mon, Jan 19, 2009 at 12:24 PM, Chouser chou...@gmail.com wrote:
#^ - metadata
#^ adds metadata at read-time, so there's no way for a function to do
exactly the same thing, though 'with-meta' does something similar at
runtime.
I've noticed this as well. It seems to me that this
Hi,
Am 19.01.2009 um 19:15 schrieb David Nolen:
I've noticed this as well. It seems to me that this prevents you
from dynamically defining a var (like in a macro) that has metadata
attached to it or it's arguments (if it's a function). Is there no
way around how the reader works? Can
On Jan 19, 1:15 pm, David Nolen dnolen.li...@gmail.com wrote:
I've noticed this as well. It seems to me that this prevents you from
dynamically defining a var (like in a macro) that has metadata attached to
it or it's arguments (if it's a function).
You can also use the new alter-meta!
Wow, nice!
On Mon, Jan 19, 2009 at 1:47 PM, Stuart Sierra
the.stuart.sie...@gmail.comwrote:
On Jan 19, 1:15 pm, David Nolen dnolen.li...@gmail.com wrote:
I've noticed this as well. It seems to me that this prevents you from
dynamically defining a var (like in a macro) that has metadata
Works. amazing.
On Mon, Jan 19, 2009 at 4:51 PM, David Nolen dnolen.li...@gmail.com wrote:
Actually, so this can't be used on structs for fns?
On Mon, Jan 19, 2009 at 1:47 PM, Stuart Sierra
the.stuart.sie...@gmail.com wrote:
On Jan 19, 1:15 pm, David Nolen dnolen.li...@gmail.com wrote:
94 matches
Mail list logo
