I fully support Warren's point of view. I'm also unhappy with current
behaviour of sequence functions (more accurate: I think it can be made even
better).
In my mind, protocols (interfaces?) based, polymorphic core functions is
just what we need. Moreover, similar request has been done
Warren Lynn wrn.l...@gmail.com writes:
Although I have not yet looked at any of Clojure's internals yet, I
suspect the change won't be too difficult (for the right person). So I
hope/wish someone with enough knowledge, skills and influence will
agree with me and advocate a review
Sam Ritchie sritchi...@gmail.com writes:
Perhaps place them inside a protocol, where core supplies
I don't think a protocol is needed to identify a performance
characteristic, which as far as I can tell really is limited to vectors.
The definition of vector? itself is sufficient.
Also,
Having separate peek and last, with documented performance characteristics,
makes it straightforward to reason about how code is likely to perform, a point
that Mark made earlier.
It is a fundamental design principle of Clojure that, when given two
approaches, A and B, make primitive the one
On Friday, June 29, 2012, Mark Engelberg wrote:
On Fri, Jun 29, 2012 at 4:50 PM, David Nolen dnolen.li...@gmail.comwrote:
ISeq *is* an interface on Clojure JVM. But ideally it would be
protocol as in ClojureScript. But then all ISeq implementing types
must also implement this new protocol
As I mentioned before, the issue here is not just a fast last. The issue
here is I find the design of Clojure wrong, or confusing. That really
shakes my confidence in the whole system.
I am also not talking about implementations, which is a separate issue that
I don't know much yet
On Saturday, June 30, 2012 9:51:56 AM UTC-4, stuart@gmail.com wrote:
Having separate peek and last, with documented performance
characteristics, makes it straightforward to reason about how code is
likely to perform, a point that Mark made earlier.
As I said before, I strongly feel
Warren Lynn wrn.l...@gmail.com writes:
As I mentioned before, the issue here is not just a fast last. The
issue here is I find the design of Clojure wrong, or confusing. That
really shakes my confidence in the whole system.
To say stuff like this, then be demure about digging into
Craig:
If the dominant community attitude is before you know everything about
Clojure, you have no right to comment, then that itself will be the reason
not to use Clojure. But I think that is just you, not the community.
Although I am glad some people paid attention to this post, I have far
Warren,
I think the issue is this:
You claim there is sg. broken in clojure while admitting that you know
little about how the design decision was made.
People that know clojure's implementation and the history of design
decisions inside-out offered advice why they think it is not broken, they
On Saturday, June 30, 2012 1:03:04 PM UTC-4, Las wrote:
Warren,
I think the issue is this:
You claim there is sg. broken in clojure while admitting that you know
little about how the design decision was made.
People that know clojure's implementation and the history of design
On Sat, Jun 30, 2012 at 7:09 AM, Warren Lynn wrn.l...@gmail.com wrote:
As I mentioned before, the issue here is not just a fast last. The issue
here is I find the design of Clojure wrong, or confusing. That really
shakes my confidence in the whole system.
Some of Clojure's design decisions
On Sat, Jun 30, 2012 at 10:24 AM, Warren Lynn wrn.l...@gmail.com wrote:
I think some people agree with me something is broken here (puzzler, for
example. Please correct me is I am wrong as I don't want to hijack other
people's opinion).
One really nice thing about the Clojure community is
Tamreen:
Thank you. Your posts really explained why it is so. I understand the
reasons now, but I can hardly agree those reasons are good ones (not
arguing with you, as you pointed out, the reasons are weak for this case).
As I pointed out before in my other post (General subsequence
On Fri, Jun 29, 2012 at 10:51 AM, Warren Lynn wrn.l...@gmail.com wrote:
1. Put good documentations on the functions, and the programmer needs to
have some idea what data structure is fast/slow for what use. If the
programmer does not have a clue, why would making last artificially slow
on
Sorry, I should have addressed my last post to puzzler.
On Friday, June 29, 2012 10:51:44 AM UTC-4, Warren Lynn wrote:
Tamreen:
Thank you. Your posts really explained why it is so. I understand the
reasons now, but I can hardly agree those reasons are good ones (not
arguing with you, as
Surely nobody can restrict/enforce anything on anybody, and I can always
have my own mycore ns. In theory, I could even create my own language
without the need to persuade anybody (or just fork from Clojure and have my
own private copy). That will be the ultimate Libertarian, but some people
The design choice has nothing to do with speed, it has nothing to do
with concrete types like lists and vectors either, no matter what
might have been said before by others.
David
If the design choice has nothing to do with speed path, Could you let us
know why we cannot get free
On Fri, Jun 29, 2012 at 12:13 PM, Warren Lynn wrn.l...@gmail.com wrote:
If the design choice has nothing to do with speed path, Could you let us
know why we cannot get free speed improvements on vectors?
I already have.
--
You received this message because you are subscribed to the Google
I'm sorry to say, but IMHO you failed to communicate the critical point to
your audience. If your audience keeps failing to grasp the point, and
communicates this failure back by asking the same question..
I do understand the distinction between a collection and a sequence and
something being a
On Fri, Jun 29, 2012 at 12:30 PM, Weber, Martin S martin.we...@nist.gov wrote:
I'm sorry to say, but IMHO you failed to communicate the critical point to
your audience. If your audience keeps failing to grasp the point, and
communicates this failure back by asking the same question..
Perhaps
I would say we can have different ways of designing things.
A way is to design abstractions and provide services on top on theses
abstractions. The abstraction here is ISeq. That is sequences. Last
is not part of the ISeq abstraction and just work on top of it. There
is no way to access last
On Fri, Jun 29, 2012 at 7:51 AM, Warren Lynn wrn.l...@gmail.com wrote:
1. Put good documentations on the functions, and the programmer needs to
have some idea what data structure is fast/slow for what use.
At the risk of continuing what is quickly becoming a rather fruitless
thread, I figured
Thanks for clarifying more on the rationale behind the design. Also a note
on the tone: I never thought insisting on a view is offensive. Insisting
our views are the essence of a debate. But we need to insist based on
reasons and acknowledge when we are wrong. Also, I realize that sometimes
Even not a single action is taken because of this thread, I still would not
consider the thread fruitless. It helped me (and maybe others) understand
the issue better.
My point was: you need a clear documentation on a coherent, consistent
abstraction, and let the programmer to understand. Just
On Fri, Jun 29, 2012 at 4:25 PM, Warren Lynn wrn.l...@gmail.com wrote:
My understanding here is ISeq is an INTERNAL, implementation level
interface/abstraction, not the user/language level abstraction (which in
this case should be ordered collection, as somebody called)
It is not internal. It
You are right, clojure.lang.ISeq is public and I can see it from user
namespace.
But that is not what I meant, the ordered collection is a language level
abstraction, clojure.lang.ISeq is an exposed interface. With regard to
last, clojure.lang.ISeq is still implementation level, even if it is
It is clear that some collections *could* support a more efficient last.
Anything with random access. Anything that supports rseq (e.g., sorted
collections).
There are multiple ways to accomplish this; I presume a protocol would do
the trick.
Perhaps the original design decision is easily
Although I have not yet looked at any of Clojure's internals yet, I suspect
the change won't be too difficult (for the right person). So I hope/wish
someone with enough knowledge, skills and influence will agree with me and
advocate a review of the design (last may not be the only one with
On Fri, Jun 29, 2012 at 5:17 PM, Mark Engelberg
mark.engelb...@gmail.com wrote:
It is clear that some collections *could* support a more efficient last.
Anything with random access. Anything that supports rseq (e.g., sorted
collections).
And what does overloading last in this way mean for
The same? If internally it can be faster, be faster. If not, don't change.
On Friday, June 29, 2012 6:05:37 PM UTC-4, David Nolen wrote:
On Fri, Jun 29, 2012 at 5:17 PM, Mark Engelberg
mark.engelb...@gmail.com wrote:
It is clear that some collections *could* support a more efficient last.
Perhaps place them inside a protocol, where core supplies implementations
for ISeq only? This would make it easier to extend efficient behavior to
other types without placing a big burden on core.
On Fri, Jun 29, 2012 at 3:05 PM, David Nolen dnolen.li...@gmail.com wrote:
On Fri, Jun 29, 2012 at
On Fri, Jun 29, 2012 at 6:49 PM, Warren Lynn wrn.l...@gmail.com wrote:
The same? If internally it can be faster, be faster. If not, don't change.
For which types do you think they can be made faster?
David
--
You received this message because you are subscribed to the Google
Groups Clojure
On Fri, Jun 29, 2012 at 7:28 PM, Sam Ritchie sritchi...@gmail.com wrote:
Perhaps place them inside a protocol, where core supplies implementations
for ISeq only? This would make it easier to extend efficient behavior to
other types without placing a big burden on core.
ISeq *is* an interface
vectors and sorted collections, for sure.
On Fri, Jun 29, 2012 at 4:42 PM, David Nolen dnolen.li...@gmail.com wrote:
On Fri, Jun 29, 2012 at 6:49 PM, Warren Lynn wrn.l...@gmail.com wrote:
The same? If internally it can be faster, be faster. If not, don't
change.
For which types do you
I really don't know, as I know very little about how these things are
implemented. My point is, we maintain a coherent abstraction and get the
best speed we can. To recap, what I don't like about current last is it
makes writing generic code difficult. Currently, I need to use peek for
vector
On Fri, Jun 29, 2012 at 4:50 PM, David Nolen dnolen.li...@gmail.com wrote:
On Fri, Jun 29, 2012 at 7:28 PM, Sam Ritchie sritchi...@gmail.com wrote:
Perhaps place them inside a protocol, where core supplies implementations
for ISeq only? This would make it easier to extend efficient behavior
Again, I don't know the internal details. If you are saying because of the
current implementation, the change is difficult, then we will be talking
about the implementation, not about the abstraction design. I have very
little to say about that.
On Friday, June 29, 2012 7:50:56 PM UTC-4, David
On Fri, Jun 29, 2012 at 8:02 PM, Mark Engelberg
mark.engelb...@gmail.com wrote:
I think the suggestion is to create a protocol for each function that could
potentially gain speed improvements for specialized types. So for example,
ILast could be a protocol. extend ILast to have an
Warren, you're on the right track with your alternative design: Intuitively
and ideally, last should return the last element of a finite, ordered
collection. But Clojure's last operates on sequences, not collections.
This is problematic because sequences can be (effectively) infinite.
On Fri, Jun 29, 2012 at 5:17 PM, David Nolen dnolen.li...@gmail.com wrote:
As I said, if ISeq and ILast are both protocols that won't work. No
protocol inheritance.
I don't see how inheritance factors into this. This works just fine in
Clojure 1.3. What am I missing?:
(defprotocol Last
Bobby:
Thanks for confirming my sanity here. But I have a different opinion on the
attractive nuisance label on last function. Sure if you call last on
an infinite sequence that will not work (the program will get stuck?), but
it is no more dangerous than other dynamic part of the language.
ISeq is a interface on Clojure JVM. So that will work. In ClojureScript it
won't as ISeq is a protocol.
On Friday, June 29, 2012, Mark Engelberg wrote:
On Fri, Jun 29, 2012 at 5:17 PM, David Nolen
dnolen.li...@gmail.comjavascript:_e({}, 'cvml', 'dnolen.li...@gmail.com');
wrote:
As I said,
On Fri, Jun 29, 2012 at 4:50 PM, David Nolen dnolen.li...@gmail.com wrote:
ISeq *is* an interface on Clojure JVM. But ideally it would be
protocol as in ClojureScript. But then all ISeq implementing types
must also implement this new protocol you are suggesting to get these
basic *generic*
On Fri, Jun 29, 2012 at 8:55 PM, Mark Engelberg mark.engelb...@gmail.comwrote:
my understanding is that in Clojure, every protocol generates a Java
interface, so I can't think of any reason why you couldn't list that
generated interface as a type in another protocol (although I haven't
tried
This is an off-shoot subject from my last post General subsequence
function.
I found people had similar questions before (one year ago):
http://groups.google.com/group/clojure/browse_thread/thread/712711f049507c63/aea7cf438aa22922
As of Clojure 1.4, seems nothing changed, as source show here:
On Thu, Jun 28, 2012 at 7:32 PM, Warren Lynn wrn.l...@gmail.com wrote:
This is an off-shoot subject from my last post General subsequence
function.
I found people had similar questions before (one year ago):
Here's a somewhat old but still generally useful article on how Clojure
vectors are implemented:
http://blog.higher-order.net/2009/02/01/understanding-clojures-persistentvector-implementation/
Vectors are optimized for random access, whereas lists are optimized for
going through from the
On Thu, Jun 28, 2012 at 6:59 PM, Tamreen Khan histor...@gmail.com wrote:
Here's a somewhat old but still generally useful article on how Clojure
vectors are implemented:
http://blog.higher-order.net/2009/02/01/understanding-clojures-persistentvector-implementation/
Vectors are optimized for
Nevertheless, I hope I've clarified the reasoning behind the current
design. Early Clojure design decisions have a lot of inertia, so as David
pointed out, this is very unlikely to change.
Well put.
I would argue as well, that many functional languages I've come across
take this stance: the
So you recommend that last should be only function that accepts
IPersistentStack *and* ISeqable and does the appopiate thing? Or are there
others?
On Thursday, June 28, 2012, Mark Engelberg wrote:
On Thu, Jun 28, 2012 at 6:59 PM, Tamreen Khan
histor...@gmail.comjavascript:_e({}, 'cvml',
Hi,
Am Freitag, 29. Juni 2012 05:26:07 UTC+2 schrieb tbc++:
For instance, one such function I wrote tonight is called every-other
(returns '(1 3 5) if you hand it (1 2 3 4 5))
user= (take-nth 2 [1 2 3 4 5])
(1 3 5)
Kind regards
Meikel
--
You received this message because you are
52 matches
Mail list logo
