Re: a record that implements the iFn protocol can itself be called as a function?
Why not trying it right away in the REPL? user= (defrecord Bar [state]) ; - not implementing IFn user.Bar user= ((-Bar foo)) ClassCastException user.Bar cannot be cast to clojure.lang.IFn user/eval15532 (form-init5689008917050406381.clj:1) user= (defrecord Foo [state] clojure.lang.IFn (invoke [this] (println my state is state))) user.Foo user= ((-Foo foo)) my state is foo nil user= ((-Foo foo bar)) ArityException Wrong number of args (2) passed to: user/eval15486/-Foo--15498 clojure.lang.AFn.throwArity (AFn.java:429) Here you have it: implementing IFn is enough to use a record as a function. You can then implement just the arities you're interested into. Cheers, c. Il giorno giovedì 14 maggio 2015 21:32:37 UTC+2, piast...@gmail.com ha scritto: The docs offer this example: https://clojuredocs.org/clojure.core/defrecord user= (defrecord Someone [nick-name preffered-drink] Fun-Time (drinky-drinky [_] (str nick-name (having preffered-drink ): uuumm))) user.Someone user= (def dude (-Someone belun daiquiri)) #'user/dude user= (drinky-drinky dude) belun(having daiquiri): uuumm But if a record implements clojure.lang.IFn it can be called directly? Do I understand this correctly? When I run macroexpand-all on defrecord-ifn, as defined here: https://github.com/overtone/overtone/blob/e200075da27375727db1f5ce342e2e1c22ea1dbd/src/overtone/helpers/lib.clj I see that it extends clojure.lang.IFn as in: clojure.lang.IFn (invoke [this__1446__auto__] ((fn [this args] (apply synth-player sdef params this [:tail instance-group] args)) this__1446__auto__)) (invoke [this__1447__auto__ arg0] ((fn [this args] (apply synth-player sdef params this [:tail instance-group] args)) this__1447__auto__ arg0)) // etc, all 20 arities are defined So, that means I could call the record as a function? -- 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.
a record that implements the iFn protocol can itself be called as a function?
The docs offer this example: https://clojuredocs.org/clojure.core/defrecord user= (defrecord Someone [nick-name preffered-drink] Fun-Time (drinky-drinky [_] (str nick-name (having preffered-drink ): uuumm))) user.Someone user= (def dude (-Someone belun daiquiri)) #'user/dude user= (drinky-drinky dude) belun(having daiquiri): uuumm But if a record implements clojure.lang.IFn it can be called directly? Do I understand this correctly? When I run macroexpand-all on defrecord-ifn, as defined here: https://github.com/overtone/overtone/blob/e200075da27375727db1f5ce342e2e1c22ea1dbd/src/overtone/helpers/lib.clj I see that it extends clojure.lang.IFn as in: clojure.lang.IFn (invoke [this__1446__auto__] ((fn [this args] (apply synth-player sdef params this [:tail instance-group] args)) this__1446__auto__)) (invoke [this__1447__auto__ arg0] ((fn [this args] (apply synth-player sdef params this [:tail instance-group] args)) this__1447__auto__ arg0)) // etc, all 20 arities are defined So, that means I could call the record as a function? -- 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.
how does one unquote a list of records that implement IFn without treating the first item as a function?
HI all,
I've gotten myself into a weird situation...
I'm defining a def-like macro and I want to use 'name-with-attributes'.
Consider the following skeleton:
(defmacro defX [name args]
(let [[name attrs] (name-with-attributes name args)]
`(let [cs-coll# ~attrs]
(assert (every? component? cs-coll#) Can only accept IComponents)
(def ~name (Workflow. cs-coll# {:description (- ~name meta :doc)}
nil)))
now consider that I am calling this like so:
(defworkflow my-stem-pipe my own basic stemming pipe my-ssplit
my-tokenizer porter-stemmer)
where the last three symbols refer to records which implement IFn...
doing ~attrs tries to invoke the list as a function-call because the
first symbol happens to be a function but I just want the list of
records (eval'd symbols) so the assertion can proceed...
any ideas?
Jim
--
--
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/groups/opt_out.
Re: how does one unquote a list of records that implement IFn without treating the first item as a function?
~(vec attrs), perhaps?
On Thu, Sep 5, 2013 at 12:20 PM, Jim - FooBar(); jimpil1...@gmail.comwrote:
HI all,
I've gotten myself into a weird situation...
I'm defining a def-like macro and I want to use 'name-with-attributes'.
Consider the following skeleton:
(defmacro defX [name args]
(let [[name attrs] (name-with-attributes name args)]
`(let [cs-coll# ~attrs]
(assert (every? component? cs-coll#) Can only accept IComponents)
(def ~name (Workflow. cs-coll# {:description (- ~name meta :doc)}
nil)))
now consider that I am calling this like so:
(defworkflow my-stem-pipe my own basic stemming pipe my-ssplit
my-tokenizer porter-stemmer)
where the last three symbols refer to records which implement IFn...
doing ~attrs tries to invoke the list as a function-call because the
first symbol happens to be a function but I just want the list of records
(eval'd symbols) so the assertion can proceed...
any ideas?
Jim
--
--
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+unsubscribe@**googlegroups.comclojure%2bunsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/**group/clojure?hl=enhttp://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+unsubscribe@**googlegroups.comclojure%2bunsubscr...@googlegroups.com
.
For more options, visit
https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out
.
--
--
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/groups/opt_out.
Re: how does one unquote a list of records that implement IFn without treating the first item as a function?
I ended up using (list ~@attrs) which is very similar to what you're
suggesting...:)
JIm
On 05/09/13 20:22, Dave Ray wrote:
~(vec attrs), perhaps?
On Thu, Sep 5, 2013 at 12:20 PM, Jim - FooBar(); jimpil1...@gmail.com
mailto:jimpil1...@gmail.com wrote:
HI all,
I've gotten myself into a weird situation...
I'm defining a def-like macro and I want to use
'name-with-attributes'. Consider the following skeleton:
(defmacro defX [name args]
(let [[name attrs] (name-with-attributes name args)]
`(let [cs-coll# ~attrs]
(assert (every? component? cs-coll#) Can only accept IComponents)
(def ~name (Workflow. cs-coll# {:description (- ~name meta
:doc)} nil)))
now consider that I am calling this like so:
(defworkflow my-stem-pipe my own basic stemming pipe my-ssplit
my-tokenizer porter-stemmer)
where the last three symbols refer to records which implement IFn...
doing ~attrs tries to invoke the list as a function-call because
the first symbol happens to be a function but I just want the list
of records (eval'd symbols) so the assertion can proceed...
any ideas?
Jim
--
--
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
mailto: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
mailto:clojure%2bunsubscr...@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
mailto:clojure%2bunsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
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/groups/opt_out.
--
--
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/groups/opt_out.
Re: Easy way to implement IFn in java?
Thanks! Works like a charm.
On Friday, 2 November 2012 19:58:19 UTC-4, AtKaaZ wrote:
looks like you can use AFn() in your example
ie.
static IFn assoc = new AFn(){
@Override
public Object invoke(Object m, Object k, Object v) {
return RT.assoc(m, k, v);
}
};
(code from clojure.lang.Var.assoc)
On Sat, Nov 3, 2012 at 12:51 AM, JvJ kfjwh...@gmail.com javascript:wrote:
I'm writing a Java interface to some Clojure code, and some of the code
needs functions as parameters.
I'd like to be able create objects from anonymous inner classes.
Something like this:
func = new IFn(){
public Object invoke(obj1,...){
//code in here
}
};
I'd like to be able to know if there's a way to do this easily without
overloading like 20 methods or whatever.
I suppose I could implement my own abstract class and extend that, but I
don't want to if I don't have to.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clo...@googlegroups.comjavascript:
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com javascript:
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--
I may be wrong or incomplete.
Please express any corrections / additions,
they are encouraged and appreciated.
At least one entity is bound to be transformed if you do ;)
--
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
Easy way to implement IFn in java?
I'm writing a Java interface to some Clojure code, and some of the code
needs functions as parameters.
I'd like to be able create objects from anonymous inner classes. Something
like this:
func = new IFn(){
public Object invoke(obj1,...){
//code in here
}
};
I'd like to be able to know if there's a way to do this easily without
overloading like 20 methods or whatever.
I suppose I could implement my own abstract class and extend that, but I
don't want to if I don't have to.
--
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: Easy way to implement IFn in java?
looks like you can use AFn() in your example
ie.
static IFn assoc = new AFn(){
@Override
public Object invoke(Object m, Object k, Object v) {
return RT.assoc(m, k, v);
}
};
(code from clojure.lang.Var.assoc)
On Sat, Nov 3, 2012 at 12:51 AM, JvJ kfjwhee...@gmail.com wrote:
I'm writing a Java interface to some Clojure code, and some of the code
needs functions as parameters.
I'd like to be able create objects from anonymous inner classes.
Something like this:
func = new IFn(){
public Object invoke(obj1,...){
//code in here
}
};
I'd like to be able to know if there's a way to do this easily without
overloading like 20 methods or whatever.
I suppose I could implement my own abstract class and extend that, but I
don't want to if I don't have to.
--
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
--
I may be wrong or incomplete.
Please express any corrections / additions,
they are encouraged and appreciated.
At least one entity is bound to be transformed if you do ;)
--
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: Extending IFn
Hi, since IFn is a Java interface and not a protocol, I'm afraid there is no better way to define this. However I would write the macro slightly differently. I find this more approachable. YMMV. (def max-arities 20) (defmacro definvokable [type fields deftype-tail] (let [f(fields 0) args (repeatedly max-arities gensym) arity(fn [n] (let [args (take n args)] `(invoke [this# ~@args] ((. this# ~f) ~@args vararg `(invoke [this# ~@args more#] (apply (. this# ~f) ~@args more#)) apply-to `(applyTo [this# args#] (apply (. this# ~f) args#))] `(deftype ~type ~fields clojure.lang.IFn ~@(map arity (range (inc max-arities))) ~vararg ~apply-to ~@deftype-tail))) Sincerely Meikel -- 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: Extending IFn
Eh, I was afraid the interface would be a problem. So there isn't a good way to reuse interface implementations for interacting w/ legacy Java quite yet. I do like your approach to the macro better. As usual you deliver, Meikel :) Sean On Oct 28, 3:11 am, Meikel Brandmeyer (kotarak) m...@kotka.de wrote: Hi, since IFn is a Java interface and not a protocol, I'm afraid there is no better way to define this. However I would write the macro slightly differently. I find this more approachable. YMMV. (def max-arities 20) (defmacro definvokable [type fields deftype-tail] (let [f (fields 0) args (repeatedly max-arities gensym) arity (fn [n] (let [args (take n args)] `(invoke [this# ~@args] ((. this# ~f) ~@args vararg `(invoke [this# ~@args more#] (apply (. this# ~f) ~@args more#)) apply-to `(applyTo [this# args#] (apply (. this# ~f) args#))] `(deftype ~type ~fields clojure.lang.IFn ~@(map arity (range (inc max-arities))) ~vararg ~apply-to ~@deftype-tail))) Sincerely Meikel -- 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
Extending IFn
I'm experimenting with creating my own fn types. I was wondering if there was a better way of extending IFn than this: https://gist.github.com/1321330 Is there a more idiomatic way? -- 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: Records implementing IFn
Thank you. That seems to do the trick.
-Mark
On Feb 7, 11:55 pm, Alex Osborne a...@meshy.org wrote:
Mark Fredrickson mark.m.fredrick...@gmail.com writes:
Is the following behavior correct or a bug:
user (defrecord Example [data] clojure.lang.IFn (invoke [this] this)
(invoke [this n] (repeat n this)))
user.Example
user (def e (Example. I am e))
#'user/e
user (e 2)
(#:user.Example{:data I am e} #:user.Example{:data I am e})
user (def some-es (e 5))
; Throws java.lang.AbstractMethodError
I can't tell if I am doing something wrong with respect to the IFn
definition, or if I am encountering a bug.
I think you need to implement applyTo for a properly working IFn
implementation:
(defrecord Example [data] clojure.lang.IFn
(invoke [this] this)
(invoke [this n] (repeat n this))
(applyTo [this args] (clojure.lang.AFn/applyToHelper this args)))
--
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
Records implementing IFn
Is the following behavior correct or a bug:
user (defrecord Example [data] clojure.lang.IFn (invoke [this] this)
(invoke [this n] (repeat n this)))
user.Example
user (def e (Example. I am e))
#'user/e
user e
#:user.Example{:data I am e}
user (e 2)
(#:user.Example{:data I am e} #:user.Example{:data I am e})
user (e)
#:user.Example{:data I am e}
user (def some-es (e 5))
; Throws java.lang.AbstractMethodError
I can't tell if I am doing something wrong with respect to the IFn
definition, or if I am encountering a bug.
I have not tried building up a deftype by hand. That may well solve my
problem and would be a perfectly acceptable solution. I started with a
record to hold immutable data and implement the meta-data protocol,
but I could implement these on a type (perhaps dropping another
protocol/interface if it is causing the problem above).
Thanks in advance,
-Mark
--
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: Records implementing IFn
Mark Fredrickson mark.m.fredrick...@gmail.com writes:
Is the following behavior correct or a bug:
user (defrecord Example [data] clojure.lang.IFn (invoke [this] this)
(invoke [this n] (repeat n this)))
user.Example
user (def e (Example. I am e))
#'user/e
user (e 2)
(#:user.Example{:data I am e} #:user.Example{:data I am e})
user (def some-es (e 5))
; Throws java.lang.AbstractMethodError
I can't tell if I am doing something wrong with respect to the IFn
definition, or if I am encountering a bug.
I think you need to implement applyTo for a properly working IFn
implementation:
(defrecord Example [data] clojure.lang.IFn
(invoke [this] this)
(invoke [this n] (repeat n this))
(applyTo [this args] (clojure.lang.AFn/applyToHelper this args)))
--
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: an object of class created using defrecord does not implement IFn .. while it behaves very similar to map otherwise ..
Generating readable code for IDEs is not a good reason. You should think carefully about variable capture and decide which you want. Usually, in a macro-generated defn, I do want to capture the parameters, so I would use ~'this. On Dec 30, 11:54 pm, André Thieme splendidl...@googlemail.com wrote: Am 31.12.2010 03:29, schrieb Alex Baranosky: I've been playing with making a macro to encapsulate Stuart's post, like this: (defmacro defrecord-ifn [name args] `(defrecord ~name ~...@args clojure.lang.IFn (invoke [this key] (get this key (defrecord-ifn Foo [a b c]) (def foo (Foo. A B C)) (prn (map foo [:a :c])) = (A, C) I get the error: No such var: user/this. I guess this is because it is expanding 'this' to 'user/this'. What is the proper way to get a macro like this to expand properly? Others have already pointed to this# . I just would like to add that you can as well use ~'this in some cases, where your macros generate defns. The advantage is that some editors (like emacs) will show you the parameter vector and that would show a useful name and not this_auto_foobarbaz123456 . -- 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: an object of class created using defrecord does not implement IFn .. while it behaves very similar to map otherwise ..
Be sure to also implement the version of get which takes a not-found argument so that your objects will work with map code which uses this functionality. (defrecord map-like-object [field-1 field-2 etc] clojure.lang.IFn (invoke [this k] (get this k)) (invoke [this k not-found] (get this k not-found))) sincerely, --Robert McIntryre On Fri, Dec 31, 2010 at 11:04 AM, Alyssa Kwan alyssa.c.k...@gmail.com wrote: Generating readable code for IDEs is not a good reason. You should think carefully about variable capture and decide which you want. Usually, in a macro-generated defn, I do want to capture the parameters, so I would use ~'this. On Dec 30, 11:54 pm, André Thieme splendidl...@googlemail.com wrote: Am 31.12.2010 03:29, schrieb Alex Baranosky: I've been playing with making a macro to encapsulate Stuart's post, like this: (defmacro defrecord-ifn [name args] `(defrecord ~name ~...@args clojure.lang.IFn (invoke [this key] (get this key (defrecord-ifn Foo [a b c]) (def foo (Foo. A B C)) (prn (map foo [:a :c])) = (A, C) I get the error: No such var: user/this. I guess this is because it is expanding 'this' to 'user/this'. What is the proper way to get a macro like this to expand properly? Others have already pointed to this# . I just would like to add that you can as well use ~'this in some cases, where your macros generate defns. The advantage is that some editors (like emacs) will show you the parameter vector and that would show a useful name and not this_auto_foobarbaz123456 . -- 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
an object of class created using defrecord does not implement IFn .. while it behaves very similar to map otherwise ..
Hello everybody, An object of class created using defrecord does not implement IFn .. while it behaves very similar to map otherwise .. Is this way by design? can it be made to behave like a hash-map without any performance penalty in terms of behaving like a function? Thanks, Sunil. -- 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: an object of class created using defrecord does not implement IFn .. while it behaves very similar to map otherwise ..
Yes, that's intentional – implementing IFn is (as you can see) orthogonal to implementing IPersistentMap, IPersistentCollection, etc. Of course, keyword access of record slots is most idiomatic, e.g. (:my-slot some-record) If you'd like to pass around a function that accesses a record, there's always get, e.g. ((partial get some-record) :my-slot) - Chas On Dec 30, 2010, at 8:08 AM, Sunil S Nandihalli wrote: Hello everybody, An object of class created using defrecord does not implement IFn .. while it behaves very similar to map otherwise .. Is this way by design? can it be made to behave like a hash-map without any performance penalty in terms of behaving like a function? Thanks, Sunil. -- 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: an object of class created using defrecord does not implement IFn .. while it behaves very similar to map otherwise ..
You can make it implement IFn easily enough: (defrecord Foo [a b c] clojure.lang.IFn (invoke [this key] (get this key))) It has been debated whether or not this is a good idea, design-wise, but it should not be a performance penalty. -Stuart Sierra clojure.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
Re: an object of class created using defrecord does not implement IFn .. while it behaves very similar to map otherwise ..
I've been playing with making a macro to encapsulate Stuart's post, like this: (defmacro defrecord-ifn [name args] `(defrecord ~name ~...@args clojure.lang.IFn (invoke [this key] (get this key (defrecord-ifn Foo [a b c]) (def foo (Foo. A B C)) (prn (map foo [:a :c])) = (A, C) I get the error: No such var: user/this. I guess this is because it is expanding 'this' to 'user/this'. What is the proper way to get a macro like this to expand properly? Alex -- 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: an object of class created using defrecord does not implement IFn .. while it behaves very similar to map otherwise ..
Alex Baranosky alexander.barano...@gmail.com writes: I've been playing with making a macro to encapsulate Stuart's post, like this: (defmacro defrecord-ifn [name args] `(defrecord ~name ~...@args clojure.lang.IFn (invoke [this key] (get this key (defrecord-ifn Foo [a b c]) (def foo (Foo. A B C)) (prn (map foo [:a :c])) = (A, C) I get the error: No such var: user/this. I guess this is because it is expanding 'this' to 'user/this'. What is the proper way to get a macro like this to expand properly? Use autogensym. Stick a # on the end of bindings you declare inside syntax-quote: this# and key#. (defmacro defrecord-ifn [name args] `(defrecord ~name ~...@args clojure.lang.IFn (invoke [this# key#] (get this# key# -- 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: an object of class created using defrecord does not implement IFn .. while it behaves very similar to map otherwise ..
Worked like a charm. Thanks Alex. -- 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: an object of class created using defrecord does not implement IFn .. while it behaves very similar to map otherwise ..
Technically, there's no possibility of variable capture, but you should use gensyms: (defmacro defrecord-ifn [name args] `(defrecord ~name ~...@args clojure.lang.IFn (invoke [this# key#] (get this# key# Thanks, Alyssa On Dec 30, 9:29 pm, Alex Baranosky alexander.barano...@gmail.com wrote: I've been playing with making a macro to encapsulate Stuart's post, like this: (defmacro defrecord-ifn [name args] `(defrecord ~name ~...@args clojure.lang.IFn (invoke [this key] (get this key (defrecord-ifn Foo [a b c]) (def foo (Foo. A B C)) (prn (map foo [:a :c])) = (A, C) I get the error: No such var: user/this. I guess this is because it is expanding 'this' to 'user/this'. What is the proper way to get a macro like this to expand properly? Alex -- 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: an object of class created using defrecord does not implement IFn .. while it behaves very similar to map otherwise ..
thanks everybody for the responses .. with macros around ... you just have to wish for it to get it .. but we need to be careful what we wish for :) Sunil. On Fri, Dec 31, 2010 at 8:18 AM, Alyssa Kwan alyssa.c.k...@gmail.comwrote: Argh! Six minutes! :P On Dec 30, 9:42 pm, Alyssa Kwan alyssa.c.k...@gmail.com wrote: Technically, there's no possibility of variable capture, but you should use gensyms: (defmacro defrecord-ifn [name args] `(defrecord ~name ~...@args clojure.lang.IFn (invoke [this# key#] (get this# key# Thanks, Alyssa On Dec 30, 9:29 pm, Alex Baranosky alexander.barano...@gmail.com wrote: I've been playing with making a macro to encapsulate Stuart's post, like this: (defmacro defrecord-ifn [name args] `(defrecord ~name ~...@args clojure.lang.IFn (invoke [this key] (get this key (defrecord-ifn Foo [a b c]) (def foo (Foo. A B C)) (prn (map foo [:a :c])) = (A, C) I get the error: No such var: user/this. I guess this is because it is expanding 'this' to 'user/this'. What is the proper way to get a macro like this to expand properly? Alex -- 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.comclojure%2bunsubscr...@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: an object of class created using defrecord does not implement IFn .. while it behaves very similar to map otherwise ..
Am 31.12.2010 03:29, schrieb Alex Baranosky: I've been playing with making a macro to encapsulate Stuart's post, like this: (defmacro defrecord-ifn [name args] `(defrecord ~name ~...@args clojure.lang.IFn (invoke [this key] (get this key (defrecord-ifn Foo [a b c]) (def foo (Foo. A B C)) (prn (map foo [:a :c])) = (A, C) I get the error: No such var: user/this. I guess this is because it is expanding 'this' to 'user/this'. What is the proper way to get a macro like this to expand properly? Others have already pointed to “this#”. I just would like to add that you can as well use “~'this” in some cases, where your macros generate defns. The advantage is that some editors (like emacs) will show you the parameter vector and that would show a useful name and not “this_auto_foobarbaz123456”. -- 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: I am unclear on how I can call an Ifn stored in a map usefully
Perfect! And Thanks!
Tim
On Jun 22, 7:00 pm, Michał Marczyk michal.marc...@gmail.com wrote:
Firstly, consider using Delays rather than IFn. See (doc delay) and
(doc delay?). In Clojure, many sorts of things are IFns, including
(among others) sets, vectors and maps, and you probably don't want to
call those.
(def uhoh* (ref {:event {:date (delay (java.util.Date.)) :name EOW}}))
(def why* (ref {:event {:stuff ELI}}))
Then you could do something like
(def current*
(zipmap (mapcat keys [(uhoh* :event) (why* :event)])
(mapcat #(- % vals
(map (fn [item] (if (delay? item)
@item item
[(uhoh* :event) (why* :event)])))
If you really want to use IFns and not Delays, change (delay? item) to
(ifn? item) and @item to (item).
For more general tree walking, see clojure.walk. E.g.
(def current*
(walk/prewalk #(if (delay? %) @% %)
(merge (uhoh* :event)
(why* :event
will give you the same thing.
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
I am unclear on how I can call an Ifn stored in a map usefully
Hello Folks,
I'm a noob to both programming (1 year part-time) and to Clojure (1
week).
I am unclear on how I can call an Ifn stored in a map usefully
and I am hoping you can help me.
I have stored data in a few maps (both functions and data):
user= (def uhoh* (ref {:event {:date #(date) :name EOW}}))
#'user/uhoh*
user= (def why* (ref {:event {:stuff ELI}}))
#'user/why*
I call the key having a string:
user= ((uhoh* :event) :name)
EOW
sweet!
I call the key having an Ifn:
user= ((uhoh* :event) :date)
#user$fn__2476 user$fn__2...@273f212a
hm. not what I wanted!
let's try this another way:
user= (((uhoh* :event) :date))
Tue 22 Jun 2010 17:41:23 MDT
nil
sweet!
let's pull my maps together:
user=(def current* (merge (uhoh* :event)(why* :event)))
#'user/current*
here's my problem:
user= current*
{:stuff ELI, :date #user$fn__2507
user$fn__2...@4fa3551c, :name EOW}
I was hoping this kind of a call would yield:
{:stuff ELI, :date Tue 22 Jun 2010 17:45:32 MDT, :name
EOW}
I need the date representing the time I assign the def (evaluated at
call time) and I don't know which keys will have an Ifn or just a
string etc.
Is there existing falicilites to make this happen? An existing
function call perhaps not obvious to me? Or do I need to write custom
loops to cycle through and handle each item?
Thanks,
Tim
--
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: I am unclear on how I can call an Ifn stored in a map usefully
user=(def current* (merge (uhoh* :event)(why* :event)))
#'user/current*
here's my problem:
user= current*
{:stuff ELI, :date #user$fn__2507
user$fn__2...@4fa3551c, :name EOW}
I was hoping this kind of a call would yield:
{:stuff ELI, :date Tue 22 Jun 2010 17:45:32 MDT, :name
EOW}
I need the date representing the time I assign the def (evaluated at
call time) and I don't know which keys will have an Ifn or just a
string etc.
Is there existing falicilites to make this happen? An existing
function call perhaps not obvious to me? Or do I need to write custom
loops to cycle through and handle each item?
Thanks,
Tim
That would be completely un-idiomatic. The point of immutable structures is
that they don't mutate. You are thinking in javaesque object orientation
where you mix state and identity.
You might be interested in Rich's take on that question:
http://clojure.org/state
--
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: I am unclear on how I can call an Ifn stored in a map usefully
Firstly, consider using Delays rather than IFn. See (doc delay) and
(doc delay?). In Clojure, many sorts of things are IFns, including
(among others) sets, vectors and maps, and you probably don't want to
call those.
(def uhoh* (ref {:event {:date (delay (java.util.Date.)) :name EOW}}))
(def why* (ref {:event {:stuff ELI}}))
Then you could do something like
(def current*
(zipmap (mapcat keys [(uhoh* :event) (why* :event)])
(mapcat #(- % vals
(map (fn [item] (if (delay? item)
@item item
[(uhoh* :event) (why* :event)])))
If you really want to use IFns and not Delays, change (delay? item) to
(ifn? item) and @item to (item).
For more general tree walking, see clojure.walk. E.g.
(def current*
(walk/prewalk #(if (delay? %) @% %)
(merge (uhoh* :event)
(why* :event
will give you the same thing.
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: refs implement IFn, atoms and agents do not?
On Oct 3, 2009, at 1:50 PM, Stuart Halloway wrote: Is there a principled reason for this? I have written some code that (unintentionally) limits itself to refs because it assumes that all reference types can sit in function position. This discussion: http://groups.google.com/group/clojure/browse_thread/thread/534dd074f18851ab suggests that reference types implementing IFn isn't the intended behavior. Using deref or @ works with all reference types: user (defn my-fn [x] (+ x 3)) #'user/my-fn user (def my-agent (agent my-fn)) #'user/my-agent user (@my-agent 4) 7 --Steve smime.p7s Description: S/MIME cryptographic signature
Re: refs implement IFn, atoms and agents do not?
On Oct 4, 2009, at 5:04 PM, Mark Volkmann wrote: Minor technicality ... Vars are a reference type, but deref and @ don't work with them. I'm guessing you're thinking of an interaction like this: user= (def a 3) #'user/a user= @a java.lang.ClassCastException: java.lang.Integer cannot be cast to clojure.lang.IDeref (NO_SOURCE_FILE:0) user= However, it's important to remember that the expression a does not evaluate to the Var named a. The Var named by a can be accessed via (var a) or #'a. deref does work with Vars: user= @(var a) 3 user= @#'a 3 user= deref works with objects that implement clojure.lang.IDeref and clojure.lang.Var is among them: user= (isa? clojure.lang.Var clojure.lang.IDeref) true user= --Steve smime.p7s Description: S/MIME cryptographic signature
Re: refs implement IFn, atoms and agents do not?
On Sun, Oct 4, 2009 at 4:26 PM, Stephen C. Gilardi squee...@mac.com wrote: On Oct 4, 2009, at 5:04 PM, Mark Volkmann wrote: Minor technicality ... Vars are a reference type, but deref and @ don't work with them. I'm guessing you're thinking of an interaction like this: user= (def a 3) #'user/a user= @a java.lang.ClassCastException: java.lang.Integer cannot be cast to clojure.lang.IDeref (NO_SOURCE_FILE:0) Yes, that's what I was thinking about. However, it's important to remember that the expression a does not evaluate to the Var named a. The Var named by a can be accessed via (var a) or #'a. deref does work with Vars: user= @(var a) 3 user= @#'a 3 user= deref works with objects that implement clojure.lang.IDeref and clojure.lang.Var is among them: user= (isa? clojure.lang.Var clojure.lang.IDeref) true user= Thanks for clarifying that! -- R. Mark Volkmann Object Computing, Inc. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
refs implement IFn, atoms and agents do not?
Is there a principled reason for this? I have written some code that (unintentionally) limits itself to refs because it assumes that all reference types can sit in function position. Thanks, Stu --~--~-~--~~~---~--~~ 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: Why doesn't regex implement ifn?
I have the same urge, to want to use regexps as predicates. However I definitely would not like to read such code. I can only imagine having to try to read such code if I didn't understand regexps. E.g. (filter #\d+ maybe-numbers) is clear enough to someone who understands regexps. However (filter is-number-regex maybe-numbers) is clear to even programmers that don't understand regexps. On Aug 27, 10:41 am, Sean Devlin francoisdev...@gmail.com wrote: On Aug 27, 1:06 am, Timothy Pratley timothyprat...@gmail.com wrote: Granted, this wouldn't work for anything that gets passed to Java, but the following gist would be a start. http://gist.github.com/176032 You already have a getPattern method for those cases. Which suggests another solution: (defn re-fn Uses ss to construct a java.util.Pattern. Returns a function which returns the Pattern if called with no arguments, and calls re-seq if called with a string argument. [ss] (let [pp (re-pattern ss)] (fn re ([] pp) ([s] (re-seq pp s) user= ((re-fn 2.) 12324251) (23 24 25) user= ((re-fn 2.)) #2. If #X created a (re-fn X) then all the re functions could accept a function and call it in order to avoid having to do (re-find (pp) s). The previous signature could be retained so that they would work with either type of arguments if that were desirable. The downside is trying to explain that in the docs might be confusing - so a wrapper seems more obvious for that. Oh - it seems like re-seq does the most work so perhaps that is the best candidate? The only feature I want is the ability to use a regex as a predicate. So, I'd prefer something like re-matches. Maybe this isn't the biggest use case, though. Sean Regards, Tim. --~--~-~--~~~---~--~~ 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: Why doesn't regex implement ifn?
On Thu, Aug 27, 2009 at 9:05 PM, Chas Emerick cemer...@snowtide.com wrote: On Aug 27, 2009, at 1:34 PM, Chouser wrote: The benefits of # producing a real java.util.regex.Pattern object instead of some Clojury wrapper will decrease as it becomes more common to write Clojure code that can run on non-JVM platforms. So although this idea has come up and then been abandoned several times before, I think it's worth bringing up again periodically to see what makes sense. Why wouldn't # produce whatever the corollary regex object is on each host platform? I had a couple suggestions on clojure-dev for ClojureCLR that line up with the produce the corollary idea: http://groups.google.com/group/clojure-dev/browse_thread/thread/d4286dac9f1cf8ba/7e05daa7b782c075 . http://groups.google.com/group/clojure-dev/browse_thread/thread/d4286dac9f1cf8ba/7e05daa7b782c075 Tangentially, if I think ahead a couple of 'moves', I'd think that perhaps there's a desire to have clojure code that is thoroughly portable between, say, Java and .NET host platforms. Essentially, as Chouser noted, # and re-seq as currently defined in Clojure get you pretty far as a portable API. However, unless the platforms agree on literal regex syntax (they don't, beyond the basic asdf|[0-9]+ features) will prevent true portability of the literals. Shawn --~--~-~--~~~---~--~~ 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: Why doesn't regex implement ifn?
On Thu, Aug 27, 2009 at 9:05 PM, Chas Emerickcemer...@snowtide.com wrote: On Aug 27, 2009, at 1:34 PM, Chouser wrote: The benefits of # producing a real java.util.regex.Pattern object instead of some Clojury wrapper will decrease as it becomes more common to write Clojure code that can run on non-JVM platforms. So although this idea has come up and then been abandoned several times before, I think it's worth bringing up again periodically to see what makes sense. Why wouldn't # produce whatever the corollary regex object is on each host platform? What methods could you call on such a thing? The answer would differ depending on your platform, making the direct calling of methods on such a thing undesirable as more platforms are supported. Tangentially, if I think ahead a couple of 'moves', I'd think that perhaps there's a desire to have clojure code that is thoroughly portable between, say, Java and .NET host platforms. Yes, exactly, at least for some subset of Clojure functionality. On the one hand, it's probably not worth making Java binary serialization work transparently on a JavaScript host, for example. On the other hand, it'd be nice (and not terribly difficult) to make (re-seq #x. x1y2x3) return (x1 x3) on nearly every platform being considered. So it'd be nice if re-seq and Clojure's other re-* functions always worked on whatever # produced, but it's less important for # to have any particular set of native methods. Of course you'd still want to provide a way to get to the underlying platform-specific pattern object for cases where you want to take advantage a platform feature in code that doesn't have to be portable. --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 -~--~~~~--~~--~--~---
Re: Why doesn't regex implement ifn?
On Aug 28, 2009, at 10:01 AM, Shawn Hoover wrote: Why wouldn't # produce whatever the corollary regex object is on each host platform? I had a couple suggestions on clojure-dev for ClojureCLR that line up with the produce the corollary idea: http://groups.google.com/group/clojure-dev/browse_thread/thread/d4286dac9f1cf8ba/7e05daa7b782c075 . Yeah, I wanted to find that thread yesterday, but (surprise!) couldn't. Tangentially, if I think ahead a couple of 'moves', I'd think that perhaps there's a desire to have clojure code that is thoroughly portable between, say, Java and .NET host platforms. Essentially, as Chouser noted, # and re-seq as currently defined in Clojure get you pretty far as a portable API. However, unless the platforms agree on literal regex syntax (they don't, beyond the basic asdf|[0-9]+ features) will prevent true portability of the literals. Indeed. FWIW, I was *definitely not* suggesting that soup-to-nuts portability across host platforms is a good idea -- I just see things that make me think that others would lean in that direction. On Aug 28, 2009, at 9:00 AM, Rich Hickey wrote: I don't think moving specific applications between JVM/CLR/JS is a target, nor should it be. People need to move their expertise in the language, and core libraries, to different applications, which might have different target platforms. So, UI/web/DB libs IMO should not be portable. Life is too short. I agree completely. You can (and many have) spend a lifetime shimming APIs (or reimplementing them, for that matter). People will do what they want of course, but there's a huge opportunity cost attached. Regex is interesting - is there a lot of core library code that uses it? Are there portable alternatives? It is quite likely that the native regex support on any platform will be best for that platform, so I'm inclined to think that # should follow when in Rome principles, and the burden should be on those who want portable regex to use something portable and eschew #, but as I've said before, I'm not much of a regex user. AFAIC, regex engines are platform facilities, like threading is. There's always going to be off-by-one differences (like those related to .NET's regex impl, nevermind the vastly different javascript impl), and any reimplementation will not be as heavily used, tested, or be as fast or feature-complete as the host platform's facility. The same goes for concurrency approaches, graphics contexts, networking, etc. etc. - Chas --~--~-~--~~~---~--~~ 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: Why doesn't regex implement ifn?
On Fri, Aug 28, 2009 at 10:01 AM, Shawn Hoovershawn.hoo...@gmail.com wrote: However, unless the platforms agree on literal regex syntax (they don't, beyond the basic asdf|[0-9]+ features) will prevent true portability of the literals. This is an interesting and crucial assertion. If the regex syntaxes do not have a useful overlap, only libraries that allow regexs to pass through from the app to the platform (creating no new regex objects of their own) will be portable, at which point wrapping the pattern in a clojure-something becomes rather less useful (except I suppose for the original IFn point). But is it true? The amount of overlap between, for example, JVM and JavaScript is quite substantial, both having borrowed features and syntax quite heavily from perl. http://www.regular-expressions.info/refflavors.html I think that a s long as we're not trying to support ancient engines (such as sed, awk, emacs...) the subset that overlaps would be quite useful. --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 -~--~~~~--~~--~--~---
Re: Why doesn't regex implement ifn?
On Aug 28, 2009, at 12:13 PM, Chouser wrote: On Fri, Aug 28, 2009 at 10:01 AM, Shawn Hoovershawn.hoo...@gmail.com wrote: However, unless the platforms agree on literal regex syntax (they don't, beyond the basic asdf|[0-9]+ features) will prevent true portability of the literals. This is an interesting and crucial assertion. If the regex syntaxes do not have a useful overlap, only libraries that allow regexs to pass through from the app to the platform (creating no new regex objects of their own) will be portable, at which point wrapping the pattern in a clojure-something becomes rather less useful (except I suppose for the original IFn point). But is it true? The amount of overlap between, for example, JVM and JavaScript is quite substantial, both having borrowed features and syntax quite heavily from perl. http://www.regular-expressions.info/refflavors.html I think that a s long as we're not trying to support ancient engines (such as sed, awk, emacs...) the subset that overlaps would be quite useful. Any kind of substantial difference in the implementation (and not just in the supported feature set) will lead to lots of confusion when those differences become apparent. The key thing is that what's substantial to one is unimportant to another. e.g.: A quick scan of that page shows two really big differences between .NET and Java -- only the latter has possessive quantifiers (which I've come to love for certain tight jams), and only the former has named groups (a feature I dearly miss from my python days when in the Java world). I don't think we do anyone any favors trying to come up with a supported regex variant that is only the intersection of the host platforms that are of interest (which, of course, will change). I guess I'm just missing the boat on the motivation here. Will the same principle apply for networking and graphics and concurrency, too? I can't imagine so... - Chas --~--~-~--~~~---~--~~ 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: Why doesn't regex implement ifn?
On Aug 27, 1:06 am, Timothy Pratley timothyprat...@gmail.com wrote: Granted, this wouldn't work for anything that gets passed to Java, but the following gist would be a start. http://gist.github.com/176032 You already have a getPattern method for those cases. Which suggests another solution: (defn re-fn Uses ss to construct a java.util.Pattern. Returns a function which returns the Pattern if called with no arguments, and calls re-seq if called with a string argument. [ss] (let [pp (re-pattern ss)] (fn re ([] pp) ([s] (re-seq pp s) user= ((re-fn 2.) 12324251) (23 24 25) user= ((re-fn 2.)) #2. If #X created a (re-fn X) then all the re functions could accept a function and call it in order to avoid having to do (re-find (pp) s). The previous signature could be retained so that they would work with either type of arguments if that were desirable. The downside is trying to explain that in the docs might be confusing - so a wrapper seems more obvious for that. Oh - it seems like re-seq does the most work so perhaps that is the best candidate? The only feature I want is the ability to use a regex as a predicate. So, I'd prefer something like re-matches. Maybe this isn't the biggest use case, though. Sean Regards, Tim. --~--~-~--~~~---~--~~ 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: Why doesn't regex implement ifn?
I named is-number-regex poorly. I meant it to be a function that calls re-matches. Here's a more complete snippet, with better names: ; bad code (filter #^\d+$ maybe-numbers) ; good code (defn re-match? [re s] (not (nil? (re-matches re s (defn number-text? [s] (re-match? #^\d+$ s)) (filter number-text? maybe-numbers) My point is that, since magic numbers are bad, you should be giving the regex a meaningful name, so implementing IFn for regexps isn't a big savings because it pretty much just transforms: (defn number-text? [s] (re-match? #^\d+$ s)) into this: (defn number-text? [s] (#^\d+$ s)) On Aug 27, 12:50 pm, Sean Devlin francoisdev...@gmail.com wrote: Hmmm... I think you're confusing the issue. Your compliant seems to be more directed at magic numbers than regexes. If I understand your argument (which I agree with): ;bad code (filter #\d+ maybe-numbers) ;good code (let [is-number-regex #\d+] (filter is-number-regex maybe-numbers)) Granted, some understanding of regexes is required. However, if you're hacking Lisp, I think you've moved beyond beginner status, and expecting a basic familiarity of a regex is fair. My $.02 Sean On Aug 27, 1:37 pm, eyeris drewpvo...@gmail.com wrote: I have the same urge, to want to use regexps as predicates. However I definitely would not like to read such code. I can only imagine having to try to read such code if I didn't understand regexps. E.g. (filter #\d+ maybe-numbers) is clear enough to someone who understands regexps. However (filter is-number-regex maybe-numbers) is clear to even programmers that don't understand regexps. On Aug 27, 10:41 am, Sean Devlin francoisdev...@gmail.com wrote: On Aug 27, 1:06 am, Timothy Pratley timothyprat...@gmail.com wrote: Granted, this wouldn't work for anything that gets passed to Java, but the following gist would be a start. http://gist.github.com/176032 You already have a getPattern method for those cases. Which suggests another solution: (defn re-fn Uses ss to construct a java.util.Pattern. Returns a function which returns the Pattern if called with no arguments, and calls re-seq if called with a string argument. [ss] (let [pp (re-pattern ss)] (fn re ([] pp) ([s] (re-seq pp s) user= ((re-fn 2.) 12324251) (23 24 25) user= ((re-fn 2.)) #2. If #X created a (re-fn X) then all the re functions could accept a function and call it in order to avoid having to do (re-find (pp) s). The previous signature could be retained so that they would work with either type of arguments if that were desirable. The downside is trying to explain that in the docs might be confusing - so a wrapper seems more obvious for that. Oh - it seems like re-seq does the most work so perhaps that is the best candidate? The only feature I want is the ability to use a regex as a predicate. So, I'd prefer something like re-matches. Maybe this isn't the biggest use case, though. Sean Regards, Tim. --~--~-~--~~~---~--~~ 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: Why doesn't regex implement ifn?
Or this: (def number-text? #^\d$) Which is a savings :) On Aug 27, 5:21 pm, eyeris drewpvo...@gmail.com wrote: I named is-number-regex poorly. I meant it to be a function that calls re-matches. Here's a more complete snippet, with better names: ; bad code (filter #^\d+$ maybe-numbers) ; good code (defn re-match? [re s] (not (nil? (re-matches re s (defn number-text? [s] (re-match? #^\d+$ s)) (filter number-text? maybe-numbers) My point is that, since magic numbers are bad, you should be giving the regex a meaningful name, so implementing IFn for regexps isn't a big savings because it pretty much just transforms: (defn number-text? [s] (re-match? #^\d+$ s)) into this: (defn number-text? [s] (#^\d+$ s)) On Aug 27, 12:50 pm, Sean Devlin francoisdev...@gmail.com wrote: Hmmm... I think you're confusing the issue. Your compliant seems to be more directed at magic numbers than regexes. If I understand your argument (which I agree with): ;bad code (filter #\d+ maybe-numbers) ;good code (let [is-number-regex #\d+] (filter is-number-regex maybe-numbers)) Granted, some understanding of regexes is required. However, if you're hacking Lisp, I think you've moved beyond beginner status, and expecting a basic familiarity of a regex is fair. My $.02 Sean On Aug 27, 1:37 pm, eyeris drewpvo...@gmail.com wrote: I have the same urge, to want to use regexps as predicates. However I definitely would not like to read such code. I can only imagine having to try to read such code if I didn't understand regexps. E.g. (filter #\d+ maybe-numbers) is clear enough to someone who understands regexps. However (filter is-number-regex maybe-numbers) is clear to even programmers that don't understand regexps. On Aug 27, 10:41 am, Sean Devlin francoisdev...@gmail.com wrote: On Aug 27, 1:06 am, Timothy Pratley timothyprat...@gmail.com wrote: Granted, this wouldn't work for anything that gets passed to Java, but the following gist would be a start. http://gist.github.com/176032 You already have a getPattern method for those cases. Which suggests another solution: (defn re-fn Uses ss to construct a java.util.Pattern. Returns a function which returns the Pattern if called with no arguments, and calls re-seq if called with a string argument. [ss] (let [pp (re-pattern ss)] (fn re ([] pp) ([s] (re-seq pp s) user= ((re-fn 2.) 12324251) (23 24 25) user= ((re-fn 2.)) #2. If #X created a (re-fn X) then all the re functions could accept a function and call it in order to avoid having to do (re-find (pp) s). The previous signature could be retained so that they would work with either type of arguments if that were desirable. The downside is trying to explain that in the docs might be confusing - so a wrapper seems more obvious for that. Oh - it seems like re-seq does the most work so perhaps that is the best candidate? The only feature I want is the ability to use a regex as a predicate. So, I'd prefer something like re-matches. Maybe this isn't the biggest use case, though. Sean Regards, Tim. --~--~-~--~~~---~--~~ 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: Why doesn't regex implement ifn?
On Thu, Aug 27, 2009 at 11:41 AM, Sean Devlinfrancoisdev...@gmail.com wrote: On Aug 27, 1:06 am, Timothy Pratley timothyprat...@gmail.com wrote: If #X created a (re-fn X) then all the re functions could accept a function and call it in order to avoid having to do (re-find (pp) s). The previous signature could be retained so that they would work with either type of arguments if that were desirable. The downside is trying to explain that in the docs might be confusing - so a wrapper seems more obvious for that. The benefits of # producing a real java.util.regex.Pattern object instead of some Clojury wrapper will decrease as it becomes more common to write Clojure code that can run on non-JVM platforms. So although this idea has come up and then been abandoned several times before, I think it's worth bringing up again periodically to see what makes sense. Oh - it seems like re-seq does the most work so perhaps that is the best candidate? The only feature I want is the ability to use a regex as a predicate. So, I'd prefer something like re-matches. Maybe this isn't the biggest use case, though. Pretty much anything that can be concluded by using re-matches can also be found using re-seq, so I think I'd prefer the latter. One proviso being that currently re-seq returns an empty list, not nil, when there are no matches. This does reduce its utility as a predicate. Would automatically forcing the first step to get a nice 'nil' be unacceptable? --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 -~--~~~~--~~--~--~---
Re: Why doesn't regex implement ifn?
Hmmm... I think you're confusing the issue. Your compliant seems to be more directed at magic numbers than regexes. If I understand your argument (which I agree with): ;bad code (filter #\d+ maybe-numbers) ;good code (let [is-number-regex #\d+] (filter is-number-regex maybe-numbers)) Granted, some understanding of regexes is required. However, if you're hacking Lisp, I think you've moved beyond beginner status, and expecting a basic familiarity of a regex is fair. My $.02 Sean On Aug 27, 1:37 pm, eyeris drewpvo...@gmail.com wrote: I have the same urge, to want to use regexps as predicates. However I definitely would not like to read such code. I can only imagine having to try to read such code if I didn't understand regexps. E.g. (filter #\d+ maybe-numbers) is clear enough to someone who understands regexps. However (filter is-number-regex maybe-numbers) is clear to even programmers that don't understand regexps. On Aug 27, 10:41 am, Sean Devlin francoisdev...@gmail.com wrote: On Aug 27, 1:06 am, Timothy Pratley timothyprat...@gmail.com wrote: Granted, this wouldn't work for anything that gets passed to Java, but the following gist would be a start. http://gist.github.com/176032 You already have a getPattern method for those cases. Which suggests another solution: (defn re-fn Uses ss to construct a java.util.Pattern. Returns a function which returns the Pattern if called with no arguments, and calls re-seq if called with a string argument. [ss] (let [pp (re-pattern ss)] (fn re ([] pp) ([s] (re-seq pp s) user= ((re-fn 2.) 12324251) (23 24 25) user= ((re-fn 2.)) #2. If #X created a (re-fn X) then all the re functions could accept a function and call it in order to avoid having to do (re-find (pp) s). The previous signature could be retained so that they would work with either type of arguments if that were desirable. The downside is trying to explain that in the docs might be confusing - so a wrapper seems more obvious for that. Oh - it seems like re-seq does the most work so perhaps that is the best candidate? The only feature I want is the ability to use a regex as a predicate. So, I'd prefer something like re-matches. Maybe this isn't the biggest use case, though. Sean Regards, Tim. --~--~-~--~~~---~--~~ 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: Why doesn't regex implement ifn?
Awesome. +1 On Aug 27, 9:57 pm, Timothy Pratley timothyprat...@gmail.com wrote: The only feature I want is the ability to use a regex as a predicate. Would automatically forcing the first step to get a nice 'nil' be unacceptable? Sounds good to me! This can be quite easily accommodated: (defn re-fn Construct a regular expression from string. Calling a regular expression with no arguments returns a Pattern. Calling a regular expression with a string argument returns nil if no matches, otherwise the equivalent of (re-seq re string). [string] (let [pp (re-pattern string)] (fn re ([] pp) ([s] (let [groups (re-seq pp s)] (if (first groups) groups nil)) user= ((re-fn 7.) 12324251) nil user= ((re-fn 2.) 12324251) (23 24 25) user= (if ((re-fn 1) 12) :great :bad) :great (And of course a wrapper implementation version could do something similar). Regards, Tim. --~--~-~--~~~---~--~~ 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: Why doesn't regex implement ifn?
The only feature I want is the ability to use a regex as a predicate. Would automatically forcing the first step to get a nice 'nil' be unacceptable? Sounds good to me! This can be quite easily accommodated: (defn re-fn Construct a regular expression from string. Calling a regular expression with no arguments returns a Pattern. Calling a regular expression with a string argument returns nil if no matches, otherwise the equivalent of (re-seq re string). [string] (let [pp (re-pattern string)] (fn re ([] pp) ([s] (let [groups (re-seq pp s)] (if (first groups) groups nil)) user= ((re-fn 7.) 12324251) nil user= ((re-fn 2.) 12324251) (23 24 25) user= (if ((re-fn 1) 12) :great :bad) :great (And of course a wrapper implementation version could do something similar). Regards, Tim. --~--~-~--~~~---~--~~ 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: Why doesn't regex implement ifn?
On Aug 27, 2009, at 1:34 PM, Chouser wrote: The benefits of # producing a real java.util.regex.Pattern object instead of some Clojury wrapper will decrease as it becomes more common to write Clojure code that can run on non-JVM platforms. So although this idea has come up and then been abandoned several times before, I think it's worth bringing up again periodically to see what makes sense. Why wouldn't # produce whatever the corollary regex object is on each host platform? Tangentially, if I think ahead a couple of 'moves', I'd think that perhaps there's a desire to have clojure code that is thoroughly portable between, say, Java and .NET host platforms. - Chas --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Why doesn't regex implement ifn?
Okay, I'm sure this has come up before. I was just wondering if
anyone knew why the regex literal doesn't implement IFn?
At first glance it seems like the following would be useful:
user=(#\d{3} 123)
true
This is defined as...
user=(not (nil? (re-matches #\d{3} 123)))
true
What am I missing?
Sean
--~--~-~--~~~---~--~~
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: Why doesn't regex implement ifn?
On Aug 26, 2009, at 9:17 PM, Sean Devlin wrote:
Okay, I'm sure this has come up before. I was just wondering if
anyone knew why the regex literal doesn't implement IFn?
At first glance it seems like the following would be useful:
user=(#\d{3} 123)
true
This is defined as...
user=(not (nil? (re-matches #\d{3} 123)))
true
What am I missing?
The # form produces Java Pattern objects:
user= (class #foo)
java.util.regex.Pattern
user=
...which of course aren't IFns.
- Chas
--~--~-~--~~~---~--~~
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: Why doesn't regex implement ifn?
java.util.regex.Pattern I imagine a wrapper class could be returned instead that implemented IFn and Pattern, but which function would it call? (re-find m) (re-find re s) (re-groups m) (re-matcher re s) (re-matches re s) (re-pattern s) (re-seq re s) I don't think there is a clear implicit choice - so explicitly choosing seems necessary here. --~--~-~--~~~---~--~~ 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: Why doesn't regex implement ifn?
On Aug 26, 2009, at 9:46 PM, Timothy Pratley wrote: java.util.regex.Pattern I imagine a wrapper class could be returned instead that implemented IFn and Pattern, Pattern is a final concrete class, so that's not possible. ...I'm counting down until I see an all-clojure regex implementation announcement. ;-) - Chas --~--~-~--~~~---~--~~ 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: Why doesn't regex implement ifn?
On Aug 26, 9:46 pm, Timothy Pratley timothyprat...@gmail.com wrote: java.util.regex.Pattern I imagine a wrapper class could be returned instead that implemented IFn and Pattern, Unfortunately, Pattern is a final class. Rich --~--~-~--~~~---~--~~ 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: Why doesn't regex implement ifn?
Well, with a statically typed language this would be a problem. What if we used duck-typing to get around this? Granted, this wouldn't work for anything that gets passed to Java, but the following gist would be a start. http://gist.github.com/176032 Now, We'd still have to address Mr. Pratley's issue of which fn to implement, but now we have an option. Thoughts? Sean On Aug 26, 10:01 pm, Rich Hickey richhic...@gmail.com wrote: On Aug 26, 9:46 pm, Timothy Pratley timothyprat...@gmail.com wrote: java.util.regex.Pattern I imagine a wrapper class could be returned instead that implemented IFn and Pattern, Unfortunately, Pattern is a final class. Rich --~--~-~--~~~---~--~~ 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: Why doesn't regex implement ifn?
Granted, this wouldn't work for anything that gets passed to Java, but the following gist would be a start. http://gist.github.com/176032 You already have a getPattern method for those cases. Which suggests another solution: (defn re-fn Uses ss to construct a java.util.Pattern. Returns a function which returns the Pattern if called with no arguments, and calls re-seq if called with a string argument. [ss] (let [pp (re-pattern ss)] (fn re ([] pp) ([s] (re-seq pp s) user= ((re-fn 2.) 12324251) (23 24 25) user= ((re-fn 2.)) #2. If #X created a (re-fn X) then all the re functions could accept a function and call it in order to avoid having to do (re-find (pp) s). The previous signature could be retained so that they would work with either type of arguments if that were desirable. The downside is trying to explain that in the docs might be confusing - so a wrapper seems more obvious for that. Oh - it seems like re-seq does the most work so perhaps that is the best candidate? Regards, Tim. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Why do Refs implement IFn and Atoms don't?
Just curious about the reasoning behind this decision? ((ref +) 3 4) ; - 7 ((atom +) 3 4) ; Exception --~--~-~--~~~---~--~~ 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 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: Why do Refs implement IFn and Atoms don't?
David Nolen a écrit : Just curious about the reasoning behind this decision? ((ref +) 3 4) ; - 7 ((atom +) 3 4) ; Exception Last time I asked, Rich said to not rely on refs implementing IFn. (It may be a remain from the time where vars and refs were the same thing -- just guessing) -- Professional: http://cgrand.net/ (fr) On Clojure: http://clj-me.blogspot.com/ (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 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: IFn?
Generally, if you see this in a runtime exception, you tried to call something that does not implement the IFn interface. On Apr 18, 11:37 pm, tmountain tinymount...@gmail.com wrote: Sorry for the newbie question, but can someone tell me what IFn means exactly? I keep running into it in the docs particularly in the keyword documentation, and Google has yet to expain. Thanks, Travis --~--~-~--~~~---~--~~ 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 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: IFn?
Thanks, makes sense. Travis On Apr 19, 12:47 am, Kevin Downey redc...@gmail.com wrote: ifn? returns true for things that implement clojure.lang.IFn, IFn is the interface for things that can be put in the operator position in a s-expr: functions vectors maps sets keywords symbols ...? fn? returns true for just functions On Sat, Apr 18, 2009 at 9:37 PM, tmountain tinymount...@gmail.com wrote: Sorry for the newbie question, but can someone tell me what IFn means exactly? I keep running into it in the docs particularly in the keyword documentation, and Google has yet to expain. Thanks, Travis -- And what is good, Phaedrus, And what is not good— Need we ask anyone to tell us these things? --~--~-~--~~~---~--~~ 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 this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
IFn?
Sorry for the newbie question, but can someone tell me what IFn means exactly? I keep running into it in the docs particularly in the keyword documentation, and Google has yet to expain. Thanks, Travis --~--~-~--~~~---~--~~ 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 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: IFn?
ifn? returns true for things that implement clojure.lang.IFn, IFn is the interface for things that can be put in the operator position in a s-expr: functions vectors maps sets keywords symbols ...? fn? returns true for just functions On Sat, Apr 18, 2009 at 9:37 PM, tmountain tinymount...@gmail.com wrote: Sorry for the newbie question, but can someone tell me what IFn means exactly? I keep running into it in the docs particularly in the keyword documentation, and Google has yet to expain. Thanks, Travis -- And what is good, Phaedrus, And what is not good— Need we ask anyone to tell us these things? --~--~-~--~~~---~--~~ 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 this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~--~~~~--~~--~--~---
