Re: [ANN] Time-Bombed Open License - thoughts?

If you are concerned about the free-rider problem, why not dual license under AGPL? It's seems sufficiently "viral" that most commercial entities will elect to take a commercial license, but it allows the source to be leveraged by other open source projects. The only downside is that AGPL do

Re: my first clojure "wat" moment - misunderstanding or bug?

you > need the sequence of keys. > > [1] > http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/util/EnumMap.java#EnumMap.EntryIterator > > Thanks, > Elias. > > On Wednesday, October 2, 2013 5:19:31 PM UTC-4, James Warren wrote: >> &

my first clojure "wat" moment - misunderstanding or bug?

I've been using Clojure for a couple months, so while I feel comfortable with it, I'm not certain whether some unusual behavior I encountered is a bug or a lack of understanding on my part. (I suspect the latter.) The context arose from using Clojure reflection to inspect a class generated by

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

I did not say that a debugger was not useful at all, I said that the > importance of having a > debugger is *overestimated* especially in an immutable world. > > Relying on a debugger as an important tool to support coding is like > admitting > the failure of your code before it runs. It's l

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

> Still miss the Elisp debugger, which is great. It's right there, in your > editing environment. It's good for debugging my own code. It's really > good for working out someone elses code. I wish I debug clojure in the > same way. It's not essential, of course. But nice. > > Phil > I miss

Re: "I don't feel the absence of a debugger, because I've learnt enough that I don't ever need a debugger."

May I suggest that as useful as your strategies are, they cannot replace a debugger? Let's be clear about our logic before claiming "it is not much needed". Maybe YOU really don't need it, but that is different from claiming it is not needed. A debugger as good as it is cannot replace the 4 fi

Re: ritz-nrepl starts up slowly?

> The killing of the user process is currently not very reliable. > > > This might be an Emacs "bug" (at least on Windows). The problem is there even for nrepl without ritz (some java process will still dangle there after exiting nrepl). What I did to work around this is to add some code/advi

Re: ritz-nrepl starts up slowly?

> > Is it normal to take this long to start the repl? > > > I don't know if it is normal. But I can confirm it takes much longer to start ritz-nrepl compared to nrepl only, which itself is already kind of slow. The slow speed really is killing a lot of fun here. -- -- You received this mes

Re: ANN: Spyscope 0.1.3

I requested some of the features added in this release. Thanks a lot for the work. -- -- 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 - plea

Re: Is it possible to set breakpoint using nrepl-ritz?

> Could you create an issue for this. > > > Just did that. Even with "M-x nrepl-ritz-break-on-exception" (and adding an (throw ...) in the code), it still does not work for me. Just hangs. Also after "M-x nrepl-ritz-break-on-exception", my "ac-nrepl" does not work anymore, Whenever auto co

Re: Is it possible to set breakpoint using nrepl-ritz?

> It is using the latest development code (C-c C-x C-b on the line to > break at). A release should be out containing this in the next few > days. > > Hugo > I was eager to use the line debugging commands but had no success. After "M-x nrepl-ritz-jack-in", I loaded a clojure file (just the

Re: emacs - how to wean me off the family of Java IDEs

> - is there a decent project explorer. I really miss the "tree on the left, editor on the right" layout Emacs is my favorite editor. But it is not perfect. My thoughts from my 8 years of using it are: 1. It is very customizable, as it builds on Elisp. After you learned some Elisp programmi

Re: STM - a request for "war stories"

On Wednesday, December 12, 2012 4:46:06 AM UTC-5, Marko Topolnik wrote: > > I wouldn't say that it should not have been added since its presence isn't > harming anything. You could say, though, that rarely anyone would realize > something was missing if Clojure didn't have the STM. > > > Alth

Re: tutorials or screencasts on debuggers in clojure?

+1. I just got the basic ritz-nrepl set up in the hope to try out the debugger. But I don't even know where to start. How to set a breakpoint, for example? I could not find it anywhere on the web or from Emacs "apropos". I figured it must be so obvious to others and I must be so stupid... Thank

Re: What is the design guideline for =?

> To work around the issue, = was changed to be in terms of equiv (see the > definitions in [2]). This allows compliance with the Map interface and > prevents (= (Square. 1 :red) (Rope. 1 :red)). > > [1] One idea was to have a hidden key corresponding to the record's type > be visible when usi

What is the design guideline for =?

With Clojure 1.4, I see this: (defrecord AA [a]) (= (AA. 1) {:a 1}) => false (= [1 2] '(1 2)) => true Another thread mentioned the second case. So if the second case is true, I thought the first one should be true too (different concrete type, but same data).I am quite confu

Re: Meaning of "="

On Wednesday, October 3, 2012 4:44:44 AM UTC-4, puzzler wrote: > > It is surprising at first, but since vectors are used so commonly in > Clojure instead of lists to represent literal sequential collections of > data, it turns out to be extremely convenient to be able to compare it for > equal

Re: Does Clojure support efficient coroutines?

All I need is some sort of threads that can handle 1000 simultaneous threads and 300,000 context switches per second. I don't actually need the coroutine value-passing feature; they are just one thing that lightweight threads can be built on top of. Regular OS threads (via java.lang.Thread) wou

Transactional memory design rationale

his sort of principled open nesting solves the problem that clojure's "commute" does but also handles cases when an operation commutes with _some_ other operations but not _all_, e.g. two hashmap writes to different keys don't conflict with each other but writes to the same key d

Does Clojure support efficient coroutines?

Hi, It seems the JVM doesn't provide any support for coroutines, generators, light-weight threads, or non-reusable continuations. I can't find any mention of coroutines in the docs, so I'm guessing Clojure doesn't have them due to the lack of JVM support. Is that corre

Re: Deprecation of Swank Clojure, long live nrepl.el

With Tim's pointer, I worked around the completion exception on namespace by redefining the resolve-class. However, there is still another problem: If my cursor stops at the end of a namespace without any slash, like this "(clojure.set", I got an exception again. This time, the exception is t

Re: Deprecation of Swank Clojure, long live nrepl.el

On Thursday, August 23, 2012 3:34:50 PM UTC-4, Warren Lynn wrote: > > > I don't think it is nREPL server related. It has to do with with > clojure.complete and lein repl. >> >> >> https://github.com/kingtim/nrepl.el/issues/63 >> >> -Tim >>

Re: Deprecation of Swank Clojure, long live nrepl.el

I don't think it is nREPL server related. It has to do with with clojure.complete and lein repl. > > > https://github.com/kingtim/nrepl.el/issues/63 > > -Tim > Thanks. I did not understand it correctly. I will wait for lein to be updated. -- You received this message because you are sub

Re: Deprecation of Swank Clojure, long live nrepl.el

Does anyone know how to let lein2 to use the latest nrepl server (beta9 for now). It seems right now (preview8) it is using beta8. I am eager to find out if beta9 fixed the ac-nrepl exception on namespace completion (according to ac-nrepl issue tracking, that is caused by the server). Thank yo

Re: Deprecation of Swank Clojure, long live nrepl.el

Hi Warren, > > You may want to check out https://github.com/purcell/ac-nrepl. > > Cheers, > Tim > > Thank you. I tried it out. It basically works but has glitches: 1. If I type "(clojure.repl/", right after the forward slash, I got a exception "java.lang.

Re: Deprecation of Swank Clojure, long live nrepl.el

I just gave a quick try on nrepl. It works right out of the box (at least the basics I tried) with jack-in. Thank you. Now I have two questions: 1. I did not not "ritz" before this post. Its debugging capabilities is attractive to me (I have not tried it yet). Is there any plan to have those

Re: Just wanted to say how much I like ClojurePY

On Thursday, August 16, 2012 9:00:50 AM UTC-4, Sean Neilan wrote: > > Hey All, > > ClojurePY is actually quite amazing. It has none of the complexities with > libraries and projects like Clojure and is suitable for crunching data > (because it's on Python) unlike Node.js/Clojurescript. You can u

Re: Rich's "The Value of Values" and REST

Rich was promoting functional programming. I can see functional programming has its benefits, but you will need mutable states eventually somewhere to do useful things. Functional programming just tell you to constraint yourself when using mutable states. It's not like mutable states are to be

Re: record constructor

the famous "let" > started as a pattern that was made into a macro that ended up in almost > every LISP in use today). > > Cheers, > > Josh > > > > -- > Joshua Ballanco > > ELC Technologies™ > 1771 NW Pettygrove Street, Suite 140 > Port

Re: record constructor

在 2012年8月7日星期二UTC-4下午9时11分58秒，Warren Lynn写道： > > > This construct is not very good. make-record is not first-class (It >> cannot be used as an argument to a function). >> Its first argument is not first-class (it has to be statically the >> name of a class). &

Re: record constructor

> This construct is not very good. make-record is not first-class (It > cannot be used as an argument to a function). > Its first argument is not first-class (it has to be statically the > name of a class). > > Good point. I am not happy with my own version because it is a pure run-time func

Re: record constructor

My reluctance (or allergy as you may suggest) about OOP is toward the > popular > implementations that are insanely verbose. > > Why is it insanely verbose? Just look at my example: (defrecord MyRecord [x y z] (make-record [arg1 arg2 arg3 ...] ...)) (make-record MyRecord arg1 arg2 arg3 ...)

Re: record constructor

You are challenging a line of logic that only exists as a strawman, an > expansion to the absurd -- changing the argument from one of sufficient > flexibility to one of abstractly greater, and therefor cumulative, > flexibility. > > -- > Craig Brozefsky > Premature reification is the root o

Re: record constructor

> We already have them. They are just functions. > (And I think thinking in term of "factory" functions does not make sense. > Every pure function takes something and makes something out of it) > > The construction of data from data is best taken care by functions. > That way you don't expose

Re: record constructor

On Sunday, August 5, 2012 7:23:55 PM UTC-4, Luc wrote: > > You have been referring to OOP several times in your posts, the kind of > patterns > we are talking about are these: > > http://en.wikipedia.org/wiki/Software_design_pattern > > These are the kind of design patterns OOP has been fond

Re: record constructor

B) I said I hate the pattern word, let me say it bluntly, elaborate > patterns have the unique > property of fossilizing a language as soon as you start to modify the > language > to support them. Especially complex ones. > It kills evolution the day you need to meet other nee

Re: record constructor

On Sunday, August 5, 2012 1:10:04 PM UTC-4, Nicolas Oury wrote: > > Constructors are not a good idea, because they tie the functionality > to the implementation. > > > You want to be able to change your record to something else without > changing your client code. > My answer to this is: eve

Re: record constructor

On Sunday, August 5, 2012 5:56:30 AM UTC-4, Vinzent wrote: > > +1 for Warren's proposal. I thought about the same thing earlier, but > haven't shared it with community because I believed it'd be rejected. > > Though, I don't see how OOP relates to the topic of this discussion. > Records are not

Re: record constructor

> My point was that you don't need a factory function if there's no > "construction logic" so the record alone - the data structure - is > sufficient for a lot of cases. Similarly you can choose to use a > "factory function" even if the underlying data structure is not a > record. They are se

Re: record constructor

I don't think it is "OO-phobia". I think a lot of people here have > used (several) OO languages and just find the FP way better - or at > least better for the problems they are solving. > If I am proposing something like state-mutation based OOP, that clearly conflicts with FP and I will ju

Re: record constructor

On Saturday, August 4, 2012 9:57:55 PM UTC-4, tbc++ wrote: > > Warren, I can't speak for others, but I can say that personally one of the > reasons I love Clojure so much is that it doesn't try to be a OOP language, > instead it cleanly separates data from logic. Clojure

Re: record constructor

> (and to be honest, Warren, I think you're beating yourself up somewhat > by trying to shoehorn OO practices into Clojure in the first place but > maybe that's something everyone goes thru if they are heavily steeped > in OO thinking, when they first try to adopt an

Re: record constructor

On Saturday, August 4, 2012 8:30:50 PM UTC-4, Luc wrote: > > Count me as a fan I designed and wrote complex systems in assembly > language > many of them above 10k lines. > > I can only admire you for that. Assemly language certain has its uses, but it is not really for average folks like m

Re: record constructor

On Saturday, August 4, 2012 6:07:20 PM UTC-4, Jim foo.bar wrote: > > ok this is clearer now! I actually like what you're proposing just > not in the form you're proposing it...since the record will already create > 2 constructors in the underlying class, having essentially a 3rd sounds a

Re: assoc! order problem

I have not used transient yet so I don't understand your code. But for ordered maps, I use ArrayMap. -- 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

Re: record constructor

> > I am not sure I follow...If you're just creating a new record yourself, > you can pass whatever you want to the constructor...no need for > 'setting' whatsoever...On the other hand if you're consuming an object > then you might need to 'set' some fields before it is useful (where doto >

Re: record constructor

On Saturday, August 4, 2012 1:15:13 PM UTC-4, Jim foo.bar wrote: > > for setting up objects as you say, I'm fine using (doto Object ... ... > ...). Records, as everything else in Clojure promote immutability and > so setting fields doesn't really make sense unless you're consuming > external

record constructor

My vague impression is this has been discussed somewhere, but I did not find a ticket in Jira when searching on "record, constructor", so I want to have some discussion here before considering entering a ticket myself. Often, when I create a record, I need to do some set-up more than just pass

Re: doc strings for both interfaces and concrete implementations

I won't object, and the alter-meta! approach allows you to do that. Of > course, it cannot provide documentation for the implementations, but the > interface docs may be extended with impl docs incrementally at the > location where the implementation is defined. That's at least better > than

Re: doc strings for both interfaces and concrete implementations

> In general, all different versions of a function should somehow do the > same thing, so with separate docstrings you'd need to repeat yourself. > A good guideline is to write the "big picture" first, followed by the > meaning of the different parameters. > > I agree the design should keep a

doc strings for both interfaces and concrete implementations

Is there a way to create doc strings on both interfaces (procotols, multi functions) and concrete implementations (protocol implementation, multi-methods)? For now it seems to me I can only have doc strings for the interfaces. If that is the case, I feel it is something worth fixing, because in

Re: Any downside of record compared to map

Thank everybody for the discussion. I am now aware of some pitfalls in using defrecord. For me, I like to have type information associated with my data. I still prefer defrecord over map in general, but I will proceed with more caution. I think some pitfalls here are not due to the greatness o

Re: Any downside of record compared to map

I don't think you're in the minority. I prefer regular maps to records > in general. struct-map was deprecated "a long time ago" (in Clojure > 1.2). clojure.java.jdbc stopped using struct-map a while back - at the > recommendation of Clojure/core - in favor of regular maps. > > Chas Emerick's

Re: Doc string for variables and record

http://clojure.org/special_forms > > (def sym "docstring" 'value) > > I don't think defrecord creates a Var so I don't think you can specify > a docstring for that? > > Thanks that works for symbols. I know derecord does not create a Var, but it would still be nice to be able to have a doc s

Doc string for variables and record

In Elisp, with "defvar" I can specify a docstring for a variable. I could not find how to do that in Clojure with "def" and "defrecord". Can someone show me the way? Thank you. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group,

Any downside of record compared to map

I plan to change all my major data structures to records instead of plain maps. Since record has everything a map provides, I figure there won't be any harm. But is that really so? Would appreciate the opinions from people who know better. -- You received this message because you are subscribe

Prefix dot in protocol method

I found that if I define a protocol like this: (defprotocol IProc (procMethod [this] "some method")) I can invoke it on a type either (procMethod object) or (.procMethod object) Note the prefix dot in the second case. I like this "dot" version because that means I can replace a record field

Re: atom and lock

It's not. Locks are created by using CAS, not the other way around. > On a x86 machine the swap basically compiles down to a single assembly > code instruction: > > http://jsimlo.sk/docs/cpu/index.php/cmpxchg.html > > On a normal x86 machine, every lock in the system will boil down to > usin

Re: atom and lock

Thanks for the discussion This is not a reply to any particular post. Here is my thinking on the various points raised. 1. The length of the critical section is irrelevant in this discussion. Even with locks, people agree that the critical section should be as short as possible. So the limiting

Re: atom and lock

For people who are interested, here is my own version of atom updating functions: ;; A wrapped up atom that can be used in those lock-* functions (deftype LockAtom [atom] clojure.lang.IDeref (deref [this] @(.atom this))) ;; (lock-atom (+ 4 5)) => # (defmacro lock-atom "Like ATOM, but

Re: atom and lock

> Finish the thought, what happens when there is "contention", a thread > reads then writes before you acquire the lock to commit. You can try > and making locking work, but you'll just up with CAS based on a lock > > > I am not saying to throw away the "swap!" syntax. "swap!" syntax guarantee

Re: atom and lock

> (def a (atom {})) > > (defn add-kv [k v] >(swap! assoc k v)) > > If I call add-kv from multiple threads, how can I assume that the map > won't be modified in the middle of the assoc? Sure, I could lock, but > read this article first: > http://en.wikipedia.org/wiki/Non-blocking_algorit

Re: atom and lock

On Tuesday, July 17, 2012 7:50:10 PM UTC-4, red...@gmail.com wrote: > > if you do it as a lock, then readers must block writers (think it > through). Clojure's reference types + immutable datastructures and the > views on perception that underlay them are strongly opposed to readers > interfer

atom and lock

I have a hard time understanding why there is a need to retry when doing "swap!" on an atom. Why does not Clojure just lock the atom up-front and do the update? I have this question because I don't see any benefit of the current "just try and then re-try if needed" (STM?) approach for atom (may

Re: mutual reference in FP style

On Saturday, July 7, 2012 3:42:58 AM UTC-4, Philip Potter wrote: > > Sounds like zippers may be able to help you here. When you use a zipper to > descend into a tree, it automatically generates a trail of breadcrumbs to > enable you to ascend back to the top, without needing backreferences in t

Re: mutual reference in FP style

r old value, 2+3 for children > :children ({:value 3, ;; 2 for old value, 1 for parent > :children ()} > {:value 8, ;; 3 for old value, 1 for parent, 4 for children > :children ({:value 7, ;; 4 for old value, 3 for parent > :children (

Re: mutual reference in FP style

Hi, Phil: Thanks for your detailed analysis. My use-case is I have a tree and want to walk over the tree and apply a function on the nodes. The operation of the function also depends on the parent and children of the node, so it will be nice if each node already contains the references to its

mutual reference in FP style

Can someone help me figure out how I can have two data structures to refer to each other in functional programing style? I mean something like double linked list, or in a tree where each node keeps a reference to its parent and children. What puzzles me is, as soon as you update the reference in

Re: Protocol specific type hierarchy

Ok, it seems I cannot make it work unless the "get-method" for protocol is available, The reason is, in the example by Michal, the return value from "(get-in IFoo [:impls user.Bar :foo])" is a Java function, not a true Clojure function with true dynamic typing. So, take the same example: (def

Re: Protocol specific type hierarchy

hink > it'd > > be a good idea to implement proof-of-concept of what you have in mind > and > > publish it on Github, so people could try it and compare to what they > > already have. > > > > вторник, 3 июля 2012 г., 21:13:27 UTC

Re: Understand extends? result

Is it possible that "satisfies?" is a better predicate to use than "extends?"? > > But it only works on instances, not types. -- 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 tha

Re: Understand extends? result

On Tuesday, July 3, 2012 2:33:52 PM UTC-4, Ambrose Bonnaire-Sergeant wrote: > > Hi Warren, > > You could use "extenders" to get all Classes that extend to the protocol > and then iterate over them, testing with isa?. > > (some #(isa? MyClass %) (extenders MyP

Understand extends? result

In the following example: (defprotocol testp (foo[this])) (extend-protocol testp clojure.lang.PersistentVector (foo [this] "PersistentVector impl")) (extend-protocol testp clojure.lang.Seqable (foo [this] "Seqable impl")) (foo []) => "PersistentVector impl" (foo '()) => "Seqable impl" (extends?

Re: Protocol specific type hierarchy

On Tuesday, July 3, 2012 12:40:24 PM UTC-4, Vinzent wrote: > > Well, as far as I understand, protocols was made as they were on purpose, > so inability to create hierarchies is a "feature" (like it or not), while > the lack of `get-method`-like thing is clearly a defect (in my mind). > > Anyway

Re: Protocol specific type hierarchy

On Tuesday, July 3, 2012 4:18:44 AM UTC-4, Vinzent wrote: > > I believe the protocol's analogue for get-method would be enough. > > > If here you mean we just need to use get-method to directly reuse a protocol method anywhere, I think that is not adequate. We need to maintain the hierarchy s

Protocol specific type hierarchy

When I re-read the thread "defrecord with inheritance" https://groups.google.com/forum/?fromgroups#!searchin/clojure/inherit/clojure/mr-o9sRyiZ0/oM4zRz4dXYsJ I am thinking: conceptually, for code reuse, is it a good idea to have protocol specific type hierarchy? I mean something like this: (defr

Re: 'last' on empty collections

That would be horribly inconsistent with the rest of Clojure, IMO: Sure it will be. That is why I said this is an academic one, and I don't expect any change to current one. > Warren, this and some of your other issues with how Clojure works > makes me curious about your language

Re: 'last' on empty collections

On Sunday, July 1, 2012 4:21:02 PM UTC-4, Dennis Haupt wrote: > > i'd do (actually, i did) it like this: > (my-special-last coll) -> returns the last element or throws an > exception if there is none > (my-special-last coll if-empty) -> in case of an empty collections, > ifEmpty is returned >

Re: Why cannot "last" be fast on vector?

I promised I won't post more on this thread. But Rich is here and I think I can grant myself an excuse to post just one more. End of it, I promise. :-) First, although Rich does not think so, I myself feel this topic is very important as it is not just about "last", It touches some fundamental

'last' on empty collections

Right now (last []) => nil (last [nil]) => nil So there is no way to differentiate these two (except with some emptiness checking). In my opinion (last []) should throw an exception, because that's when last does not apply. From another point of view, there are two cases: 1. The local semantics

Re: Clojure type of Java array

u encounter them at runtime. > > http://dosync.posterous.com/51626638 > > David > > On Sun, Jul 1, 2012 at 1:17 PM, Warren Lynn wrote: > > > > So if I want to extend a protocol to all Java arrays, is there a single > type > > I can use? Sounds like not.

Re: Clojure type of Java array

So if I want to extend a protocol to all Java arrays, is there a single type I can use? Sounds like not. So I need to extend the protocols to char arrays, int arrays and etc? On Sunday, July 1, 2012 12:20:19 PM UTC-4, dennis wrote: > > (type (.toCharArray "Clojure")) is a class, [C means an a

Clojure type of Java array

Somebody asks me to add handling of Java array in clj-cc/last. But I am confused what will be the type of Java array in Clojure. Fox example: (type (.toCharArray "Clojure")) => [C ;; Note: it looks like garbage. but that is what I actually got (isa? (type (.toCharArray "Clojure")) j

Re: Protocol as an abstract data type

implementation which only supports one abstract protocol!) I don't feel strongly about last specifically, but if people wanted it to behave polymorphically, I'd be happy to volunteer to write the code. Thanks a lot for the detailed analysis and volunteering to write the code. Not surprisingly

[ANN] clj-cc lib

Available here: https://github.com/wrn/clj-cc This is a very simple lib (for now only three functions) that I created in response to people's suggestions in the following two threads: 1. Why cannot "last" be fast on vector?

Re: Why cannot "last" be fast on vector?

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 implemen

Re: Why cannot "last" be fast on vector?

e a better experience using it. That is my goal (obvious I hope). On Saturday, June 30, 2012 12:17:39 PM UTC-4, Craig Brozefsky wrote: > > Warren Lynn writes: > > >As I mentioned before, the issue here is not just a fast "last". The > >issue here is

Re: Why cannot "last" be fast on vector?

undamental design principle of Clojure that, when given two > approaches, A and B, make primitive the one that could be used to build the > other. Clojure's "peek" and "last" might be useful to somebody building > the "last" that Warren wants. Warre

Re: Why cannot "last" be fast on vector?

eality. On Saturday, June 30, 2012 3:47:58 AM UTC-4, Craig Brozefsky wrote: > > Warren Lynn 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 >

Re: Why cannot "last" be fast on vector?

On Friday, June 29, 2012 9:23:09 PM UTC-4, Bobby Eickhoff wrote: > > 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" operate

Re: Why cannot "last" be fast on vector?

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

Re: Why cannot "last" be fast on vector?

ed to use "peek" for vector and "last" for sequence. That defeats the very purpose of abstraction. On Friday, June 29, 2012 7:42:14 PM UTC-4, David Nolen wrote: > > On Fri, Jun 29, 2012 at 6:49 PM, Warren Lynn wrote: > > The same? If internally it can be faster, be f

Re: Why cannot "last" be fast on vector?

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 > wrote: > > It is clear that some collections *could* support a more efficient last. > > Anything with

Re: Why cannot "last" be fast on vector?

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 is

Re: Why cannot "last" be fast on vector?

2012 4:41:59 PM UTC-4, David Nolen wrote: > > On Fri, Jun 29, 2012 at 4:25 PM, Warren Lynn wrote: > > My understanding here is "ISeq" is an INTERNAL, implementation level > > interface/abstraction, not the user/language level abstraction (which in > > this case sh

Re: Why cannot "last" be fast on vector?

eld wrote: > > On Fri, Jun 29, 2012 at 7:51 AM, Warren Lynn 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 rat

Re: Why cannot "last" be fast on vector?

their > own interrest. > > It is logical you ask for it, but there is no need to insist or maybe > be a little offensive if others don't share your views. > > Regards, > > Nicolas Bousquet. > > On 29 juin, 01:32, Warren Lynn wrote: > > This is an off-sho

Re: Why cannot "last" be fast on vector?

> 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 fre

Re: Why cannot "last" be fast on vector?

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 peopl

Re: Why cannot "last" be fast on vector?

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 go

  1   2   >