Re: [ANN] Leiningen 2.0.0-preview7

[Laurent PETIT]

2012/6/28 Phil Hagelberg :
>
> I'm happy to announce the release of Leiningen version 2.0.0-preview7.
>
> This release introduces mirror support as well as the ability to sign
> deployments and verify signatures and changes to credentials.
>
> ## 2.0.0-preview7 / 2012-06-27
>
> * Fix a bug where failed javac wouldn't abort. (Michael Klishin)
> * Check task aliases everywhere tasks are invoked.
> * Sign jars and poms of releases upon deploy by default.
> * Don't decrypt `credentials.clj.gpg` for every request.
> * Support setting `:mirrors` in project.clj. (Chas Emerick, Nelson Morris)
> * Allow aliases shadowing task names to invoke shadowed tasks.
> * Emit `doc/intro.md` in new project templates.
> * Allow `:scm` to be set in project.clj for pom inclusion. (Florian 
> Anderiasch)
> * Fix a bug where dependency `:classifier` and `:extension` would be ignored.
> * Speed up subprocess launches when `:bootclasspath` is set.
> * Set user agent for HTTP requests. (Bruce Adams)
> * Verify signatures of dependencies with `lein deps :verify`.
> * Move task chaining to `do` task in order to allow for higher-order use.
>
> There are two breaking changes in this release.
>
> The first is rearranging the implementation of task chaining so that
> it's just another task. This means that chains can be run inside other
> higher-order tasks. This is done in the `do` task: `lein clean, test,
> deploy` becomes `lein do clean, test, deploy`. It also makes things like
> this possible: `lein with-profile production do check, uberjar`.
> Previously `with-profile` could not apply across task chains. Use of the
> old style will emit a warning explaining the change, so hopefully this
> is straightforward to fix.
>
> Details are at 
> http://groups.google.com/group/leiningen/browse_thread/thread/164a9982eb45e528
>
> The other breaking change is making credential decryption explicit.
> Rather than making the presence of ~/.lein/credentials.clj.gpg cause
> decryption every time, now you must place `:gpg` in the repository
> settings to indicate that the given repository needs to have the
> credentials file decrypted. This allows for a streamlined experience for
> users who do not have a GPG agent configured.
>
> Details are at 
> http://groups.google.com/group/leiningen/browse_thread/thread/1e7e902cc87360da
>
> Launch times may be sped up by adding `:bootclasspath true` to
> project.clj or a profile. This causes the project's JVM to put its
> dependencies on the bootstrap classpath, causing them to skip bytecode
> verification and speeding up boot times considerably. However, there are
> compatibility issues with some libraries, so this is not enabled by
> default.

Hello,

This option may not be really "IDE" friendly. I'll have to find a way
to overwrite the project option in Counterclockwise.

>
> It's my hope that this is the last 2.x preview release and that the next
> release will be 2.0.0 final. However, there are still a few big steps to
> be taken surrounding Clojars[1] for which this preview paves the way.
>
> Thanks,
> Phil
>
> [1] - 
> http://groups.google.com/group/clojars-maintainers/browse_thread/thread/77c1cd77e478bb0f

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

Re: [ANN] C2 v0.2.0: now with cljs data binding

[László Török]

Great, can't wait to try it,

note the http://keminglabs.com/c2/ page still refers to 0.1.0.

2012/6/28 Kevin Lynagh 

> Of course, you may want a link to the library itself:
>
> https://github.com/lynaghk/c2
>
> As always, to use from Clojure/ClojureScript just add this to your
> `project.clj`:
>
> [com.keminglabs/c2 "0.2.0"]
>
>  --
> 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
>



-- 
László Török

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

Re: leinigen 1.7.1 stalled when used from Jenkins

[Pierre Allix]

I found the error.

Somehow it was caused by Jenkins started as standalone JAR by the nohup 
command but nonetheless not properly being "daemonized".

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

Re: How I can convert this python line to clojure?

[tutysara]

Hi,
If you have a variable vtkDataSetAttributes defined and if it contains 
the SCALARS method/field, it can be called using

(.SCALARS vtkDataSetAttributes)



On Monday, June 25, 2012 1:37:47 AM UTC+5:30, Antonio Recio wrote:
>
> The python line that I have rote before is not the one that I want to 
> convert. The correct python line is this, and the result is "0". How I can 
> convert it to clojure?
> print vtkDataSetAttributes.SCALARS
> ;=> 0
>
>

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

Re: ClojureScript instead of CoffeeScript for complete web app development?

[Christian M.]

I have developed a tiny web app in Clojure/ClojureScript and have written 
an overview here . In 
general, it was an exciting experience, but I also faced several problems 
with ClojureScript. For example, if you compile your code to JS, then the 
output file (in contrast to CoffeeScript) will contain other code (~18kb or 
so): this code contains the Google Closure libraries, which do a lot of 
stuff, like accessing the DOM elements. However, I found it *much* easier 
to use jQuery (through the jayq library written in ClojureScript). Hence, 
in my case, a lot of this additional code will be loaded for nothing. And 
the first-time load times are not negligible!

Furthermore, I did experience some performance problems with ClojureScript, 
which I didn't investigate further, so I'm not sure, that these problems 
hold in general. I did some per-character computations on a very large text 
and it took just too long for such a primitive operation. Since my code was 
quite high-level I assumed, that the GC of JS engine was choked.

Now to your questions

1. I suppose you can't call any Java library from ClojureScript if you want 
> it to compile to JS. Can you call any Clojure library and have it 
> translated?
>

This is right, what is supported in ClojureScript is _almost_ everything 
what is supported in _native_ Clojure only, so don't expect things like 
Integer/parseInt or all String methods to work in JS!
 

> 2. If I'd create a DSL with Clojure, could it be deployed to JS through 
> ClojureScript also?
>

If you manage to keep it platform-independent, then of course. However, 
even if you'll need some platform-specific calls, you can abstract them: I 
had a similar problem with my web app (the problem is described in my 
overview ) when I needed 
a simple hash function, which would work on the client and on the server. 
The problem is that you run into the platform much faster, than you assume: 
JS (and therefore ClojureScript) has no chars, it doesn't produce 
overflows, the entire String API is different and so on. What I did, I just 
implemented my code with dependency injections in form of higher order 
functions injected as arguments. Such code can be run on the client and on 
the server with different platform-specific parameter. This was fun.
 

> 3. One of my main concerns ...
>

I can't give more insightful answers as already given.

I know the tooling is raw at the moment and that it'll get better overtime, 
> so I'm asking more about the fundamental problems that are hardly going to 
> be solved in the near time.
>

I think the only problem (if it is a problem at all), which won't be solved 
soon is ClojureScript's performance resulting from creating a lot of 
implicit objects in very high level computations. Something like (filter 
(map (reduce ... ... (map ... can't be as fast and as memory-efficient 
for loops and in-place array operations of JS. In theory, the same holds 
for Clojure and Java as well, however, in contrast to ClojureScript, I 
never faced this problem on JVM yet.

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

[ANN] table - Display ascii tables for almost any data structure with ease

[Gabriel Horner]

Hi Clojuristas,

I'm announcing my first clojar - table, https://github.com/cldwalker/table.

table handles rendering combinations of maps, vecs, lists and sets
nested in one another as ascii tables. Four ascii table styles exist
and more welcome: plain, org, unicode and github markdown. See the
readme, https://github.com/cldwalker/table#readme, for examples of
each as they look horrible when copied into this email.

table is more featureful than clojure.pprint/print-table and has a
different emphasis than doric.

Any feedback - technical, cultural or whatever is much appreciated.

Thanks,
Gabriel

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

Re: [ANN] lib-noir 0.1.1

[Ryan McGowan]

I just wanted to say that this seems like a great idea.

+1

On Saturday, June 23, 2012 11:08:47 PM UTC-7, Anthony Grimes wrote:
>
> Chris Granger and I decided that a lot of the stuff in Noir is also useful 
> outside of Noir, so I took a bunch of Noir's middleware and such and split 
> it out into a
> new library called lib-noir. You can find it here:
>
> https://github.com/noir-clojure/lib-noir
>
> It has Noir's stateful session/flash middleware, cookie middleware, 
> validation middleware, encryption utilities, and my personal favorite, some 
> utilities for
> creating ring response maps (higher level than ring.util.response).
>
> All of these things are completely independent of Noir. They are can be 
> used from any ring-based web framework, and my motivation for doing it was 
> actually
> so I could use stateful sessions and the response utils in Compojure apps. 
> These things will be maintained completely separately from noir from now on.
>
> The stateful session and flash stuff works mostly the same as sandbar's 
> does, but sandbar tends to stay a little out of date, so hopefully this 
> will make for
> a great alternative for people having issues with it.
>
> We hope you enjoy these things!
>
> ( First announcement on the Noir group: 
> https://groups.google.com/d/topic/clj-noir/0BkySc8gG90/discussion )
>

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

Bug in passing closured fns to eval

[myk]

Hi - I'm pretty sure I've found a bug in the way eval (Clojure 1.4) deals 
with fns that have closures (in that it doesn't).

I've posted my examples on stack overflow, so I won't reproduce them here:
http://stackoverflow.com/questions/11191992/functions-with-closures-and-eval-in-clojure/11202589#11202589
 

I'm not sure of the usual procedure for things like this so I figured I'd 
just let you guys know and see what you think.

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

Re: Anyone using Sublime Text 2 + SumblimeREPL with Windows?

[Wojciech Bederski]

Hi Jacobo, 

sorry for responding so late. Usually I try to keep an eye on SublimeREPL 
Google Alerts and forums, but I've been buried with paperwork for the past 
several weeks (and there is no end in sight). 

Regarding text transfer shortcuts. Please move them to  Preferences -> Key 
Bindings - User. This way when a new version of SublimeREPL is released, 
updated sources won't overwrite your changes.  
 
>
> Do you know of any way to force to open a new REPL everytime we fire up 
> Sublime?
>

You can create a keybinding that will make it super easy.

{"keys": ["ctrl+f9"], "command": "run_existing_window_command", "args": 
{"id": "repl_clojure", "file": "config/Clojure/Main.sublime-menu"}}
 
Or a simple plugin:
1) Tools -> New Plugin
2) Paste this

import sublime, sublime_plugin
def run():
sublime.active_window().run_command("run_existing_window_command", {"id": 
"repl_clojure", "file": "config/Clojure/Main.sublime-menu"})

sublime.set_timeout(run, 2000)

3) Save as clojurerepl_autostart.py in your "User" directory.

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

Re: General subsequence function

[Timothy Baldridge]

> I like Lisp in general but it frustrated me (before also with Common Lisp)
> that it seems Lispers often claim the language can help you fly higher while
> in reality it actually makes your walking more difficult. Even it can help
> you fly higher, that will still turn off many people because we walk much
> more than fly. And there is no REAL reason that you need to walk slower when
> trying to fly higher. All those nuances are self imposed without any true
> substantial reason.

Can you provide an example of this subseqx function in a different
language? The sequence abstraction is not unique to Clojure. C# has
the IEnumerable abstraction, and Python has iterators. All of these
will cause the same problems you are expressing of changing the type.
That is, doing .Where(x => x == 1) on a List in C# will return a
IEnumerable at that point you haven't a clue what the concrete
type was originally.

To better explain my point, let's look at contains? Many people
(including myself) get confused about contains?. For instance:

=> (contains? [1 2 3] 1)
true
=> (contains? [2 3 4] 4)
false

What's going on here? Well contains is a key based look-up. [1 2 3]
has a 1st element so the that is true, but [2 3 4] does not have a 4th
element, so our second form evaluates to false. So what contains?
actually does is say "perform a constant-time lookup on the collection
to see if key exists". Since searching [2 3 4] for the number 4 is not
constant time, that is not the algorithm that is implemented.

Okay, so back to subseqx. The problem is that you are asking  for a
mixture of semantics. Is subseqx a constant time operation? On a
vector, yes. On a seq, no.

This is where the simplicity Clojure attempts to employ comes into
play. Don't write a function that sometimes takes O(1) and other times
takes O(log32) or O(n).

This also comes into play with the function conj. People mistakenly
think conj means "add this element to the end" or "add this element,
but do it differently depending on the collection". Instead what conj
really means is "add in the most efficient way possible". For lists
conj would then be like cons. For vectors conj adds on the end. For
maps, conj is the same as assoc (more or less).

So there you have it. Simplicity here is defined as stating that a
given function will always take the same time to perform the same
action, and that will not employ a bunch of if/then magic.

To answer your question then, since we are using different semantics
for each collection you should use:

drop/take - for seqs and lists
subvec - for vectors
select-keys - for maps

Hopefully this helps clear it up a bit.

Timothy

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

Printing non-serializable data that can be read back in

[Jeff Weiss]

I am using clojure for functional testing ('functional' as opposed to unit 
testing, I don't mean in the FP sense).

My tests write a clojure-formatted file containing all the test results. 
 Each result may include:

1) The code of the test
2) Parameters of a data-driven test
3) Trace of a failed test

The problem I'm having is when I go to analyze the results, I cannot simply 
call read on the file, because it's full of 
non-serializable #< ... > values, and also #'s and "..."s for print-level 
and print-length being exceeded.  Usually those are nested deep in the 
parameters or the trace.

In every case, I don't *need* the missing data, it doesn't need to be truly 
serializable.  An informative placeholder would do fine.  I'm not doing 
computations on the trace, I just like it to be there so I can read it 
myself to see what what happening.

So how do I solve this?  I know I can replace the defmethod print-method 
for java.lang.Object to just print a readable string.  That would solve the 
#< ... >.  What about the #'s from the nesting level being exceeded?  Or 
"..." from print-length being exceeded?  (I cannot turn off the limits for 
print-length, since I trace functions that return infinite seq's).

Or should I approach it from the other direction, and modify the reader to 
accept this input somehow?  And I suppose on another level I should ask, 
why isn't a readable placeholder the default behavior?

Any suggestions appreciated, 

Jeff






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

Re: Bug in passing closured fns to eval

[Tassilo Horn]

myk  writes:

Hi!

> Hi - I'm pretty sure I've found a bug in the way eval (Clojure 1.4)
> deals with fns that have closures (in that it doesn't).
>
> I've posted my examples on stack overflow, so I won't reproduce them here:
> http://stackoverflow.com/questions/11191992/functions-with-closures-and-eval-in-clojure/11202589#11202589
>
> I'm not sure of the usual procedure for things like this so I figured
> I'd just let you guys know and see what you think.

As the guys on stackoverflow already said, if think you need to use
`eval` it is highly likely you are doing it wrong.  That said, the last
answer on stackoverflow seems to be correct.

For example, when compiling classes for this code

(ns testi.core)

(let [noclo (fn [] "foo")
  s "foo"
  clo (fn [] s)]
  [(noclo) (clo)])

and disassembling them, you get:

public final class testi.core$fn__2145$noclo__2146 extends 
clojure.lang.AFunction {
  public static {};
  public testi.core$fn__2145$noclo__2146();
  public java.lang.Object invoke();
}

and

public final class testi.core$fn__2145$clo__2148 extends clojure.lang.AFunction 
{
  java.lang.Object s;
  public static {};
  public testi.core$fn__2145$clo__2148(java.lang.Object);
  public java.lang.Object invoke();
}

So the function closing over s above has one additional constructor
parameter, where the closed over value of s comes in to be set to the s
field of the object.

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

Re: [ANN] C2 v0.2.0: now with cljs data binding

[Kevin Lynagh]

Thanks Las, the page is now updated with the latest version and additional 
description.

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

Re: General subsequence function

[Warren Lynn]

Some of my thoughts:

1. The argument that other languages do not have a similar thing is not 
valid. If that is valid, we don't need Clojure in the first place.

2. The argument that other people did not raise the issue before and not 
enough people support it so this is a non-issue is also not valid. If that 
is valid, the vote-based committee designed language will be the best, and 
also the most popular language will be the best. Of course, I do need 
people's support so the change will happen, but that is different from the 
issue itself.

3. Simplicity is defined as "constant time" operation is really weird  here 
to me. Simplicity in my view is a clear abstraction so conceptually things 
behavior consistently, regardless the time. The user himself knows that 
counting a sequence will take longer than vector, so it is his choice to 
use vector of sequence. But counting is still counting, and he does not 
need to have to choose between"countvec" or "countseq". That is what 
abstraction is about.

4. Back to my original need. I need to use vector a lot because I deal with 
large data set for numeric processing. When I extract a segment from the 
vector, I still want it to be a vector. Of course it is doable even now 
(with "vec" you can convert a sequence back to vector). But when I am 
writing some basic routines, I don't want to limit them to vector as they 
may be useful for sequence too. Still, I can write separate versions or 
with a lot of conditions as someone else did. But are we trying to achieve 
something better than doable here?

5. The solution is really simple. Add one or two functions as I suggested 
before. I don't see any downside of that.

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

Re: General subsequence function

[Warren Lynn]

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)

As simple as that. Is that even worth the debate? :-)

On Thursday, June 28, 2012 11:30:25 AM UTC-4, Warren Lynn wrote:
>
> Some of my thoughts:
>
> 1. The argument that other languages do not have a similar thing is not 
> valid. If that is valid, we don't need Clojure in the first place.
>
> 2. The argument that other people did not raise the issue before and not 
> enough people support it so this is a non-issue is also not valid. If that 
> is valid, the vote-based committee designed language will be the best, and 
> also the most popular language will be the best. Of course, I do need 
> people's support so the change will happen, but that is different from the 
> issue itself.
>
> 3. Simplicity is defined as "constant time" operation is really weird  
> here to me. Simplicity in my view is a clear abstraction so conceptually 
> things behavior consistently, regardless the time. The user himself knows 
> that counting a sequence will take longer than vector, so it is his choice 
> to use vector of sequence. But counting is still counting, and he does not 
> need to have to choose between"countvec" or "countseq". That is what 
> abstraction is about.
>
> 4. Back to my original need. I need to use vector a lot because I deal 
> with large data set for numeric processing. When I extract a segment from 
> the vector, I still want it to be a vector. Of course it is doable even now 
> (with "vec" you can convert a sequence back to vector). But when I am 
> writing some basic routines, I don't want to limit them to vector as they 
> may be useful for sequence too. Still, I can write separate versions or 
> with a lot of conditions as someone else did. But are we trying to achieve 
> something better than doable here?
>
> 5. The solution is really simple. Add one or two functions as I suggested 
> before. I don't see any downside of that.
>
>

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

Re: General subsequence function

[Tassilo Horn]

Warren Lynn  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

Re: General subsequence function

[Andy Fingerhut]

>From quick & easy, to slower & more difficult, here are some options:

Use the functions you want in your own code, and find happiness in the fact 
that they are quick & easy to write.

Make a library of this and perhaps other related functions on github.  Perhaps 
also release JARs to clojars.org for other people to use.  Post announcements 
of new versions to this list so more people learn about it.

Add the functions you want to a Clojure contrib library.  I don't know off-hand 
one that would be best for it, but perhaps creating a new one based off of the 
things that were in the "old" clojure.contrib.seq, perhaps with a name like 
clojure.contrib.seq, would be appropriate.

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 this thread, it might be 
rejected.   http://clojure.org/patches has links to more info on the process.

And, of course there is the option of trying to convince other people to do one 
of the above.  That can be anywhere on the scale of amazingly quick & easy, to 
incredibly frustrating & hard, depending upon your ideas, how persuasive you 
are, and who reads your arguments.

Andy
 
On Jun 28, 2012, at 10:55 AM, 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)
> 
> As simple as that. Is that even worth the debate? :-)
> 
> On Thursday, June 28, 2012 11:30:25 AM UTC-4, Warren Lynn wrote:
> Some of my thoughts:
> 
> 1. The argument that other languages do not have a similar thing is not 
> valid. If that is valid, we don't need Clojure in the first place.
> 
> 2. The argument that other people did not raise the issue before and not 
> enough people support it so this is a non-issue is also not valid. If that is 
> valid, the vote-based committee designed language will be the best, and also 
> the most popular language will be the best. Of course, I do need people's 
> support so the change will happen, but that is different from the issue 
> itself.
> 
> 3. Simplicity is defined as "constant time" operation is really weird  here 
> to me. Simplicity in my view is a clear abstraction so conceptually things 
> behavior consistently, regardless the time. The user himself knows that 
> counting a sequence will take longer than vector, so it is his choice to use 
> vector of sequence. But counting is still counting, and he does not need to 
> have to choose between"countvec" or "countseq". That is what abstraction is 
> about.
> 
> 4. Back to my original need. I need to use vector a lot because I deal with 
> large data set for numeric processing. When I extract a segment from the 
> vector, I still want it to be a vector. Of course it is doable even now (with 
> "vec" you can convert a sequence back to vector). But when I am writing some 
> basic routines, I don't want to limit them to vector as they may be useful 
> for sequence too. Still, I can write separate versions or with a lot of 
> conditions as someone else did. But are we trying to achieve something better 
> than doable here?
> 
> 5. The solution is really simple. Add one or two functions as I suggested 
> before. I don't see any downside of that.
> 


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

Re: General subsequence function

[Warren Lynn]

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

Re: General subsequence function

[Warren Lynn]

Andy:

Thanks for laying out the options to move it forward. I think those 
functions belong to clojure.core, but I will see how persuasive I am, or 
how receptive the community is. :-)

On Thursday, June 28, 2012 2:53:27 PM UTC-4, Andy Fingerhut wrote:
>
> From quick & easy, to slower & more difficult, here are some options:
>
> Use the functions you want in your own code, and find happiness in the 
> fact that they are quick & easy to write.
>
> Make a library of this and perhaps other related functions on github. 
>  Perhaps also release JARs to clojars.org for other people to use.  Post 
> announcements of new versions to this list so more people learn about it.
>
> Add the functions you want to a Clojure contrib library.  I don't know 
> off-hand one that would be best for it, but perhaps creating a new one 
> based off of the things that were in the "old" clojure.contrib.seq, perhaps 
> with a name like clojure.contrib.seq, would be appropriate.
>
> 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 this thread, 
> it might be rejected.   http://clojure.org/patches has links to more info 
> on the process.
>
> And, of course there is the option of trying to convince other people to 
> do one of the above.  That can be anywhere on the scale of amazingly quick 
> & easy, to incredibly frustrating & hard, depending upon your ideas, how 
> persuasive you are, and who reads your arguments.
>
> Andy
>  
> On Jun 28, 2012, at 10:55 AM, 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)
>
> As simple as that. Is that even worth the debate? :-)
>
> On Thursday, June 28, 2012 11:30:25 AM UTC-4, Warren Lynn wrote:
>>
>> Some of my thoughts:
>>
>> 1. The argument that other languages do not have a similar thing is not 
>> valid. If that is valid, we don't need Clojure in the first place.
>>
>> 2. The argument that other people did not raise the issue before and not 
>> enough people support it so this is a non-issue is also not valid. If that 
>> is valid, the vote-based committee designed language will be the best, and 
>> also the most popular language will be the best. Of course, I do need 
>> people's support so the change will happen, but that is different from the 
>> issue itself.
>>
>> 3. Simplicity is defined as "constant time" operation is really weird  
>> here to me. Simplicity in my view is a clear abstraction so conceptually 
>> things behavior consistently, regardless the time. The user himself knows 
>> that counting a sequence will take longer than vector, so it is his choice 
>> to use vector of sequence. But counting is still counting, and he does not 
>> need to have to choose between"countvec" or "countseq". That is what 
>> abstraction is about.
>>
>> 4. Back to my original need. I need to use vector a lot because I deal 
>> with large data set for numeric processing. When I extract a segment from 
>> the vector, I still want it to be a vector. Of course it is doable even now 
>> (with "vec" you can convert a sequence back to vector). But when I am 
>> writing some basic routines, I don't want to limit them to vector as they 
>> may be useful for sequence too. Still, I can write separate versions or 
>> with a lot of conditions as someone else did. But are we trying to achieve 
>> something better than doable here?
>>
>> 5. The solution is really simple. Add one or two functions as I suggested 
>> before. I don't see any downside of that.
>>
>>
>
>

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

Re: ClojureScript instead of CoffeeScript for complete web app development?

[David Nolen]

On Mon, Jun 25, 2012 at 12:31 AM, Christian M.  wrote:

> I have developed a tiny web app in Clojure/ClojureScript and have written
> an overview here . In
> general, it was an exciting experience, but I also faced several problems
> with ClojureScript. For example, if you compile your code to JS, then the
> output file (in contrast to CoffeeScript) will contain other code (~18kb or
> so): this code contains the Google Closure libraries, which do a lot of
> stuff, like accessing the DOM elements.


The bulk of the "other" code is the CLJS standard lib. We currently only
use a few things from GClosure (string, object, array, etc), nothing
involving the DOM.


> Furthermore, I did experience some performance problems with
> ClojureScript, which I didn't investigate further, so I'm not sure, that
> these problems hold in general. I did some per-character computations on a
> very large text and it took just too long for such a primitive operation.
> Since my code was quite high-level I assumed, that the GC of JS engine was
> choked.
>

If you want fast string manipulating, writing very high-level code isn't
going to work. Same for hand written JavaScript.


> I think the only problem (if it is a problem at all), which won't be
> solved soon is ClojureScript's performance resulting from creating a lot of
> implicit objects in very high level computations. Something like (filter
> (map (reduce ... ... (map ... can't be as fast and as memory-efficient
> for loops and in-place array operations of JS. In theory, the same holds
> for Clojure and Java as well, however, in contrast to ClojureScript, I
> never faced this problem on JVM yet.
>

There's lots of room for improving the performance of the high level
operations. That said generating fast JS from CLJS is a goal - otherwise
the data structure benchmarks would not look as good as they currently do.

I admit as with Clojure on JVM - it's not obvious how to write fast code -
even though it's not difficult. A guide on how to write fast code for
critical parts of CLJS application needs to be written up by someone.

David

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

Re: General subsequence function

[Meikel Brandmeyer]

Hi,

Am 28.06.2012 um 20:52 schrieb Tassilo Horn:

> And yes, there are some counter examples like `count` and `last`...

last is not a counterexample. last is a sequence function, which acts on seqs. 
It just calls seq on its argument so you may pass in a vector (or anything 
seqable). The vector equivalent of last is peek, btw.

nth is better example, since it's fast on vectors and O(n) on seqs and lists. 
Just like count.

Kind regards
Meikel

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

Re: General subsequence function

[Tassilo Horn]

Meikel Brandmeyer  writes:

Hi Meikel,

>> And yes, there are some counter examples like `count` and `last`...
>
> last is not a counterexample. last is a sequence function, which acts
> on seqs. It just calls seq on its argument so you may pass in a vector
> (or anything seqable). The vector equivalent of last is peek, btw.

Yes, exactly.  If you need to access the last element, you'd be better
off with a vector, so IMHO there's no reason for `last` to exist (except
for backwards compatibility maybe).

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

Re: General subsequence function

[David Nolen]

On Thu, Jun 28, 2012 at 4:28 PM, Meikel Brandmeyer  wrote:

> Hi,
>
> Am 28.06.2012 um 20:52 schrieb Tassilo Horn:
>
> > And yes, there are some counter examples like `count` and `last`...
>
> last is not a counterexample. last is a sequence function, which acts on
> seqs. It just calls seq on its argument so you may pass in a vector (or
> anything seqable). The vector equivalent of last is peek, btw.
>

Well, peek is a collection operation. IPersistentStack on the JVM & simply
IStack in ClojureScript.

I think nth & count are really the only exceptions - collection operations
that happen to work on seqs. It's quite clear in the ClojureScript source.

David

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

Re: General subsequence function

[David Nolen]

It's a sequence operation and plenty useful.

On Thu, Jun 28, 2012 at 4:56 PM, Tassilo Horn wrote:

> Meikel Brandmeyer  writes:
>
> Hi Meikel,
>
> >> And yes, there are some counter examples like `count` and `last`...
> >
> > last is not a counterexample. last is a sequence function, which acts
> > on seqs. It just calls seq on its argument so you may pass in a vector
> > (or anything seqable). The vector equivalent of last is peek, btw.
>
> Yes, exactly.  If you need to access the last element, you'd be better
> off with a vector, so IMHO there's no reason for `last` to exist (except
> for backwards compatibility maybe).
>
> 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
>

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

Re: General subsequence function

[Warren Lynn]

Is there any reason why "last" needs to be slow on vectors? Can it just do 
the right thing and be fast on it?

On Thursday, June 28, 2012 4:28:30 PM UTC-4, Meikel Brandmeyer (kotarak) 
wrote:
>
> Hi, 
>
> Am 28.06.2012 um 20:52 schrieb Tassilo Horn: 
>
> > And yes, there are some counter examples like `count` and `last`... 
>
> last is not a counterexample. last is a sequence function, which acts on 
> seqs. It just calls seq on its argument so you may pass in a vector (or 
> anything seqable). The vector equivalent of last is peek, btw. 
>
> nth is better example, since it's fast on vectors and O(n) on seqs and 
> lists. Just like count. 
>
> Kind regards 
> Meikel 
>
>

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

Re: ClojureScript instead of CoffeeScript for complete web app development?

[Ben Mabey]

On 6/24/12 10:31 PM, Christian M. wrote:
I think the only problem (if it is a problem at all), which won't be 
solved soon is ClojureScript's performance resulting from creating a 
lot of implicit objects in very high level computations. Something 
like (filter (map (reduce ... ... (map ... can't be as fast and as 
memory-efficient for loops and in-place array operations of JS. In 
theory, the same holds for Clojure and Java as well, however, in 
contrast to ClojureScript, I never faced this problem on JVM yet.




Does the new reducers library[1] work in ClojureScript?  One of its 
advantages is that it avoids the per-step allocation overhead that you 
are mentioning with the chain of filters/maps/reduce calls.


-Ben


1. 
http://clojure.com/blog/2012/05/08/reducers-a-library-and-model-for-collection-processing.html


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

Re: ClojureScript instead of CoffeeScript for complete web app development?

[David Nolen]

reducers are already available - though further perf work needs to be done
to really deliver on the performance promises. Even so I wouldn't be
surprised if they already outperform many chained sequence operations.

David

On Thu, Jun 28, 2012 at 5:45 PM, Ben Mabey  wrote:

> On 6/24/12 10:31 PM, Christian M. wrote:
>
>> I think the only problem (if it is a problem at all), which won't be
>> solved soon is ClojureScript's performance resulting from creating a lot of
>> implicit objects in very high level computations. Something like (filter
>> (map (reduce ... ... (map ... can't be as fast and as memory-efficient
>> for loops and in-place array operations of JS. In theory, the same holds
>> for Clojure and Java as well, however, in contrast to ClojureScript, I
>> never faced this problem on JVM yet.
>>
>>
> Does the new reducers library[1] work in ClojureScript?  One of its
> advantages is that it avoids the per-step allocation overhead that you are
> mentioning with the chain of filters/maps/reduce calls.
>
> -Ben
>
>
> 1. http://clojure.com/blog/2012/**05/08/reducers-a-library-and-**
> model-for-collection-**processing.html
>
>
> --
> 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+unsubscribe@**googlegroups.com
> For more options, visit this group at
> http://groups.google.com/**group/clojure?hl=en
>

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

Why cannot "last" be fast on vector?

[Warren Lynn]

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:

user> (source last)
(def 
 ^{:arglists '([coll])
   :doc "Return the last item in coll, in linear time"
   :added "1.0"
   :static true}
 last (fn ^:static last [s]
(if (next s)
  (recur (next s))
  (first s

Any reason for that? Thanks.

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

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

[David Nolen]

On Thu, Jun 28, 2012 at 7:32 PM, Warren Lynn  wrote:

> 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:
>
> user> (source last)
> (def
>  ^{:arglists '([coll])
>:doc "Return the last item in coll, in linear time"
>:added "1.0"
>:static true}
>  last (fn ^:static last [s]
> (if (next s)
>   (recur (next s))
>   (first s
>
> Any reason for that? Thanks.


Don't hold your breath. Assume that the language was designed after much
consideration. last is a sequence operation, not a collection operation. If
the distinction doesn't make sense, I suggest you explore the design
decision by writing some non-trivial Clojure code so you can arrive at your
own satisfying answer why this was done. Otherwise you'll just listen to
people repeat the same answer without hearing what is being said.

David

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

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

[Tamreen Khan]

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 beginning to the end, which is exactly what the last
function does.

On Thu, Jun 28, 2012 at 7:36 PM, David Nolen  wrote:

> On Thu, Jun 28, 2012 at 7:32 PM, Warren Lynn  wrote:
>
>> 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:
>>
>> user> (source last)
>> (def
>>  ^{:arglists '([coll])
>>:doc "Return the last item in coll, in linear time"
>>:added "1.0"
>>:static true}
>>  last (fn ^:static last [s]
>> (if (next s)
>>   (recur (next s))
>>   (first s
>>
>> Any reason for that? Thanks.
>
>
> Don't hold your breath. Assume that the language was designed after much
> consideration. last is a sequence operation, not a collection operation. If
> the distinction doesn't make sense, I suggest you explore the design
> decision by writing some non-trivial Clojure code so you can arrive at your
> own satisfying answer why this was done. Otherwise you'll just listen to
> people repeat the same answer without hearing what is being said.
>
> David
>
> --
> 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
>

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

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

[Mark Engelberg]

On Thu, Jun 28, 2012 at 6:59 PM, Tamreen Khan  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 random access, whereas lists are optimized for
> going through from the beginning to the end, which is exactly what the last
> function does.
>
>
>
This doesn't really address the underlying question.

nth is a good example of a function that is fast for vectors, strings, and
arrays, and only for lists uses the slower sequential implementation.

There's no technical reason that last couldn't do the same, dispatching on
the underlying type to have a more efficient implementation for data types
that support it.

The real reason is this: With the glaring exception of nth, Clojure tends
to eschew functions with a fast path and a slow path, because programmers
shouldn't have to do deep semantic analysis of their code to figure out
which will get chosen.  In this case, however, we're talking about a
function that is currently always slow.  Surely it would be a win to make
it have a faster path in a large number of cases, right?  Well, the
argument against that is eventually people would start to rely on it being
fast for so many collection types, and then get burned when somehow their
collection accidentally gets turned into a seq before last is called on
it.  The theory is that it's better to force people to use a different
function call, namely peek, to retrieve the last element quickly from a
vector.

Honestly though, despite David Nolen's claim that this design decision will
be obvious if you've coded enough Clojure, I've been programming in it for
around 3-1/2 years, and I think the argument behind this design decision is
a relatively weak one, so you are not making an unreasonable request.  In
fact, the more I code in Clojure, the more I see that there are a number of
core functions that require significant semantic analysis of the
surrounding context to know how they will behave.  Either Clojure trusts
that programmers can make determinations about the types of their
collections or it doesn't.  Which is it?  Well, I'd argue there's a large
body of evidence that under Clojure's current design, it's clear that you
better know what you're doing.  If that's the case, why not go ahead and
make last fast when it can be fast?

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.

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

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

[Timothy Baldridge]

> 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 language is opensource, you have namespaces, so
feel free to make a namespace called mycore, that includes all you
special versions of functions that you need, and then use that library
for your projects. It doesn't take very long to define these special
case functions and if they work for you, then just use them. 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))

Does this function exist in clojure.core...not that I saw off-hand.
Does it really matter though? Not really. I'll copy and paste these
functions when I need them and go happily on my way. One of the
biggest strengths of functional programming is that we can build up
snippets of functions like this, and when we use then in our programs
we can't tell that they weren't included by default.

As Gerald Sussman said at the last Strange Loop conference: be a
Libertarian when it comes to programming. Don't restrict others to
your view of programming, liberty to you and to me and to everyone.
You can code in your style, I'll code in mine, and Clojure (or Lisp in
the case of the quote), shouldn't constrain me to its view of the
world.

Timothy

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

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

[David Nolen]

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 
> 
> > 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 random access, whereas lists are optimized for
>> going through from the beginning to the end, which is exactly what the last
>> function does.
>>
>>
>>
> This doesn't really address the underlying question.
>
> nth is a good example of a function that is fast for vectors, strings, and
> arrays, and only for lists uses the slower sequential implementation.
>
> There's no technical reason that last couldn't do the same, dispatching on
> the underlying type to have a more efficient implementation for data types
> that support it.
>
> The real reason is this: With the glaring exception of nth, Clojure tends
> to eschew functions with a fast path and a slow path, because programmers
> shouldn't have to do deep semantic analysis of their code to figure out
> which will get chosen.  In this case, however, we're talking about a
> function that is currently always slow.  Surely it would be a win to make
> it have a faster path in a large number of cases, right?  Well, the
> argument against that is eventually people would start to rely on it being
> fast for so many collection types, and then get burned when somehow their
> collection accidentally gets turned into a seq before last is called on
> it.  The theory is that it's better to force people to use a different
> function call, namely peek, to retrieve the last element quickly from a
> vector.
>
> Honestly though, despite David Nolen's claim that this design decision
> will be obvious if you've coded enough Clojure, I've been programming in it
> for around 3-1/2 years, and I think the argument behind this design
> decision is a relatively weak one, so you are not making an unreasonable
> request.  In fact, the more I code in Clojure, the more I see that there
> are a number of core functions that require significant semantic analysis
> of the surrounding context to know how they will behave.  Either Clojure
> trusts that programmers can make determinations about the types of their
> collections or it doesn't.  Which is it?  Well, I'd argue there's a large
> body of evidence that under Clojure's current design, it's clear that you
> better know what you're doing.  If that's the case, why not go ahead and
> make last fast when it can be fast?
>
> 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.
>
> --
> 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 '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  'clojure%2bunsubscr...@googlegroups.com');>
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

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

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

[Meikel Brandmeyer (kotarak)]

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