> If you want to see something like this in clojure.core, you can create a
> ticket on JIRA, preferably with a patch adding the new function as well as
> some unit tests, and then some day it may be screened and later included in
> Clojure's core code. For some of the reasons you have read in
Hi,
are there fellow Clojurians from Prague, Czech Republic using Clojure to
attack real problems?
I started with Clojure about three months ago. At the beginning it was
curious experiment, now it is full time engagement. And you know -
programming can be fun again :)
Would you like to meet fo
Hi there, I've been browsing through the code trying to wrap my head the
new reducers library.
I came across 2 functions called 'reduce' in APersistentVector.java around
line 447. The don't have the same 'reduced?' check that ArrayChunk.java
has in it's implementation of reduce (around line 57
*Format:*
James Reeves is giving a talk on Designing web applications using Ring and
Compojure. We've also got lightning talks from Jennifer Smith and Robert
Rees.
*Registration:*
The event is happening on Tuesday 3rd July 2012. You can register, and find
venue details,
here: http://skillsmatt
But elisp vectors can't be accessed like lists, try running "car" on one.
On Thu, Jun 28, 2012 at 1:55 PM, Warren Lynn wrote:
> Here is "another language" elisp:
>
> Anybody who use Emacs can do this:
>
> (subseq (make-vector 5 10) 2 4) => [10 10]
> (subseq '(10 10 10 10 10) 2 4) => (10 10)
>
>
I've just started playing with Clojure and I have a newbie question:
I have an anonymous function that takes a variable number of parameters. I
coded it so it takes a list of strings or functions that return strings and
concatenates the resultant strings like so:
(defn example [& args] (reduce
> My question is: I would like to allow the first parameter to be an
> (optional) map containing key values for the function. What's a clean,
> readable way to do that?
How about this:
(defn example [& args]
(let [opts (when map? (first args))
args (when opts (next args))]
(redu
Getting code into a Clojure contrib library, or into clojure.core, require
convincing others that maintain the appropriate namespace.
One way to be persuasive is to make a library of useful code on github and
clojars.org, advertise it here, and have folks try it out. If they do, and
like what
Hi,
(defn example
[& args]
(let [[opts args] (let [opts? (first args)]
(if (map? opts?)
[opts? (next args)]
[nil args]))]
(reduce str args)))
Kind regards
Meikel
--
You received this message because you are subscribed
Before we had reducers we had a optimization (and still have this
optimization) called internal-reduce:
https://github.com/clojure/clojure/blob/master/src/clj/clojure/core/protocols.clj#L86
If you run reduce on a seq, then your only option is to walk through
the structure one cell at a time, doin
I wonder if there is any "official" (i.e. stable and ideally documented) way
to use logic variables and unification from core.logic without running the
constraint solver. More specifically, I'd like to
- define some logic variables
- do some unifications
- enquire the resulting constraint list ask
On Fri, Jun 29, 2012 at 9:37 AM, Konrad Hinsen
wrote:
> I wonder if there is any "official" (i.e. stable and ideally documented) way
> to use logic variables and unification from core.logic without running the
> constraint solver. More specifically, I'd like to
>
> - define some logic variables
>
David Nolen writes:
> It's important that core.logic be constructed on a solid set of lower
> level primitives. What functionality are you afraid of using from the
> outside?
What I worry about is not so much losing functionality, but
restructuring of the code or renaming of the interfaces, f
> Of course all that machinery exists in core.logic and I think I
> identified most of it, but those interfaces don't look like they were
> meant to be used "from the outside". I certainly don't want to fix my
> code with every new release of core.logic. That's why I am looking
> for something more
On Fri, Jun 29, 2012 at 10:29 AM, Konrad Hinsen
wrote:
> What I worry about is not so much losing functionality, but
> restructuring of the code or renaming of the interfaces, functions,
> etc.
>
> Konrad.
I don't forsee the protocols or functions around logic vars &
unification changing. I'm act
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 function
On Fri, Jun 29, 2012 at 10: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. If the
> programmer does not have a clue, why would making "last" artificially slow
> on vectors help? Plu
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
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
> 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
On Fri, Jun 29, 2012 at 12:13 PM, Warren Lynn 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
Groups "Clojure" gro
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 co
On Fri, Jun 29, 2012 at 12:30 PM, Weber, Martin S 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 we differ on the mat
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 elem
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 rather fruitless
thread, I figured I'd quote the docs
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
deb
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 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 is a user/la
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 i
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 justif
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
Hi,
They say that a part of a learning is to ask questions. Lots of
questions. That's why I'm here. I need your advice.
There's a team I'm a part of where people used to write Java apps.
They're fine with the job, but they do everything in Java. I thought
I'd introduce Clojure as a functional lan
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 random access. Anything that supports rseq (e.g., sorted
> collections).
And what does overloading last in this way mean for drop-last,
take-last, but
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
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 wrote:
> On Fri, Jun 29, 2012 at 5:17 PM, Mark Engelbe
On Fri, Jun 29, 2012 at 6:49 PM, Warren Lynn 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" group.
To post to
On Fri, Jun 29, 2012 at 7:28 PM, Sam Ritchie 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 on Clojure JVM. But
On Fri, 2012-06-29 at 23:56 +0200, Jacek Laskowski wrote:
> They're fine with the job, but they do everything in Java. I thought
> I'd introduce Clojure as a functional language to solve some problems
> that are functional in nature, like processing XML files. I said I'd
> show you how to do it dif
vectors and sorted collections, for sure.
On Fri, Jun 29, 2012 at 4:42 PM, David Nolen wrote:
> On Fri, Jun 29, 2012 at 6:49 PM, Warren Lynn 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?
>
> Davi
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
vect
On Fri, Jun 29, 2012 at 4:50 PM, David Nolen wrote:
> On Fri, Jun 29, 2012 at 7:28 PM, Sam Ritchie 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 b
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
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 implementation for ISeq
> (using
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.
Ca
On Fri, Jun 29, 2012 at 5:17 PM, David Nolen 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
(better-last [s]))
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 languag
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
>
> > wrote:
>
>> As I said, if ISeq and ILast are both protocols that won't work. No
>> protoco
On Fri, Jun 29, 2012 at 4:50 PM, David Nolen 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* sequence operations w
On Fri, Jun 29, 2012 at 8:55 PM, Mark Engelberg wrote:
> 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 it).
>
>
Hmmm, thin
49 matches
Mail list logo
