The "correct" way to do this is:
(defn function-form? [x]
(let [x' (macroexpand x)]
(and (sequential? x') (= 'fn* (first x')))))
However, the approach you're describing won't work with let-bound
variables, only inline function definitions and vars, which means that your
macro is a limited subset of Clojure, rather than a small extension of it.
People generally find that to be confusing. If this is just for your own
personal use, go nuts, but if this is meant to be understood and used by
others, I suggest thinking carefully about whether this the approach you
want to use.
Zach
On Tuesday, December 8, 2015 at 9:18:05 AM UTC-8, Gregg Reynolds wrote:
>
>
>
> On Tue, Dec 8, 2015 at 7:16 AM, Angel Java Lopez <ajlop...@gmail.com
> <javascript:>> wrote:
>
>> Hi!
>>
>> Sorry, this is not an answer, but a question: Why you need to know if an
>> argument is a lambda? What is your use case?
>>
>
> A simple use case (somewhat different from my actual case, but clearer)
> would be dynamic function dispatch. You have a vector of functions and a
> dispatch function that takes a vector of args and selects the "best match"
> from the fns vector.
>
> If things are expressed like so:
>
> (defn f1 ...) (defn f2 ...) ...
> (def fns [f1 f2 ...])
>
> then it's easy: the dispatcher can pull the :arglists from the var
> metadata for the fn symbols and compare it with the incoming args. But if
> you allow inline lambdas you can't (at least I don't know how to) access
> the var metadata. In my case this is a problem because some of my
> functions will have a bit of custom metadata.
>
> To complicate things, let's say we allow clients to register functions,
> using a register-fn function or macro, for example. In my case, I have a
> function and I use it to pre-register some fns defined using #(...)
> syntax. The problem I'm encountering is that these functions do not seem
> to satisfy fn? or any other predicate I can think of to detect that they
> are in fact functions. Their types look like this: class
> miraj.sync$config_polymer_reqs$fn__16463
> miraj.sync$config_polymer_reqs$fn__16463@541276dc - from this it is clear
> that they are function objects, but I don't want to rely on parsing out
> this kind of stuff. FYI mirj.sync is my namespace, config-polymer-reqs is
> my function, and #(...) is expressed in the result of a call to register-fn
> within config-polymer-reqs.
>
> (My use case involves macros and alter-var-root stuff to manage system
> config at startup. I don't have the heart to try to describe it at the
> moment.)
>
> Thanks,
>
> Gregg
>
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
