Tassilo:
Thanks a lot. Your version may be my private version before it (may) make
into the language itself.
When I raise an issue like this, a very common answer is "you can do this
yourself". Maybe I can, but what is the purpose of a language? It gives you
a common framework so nobody needs to reinvent the wheels (and clutter the
code base with different copies), and also things (especially those at the
core of the language) are more efficient and coherent (I am sure Rich knows
how to make this faster much more than I do as he can play with the
internals not exposed to us). When I take a look of the Elisp
implementation of "subseq", it just use a "cond" to do different things on
vectors and sequences. I could have written that too, but the authors of
Emacs realize that it is a core part of the language and include it in. In
the future if Emacs decides to implement that part in C, everything using
it will get faster.
Back to the speed issue. If the concern is "this may be slow with certain
types", but the function is a core part of the abstraction, then what is
our options here? Don't put it into the language, let the user to define
it, so the language can say "hey, not my fault. I am super fast, your
function itself is slow". In that sense, assembly language is the fastest
and perfect, everything is the user's fault. The right option in my view is
to provide it in the language, because no matter how slow it is, the
version included most likely is faster than the user's own definition, and
any improvement in the future is going to benefit everyone. If in the end
it is still slow, than that is just the trade-off of using this particular
high-level language, and we are no worse-off (as you will be even slower to
to have your own).
On Thursday, June 28, 2012 2:52:54 PM UTC-4, Tassilo Horn wrote:
>
> Warren Lynn <wrn.l...@gmail.com> writes:
>
> Hi Warren,
>
> > 1. add a new function "append", which splices multiple ordered
> collection
> > together and always returns the result in the concrete type of its first
> > argument. So:
> > (append [1] '(2 3)) => [1 2 3]
> > (append '(1) [2 3])) => (1 2 3)
> >
> > It is different from "concat" because it keeps the original concrete
> > type. This will solve the "into" problem. and "into" still has its
> > value because it works on non ordered collections too.
>
> Here's a version that seems to work. Well, it uses reflection and
> exploits the fact that all concrete clojure collections have a static
> create() method receiving a java.util.List, but since you said you don't
> care about performance...
>
> --8<---------------cut here---------------start------------->8---
> (defn create-method [c]
> (.getMethod (if (isa? c clojure.lang.ISeq)
> clojure.lang.PersistentList
> c)
> "create"
> (into-array Class [java.util.List])))
>
> (defn append [coll & more]
> (.invoke (create-method (class coll)) nil
> (to-array [(apply concat coll more)])))
> --8<---------------cut here---------------end--------------->8---
>
> testi.core> (append [1 2] '(3 4))
> [1 2 3 4]
> testi.core> (append '(1 2) '(3 4))
> (1 2 3 4)
> testi.core> (append (seq [1 2]) '(3 4))
> (1 2 3 4)
> testi.core> (append #{1 2} '(3 4)) ;; ok, that's no sequential...
> #{1 2 3 4}
>
> > If a post like this will get no attention from the Clojure gods, where
> > should I submit the idea?
>
> You got attention. No clue if gods or mere mortals responded, but
> hey. ;-)
>
> But I think there are no big chances to get a function into Clojure that
> performes badly with some collections and is super-fast with others.
> The problem is simply, as soon as it's there, it will be used and people
> will start complaining about Clojure's slowness without considering that
> they use the wrong collection types for the functions they are using.
> And yes, there are some counter examples like `count` and `last`...
>
> Bye,
> Tassilo
>
On Thursday, June 28, 2012 2:52:54 PM UTC-4, Tassilo Horn wrote:
>
> Warren Lynn <wrn.l...@gmail.com> writes:
>
> Hi Warren,
>
> > 1. add a new function "append", which splices multiple ordered
> collection
> > together and always returns the result in the concrete type of its first
> > argument. So:
> > (append [1] '(2 3)) => [1 2 3]
> > (append '(1) [2 3])) => (1 2 3)
> >
> > It is different from "concat" because it keeps the original concrete
> > type. This will solve the "into" problem. and "into" still has its
> > value because it works on non ordered collections too.
>
> Here's a version that seems to work. Well, it uses reflection and
> exploits the fact that all concrete clojure collections have a static
> create() method receiving a java.util.List, but since you said you don't
> care about performance...
>
> --8<---------------cut here---------------start------------->8---
> (defn create-method [c]
> (.getMethod (if (isa? c clojure.lang.ISeq)
> clojure.lang.PersistentList
> c)
> "create"
> (into-array Class [java.util.List])))
>
> (defn append [coll & more]
> (.invoke (create-method (class coll)) nil
> (to-array [(apply concat coll more)])))
> --8<---------------cut here---------------end--------------->8---
>
> testi.core> (append [1 2] '(3 4))
> [1 2 3 4]
> testi.core> (append '(1 2) '(3 4))
> (1 2 3 4)
> testi.core> (append (seq [1 2]) '(3 4))
> (1 2 3 4)
> testi.core> (append #{1 2} '(3 4)) ;; ok, that's no sequential...
> #{1 2 3 4}
>
> > If a post like this will get no attention from the Clojure gods, where
> > should I submit the idea?
>
> You got attention. No clue if gods or mere mortals responded, but
> hey. ;-)
>
> But I think there are no big chances to get a function into Clojure that
> performes badly with some collections and is super-fast with others.
> The problem is simply, as soon as it's there, it will be used and people
> will start complaining about Clojure's slowness without considering that
> they use the wrong collection types for the functions they are using.
> And yes, there are some counter examples like `count` and `last`...
>
> Bye,
> Tassilo
>
On Thursday, June 28, 2012 2:52:54 PM UTC-4, Tassilo Horn wrote:
>
> Warren Lynn <wrn.l...@gmail.com> writes:
>
> Hi Warren,
>
> > 1. add a new function "append", which splices multiple ordered
> collection
> > together and always returns the result in the concrete type of its first
> > argument. So:
> > (append [1] '(2 3)) => [1 2 3]
> > (append '(1) [2 3])) => (1 2 3)
> >
> > It is different from "concat" because it keeps the original concrete
> > type. This will solve the "into" problem. and "into" still has its
> > value because it works on non ordered collections too.
>
> Here's a version that seems to work. Well, it uses reflection and
> exploits the fact that all concrete clojure collections have a static
> create() method receiving a java.util.List, but since you said you don't
> care about performance...
>
> --8<---------------cut here---------------start------------->8---
> (defn create-method [c]
> (.getMethod (if (isa? c clojure.lang.ISeq)
> clojure.lang.PersistentList
> c)
> "create"
> (into-array Class [java.util.List])))
>
> (defn append [coll & more]
> (.invoke (create-method (class coll)) nil
> (to-array [(apply concat coll more)])))
> --8<---------------cut here---------------end--------------->8---
>
> testi.core> (append [1 2] '(3 4))
> [1 2 3 4]
> testi.core> (append '(1 2) '(3 4))
> (1 2 3 4)
> testi.core> (append (seq [1 2]) '(3 4))
> (1 2 3 4)
> testi.core> (append #{1 2} '(3 4)) ;; ok, that's no sequential...
> #{1 2 3 4}
>
> > If a post like this will get no attention from the Clojure gods, where
> > should I submit the idea?
>
> You got attention. No clue if gods or mere mortals responded, but
> hey. ;-)
>
> But I think there are no big chances to get a function into Clojure that
> performes badly with some collections and is super-fast with others.
> The problem is simply, as soon as it's there, it will be used and people
> will start complaining about Clojure's slowness without considering that
> they use the wrong collection types for the functions they are using.
> And yes, there are some counter examples like `count` and `last`...
>
> Bye,
> Tassilo
>
On Thursday, June 28, 2012 2:52:54 PM UTC-4, Tassilo Horn wrote:
>
> Warren Lynn <wrn.l...@gmail.com> writes:
>
> Hi Warren,
>
> > 1. add a new function "append", which splices multiple ordered
> collection
> > together and always returns the result in the concrete type of its first
> > argument. So:
> > (append [1] '(2 3)) => [1 2 3]
> > (append '(1) [2 3])) => (1 2 3)
> >
> > It is different from "concat" because it keeps the original concrete
> > type. This will solve the "into" problem. and "into" still has its
> > value because it works on non ordered collections too.
>
> Here's a version that seems to work. Well, it uses reflection and
> exploits the fact that all concrete clojure collections have a static
> create() method receiving a java.util.List, but since you said you don't
> care about performance...
>
> --8<---------------cut here---------------start------------->8---
> (defn create-method [c]
> (.getMethod (if (isa? c clojure.lang.ISeq)
> clojure.lang.PersistentList
> c)
> "create"
> (into-array Class [java.util.List])))
>
> (defn append [coll & more]
> (.invoke (create-method (class coll)) nil
> (to-array [(apply concat coll more)])))
> --8<---------------cut here---------------end--------------->8---
>
> testi.core> (append [1 2] '(3 4))
> [1 2 3 4]
> testi.core> (append '(1 2) '(3 4))
> (1 2 3 4)
> testi.core> (append (seq [1 2]) '(3 4))
> (1 2 3 4)
> testi.core> (append #{1 2} '(3 4)) ;; ok, that's no sequential...
> #{1 2 3 4}
>
> > If a post like this will get no attention from the Clojure gods, where
> > should I submit the idea?
>
> You got attention. No clue if gods or mere mortals responded, but
> hey. ;-)
>
> But I think there are no big chances to get a function into Clojure that
> performes badly with some collections and is super-fast with others.
> The problem is simply, as soon as it's there, it will be used and people
> will start complaining about Clojure's slowness without considering that
> they use the wrong collection types for the functions they are using.
> And yes, there are some counter examples like `count` and `last`...
>
> Bye,
> Tassilo
>
--
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
