I haven't tried this, so apologies if it couldn't even work, but have you
considered providing a fn in your library intended to be used inside the ns
macro? The refer-clojure :exclude boilerplate could be replaced with
something like this.
(ns my-thing
(:require core.matrix.ns)
On Friday, 6 September 2013 03:15:40 UTC+8, Sean Corfield wrote:
On Wed, Sep 4, 2013 at 11:25 PM, Mikera mike.r.an...@gmail.comjavascript:
wrote:
I remember the debates :-) and I don't think there was anything like a
consensus that don't do that is the right answer.
I didn't say there
On Friday, 6 September 2013 02:30:22 UTC+8, Armando Blancas wrote:
I just think the default behaviour should be super-friendly and not spit
out warnings.
If other libs also redefine any of those operators or names, now or in
later versions, I'd be glad to know. With last-one-in-wins
On Thu, Sep 5, 2013 at 2:35 PM, Dave Ray dave...@gmail.com wrote:
could you have a macro that rewrites code to use your ops?
(require '[clojure.core.matrix :as m])
(m/with-ops (+ ... (* ...) ...))
I wonder if there is value in a more general (with-ns clojure.core.matrix
(foo (bar ...)))
On Thursday, 5 September 2013 13:26:28 UTC+8, Sean Corfield wrote:
You only get the warning if you 'use' the namespace or 'refer all'
tho', correct?
And we've recently seen a lot of discussion that basically says don't
do that so it seems that either users of core.matric are going to
This is actually probably not a bad solution. You wouldn't even need to
rewrite, couldn't you just expand to a let?
(let [* clojure.core.matrix.*
+ clojure.core.matrix.+]
(+ ... (* ...)))
Although thinking about it, you'd have to let-bind all possible operators
every time, and the
I just think the default behaviour should be super-friendly and not spit
out warnings.
If other libs also redefine any of those operators or names, now or in
later versions, I'd be glad to know. With last-one-in-wins some will lose.
Maybe this will help:
mvn clojure:repl 2 /dev/null
--
On Wed, Sep 4, 2013 at 11:25 PM, Mikera mike.r.anderson...@gmail.com wrote:
I remember the debates :-) and I don't think there was anything like a
consensus that don't do that is the right answer.
I didn't say there was consensus or that it was right :)
I'm not against giving the user
Not doing actual replacement via code-walking will prevent any functions
with inline definitions actually being able to benefit from this. I'm not
sure if those are used in core.matrix, though.
On Thu, Sep 5, 2013 at 4:54 AM, Colin Fleming
colin.mailingl...@gmail.comwrote:
This is actually
It is probably instructive to look at how (use-primitive-operators) works
in primitive-math [1], though maybe not something you want to emulate. The
basic mechanism is pretty simple: use 'ns-unmap' to get rid of the
operators you want to shadow, and bring in the operators from the alternate
Hmmm clever trick. I hadn't thought about hijacking ns :-)
Still, it's a colossal hack. Monkey patching always makes me feel uneasy.
Perhaps Clojure itself needs patching to make this use case a bit more
palatable? Some obvious options:
- Turn off all warnings for symbol replacement by default.
You only get the warning if you 'use' the namespace or 'refer all'
tho', correct?
And we've recently seen a lot of discussion that basically says don't
do that so it seems that either users of core.matric are going to
have two approved choices:
* require core.matrix with an alias, or choose to
Maybe this is a dumb idea, but could you have a macro that rewrites code to
use your ops?
(require '[clojure.core.matrix :as m])
(m/with-ops (+ ... (* ...) ...))
and then all the special symbols get rewritten/qualified with
clojure.core.matrix?
Dave
On Wed, Sep 4, 2013 at 10:26 PM, Sean
13 matches
Mail list logo
