Re: Can the data in a vector have data inside it that points to the same vector? vector1=[a b c d] a=[1 2 f s vector1]

[Gary Verhaegen]

Basically, since vectors are immutable, you cannot easily construct that
kind of recursive structure. Any means of breaking immutability would allow
it, though (atoms, promises, undocumented mutable apis, mutable objects
inside the vector, etc.).

To clarify: the vector itself does not explicitly prevent that, but the
fact that a vector is immutable once created means that you cannot put it
into itself, since you don't have it before you create it and you cannot
add anything to it once it is created. That holds for any kind of immutable
(and eager) data structure.

On Wednesday, 10 February 2016, James Reeves  wrote:

> No, vectors can't be recursive. However you can use a reference of some
> description, e.g.
>
>(let [p (promise), v [p]]
>  (deliver p v)
>  v))
>
> You could also use a lazy seq.
>
> - James
>
> On 10 February 2016 at 04:29, Timothy Vinick  > wrote:
>
>> Here's an example:
>>
>>  vector1=[a b c d] a=[1 2 f s vector1]
>>
>> --
>> 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 unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> 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 unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Can the data in a vector have data inside it that points to the same vector? vector1=[a b c d] a=[1 2 f s vector1]

[James Reeves]

No, vectors can't be recursive. However you can use a reference of some
description, e.g.

   (let [p (promise), v [p]]
 (deliver p v)
 v))

You could also use a lazy seq.

- James

On 10 February 2016 at 04:29, Timothy Vinick  wrote:

> Here's an example:
>
>  vector1=[a b c d] a=[1 2 f s vector1]
>
> --
> 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 unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Can the data in a vector have data inside it that points to the same vector? vector1=[a b c d] a=[1 2 f s vector1]

[Timothy Vinick]

Here's an example:

 vector1=[a b c d] a=[1 2 f s vector1]

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Library updates (Redis & DynamoDB clients, logging+profiling, i18n+L10n, serialization, A/B testing)

[Peter Taoussanis]

Have had one or two people ask me about this - all libraries are under the EPL 
v1.0 , the same license as 
Clojure itself. Cheers! - Peter

-- 
-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[ANN] Library updates (Redis & DynamoDB clients, logging+profiling, i18n+L10n, serialization, A/B testing)

[Peter Taoussanis]

Hi folks, just a quick update on some libraries - figure I'll do this and 
future updates in batches to keep from spamming the group. Hoping the 
formatting comes through here...

*Carmine* - Redis client & message queue 
(GitHub<https://github.com/ptaoussanis/carmine>
)
Current version: *1.9.1*
Clojure dependency: 1.4+
Recent changes: message queue features, distributed locks, performance 
improvements.
Thanks to Ronen (narkisr) for most of the new features.

*Faraday* - DynamoDB client (GitHub <https://github.com/ptaoussanis/faraday>) 
- NEW LIBRARY
Current version: *0.5.0*
Clojure dependency: 1.5+
Recent changes: full DynamoDB v2 API coverage.
Thanks to James Reaves whose library (Rotary) provided the basis for 
Faraday.

*Nippy* - serialization library (GitHub<https://github.com/ptaoussanis/nippy>
)
Current version: *1.2.1*
Clojure dependency: 1.3+
Recent changes: sorted set+map support, performance improvements.

*Timbre* - logging & profiling library 
(GitHub<https://github.com/ptaoussanis/timbre>
)
Current version: *2.0.0 *- MAJOR RELEASE
Clojure dependency: 1.4+
Recent changes: tools.logging support.

*Touchstone* - A/B testing library 
(GitHub<https://github.com/ptaoussanis/touchstone>
)
Current version: *1.0.0* - MAJOR RELEASE
Clojure dependency: 1.4+
Recent changes: inherited test-config support, marked API as stable.

*Tower* - i18n & L10n library (GitHub <https://github.com/ptaoussanis/tower>
)
Current version: *1.7.0*
Clojure dependency: 1.4+
Recent changes: Nothing major.


I've started to push new releases (like Faraday) to Clojure 1.5+ but will 
maintain backwards-compatibility with 1.4+ where possible. Nippy is an 
exception which I'll keep at Clojure 1.3+  for at least 
the foreseeable future.

For those interested I've now setup a page at 
https://www.taoensso.com/clojure-libraries to keep track of the libraries 
I'm currently maintaining. In any event, will update the group from time to 
time when there's a bunch of significant changes queued like today.

As always, am very happy to take ideas/comments/PRs/whatever - a lot of the 
recent improvements above were a result of direct/indirect input from other 
folks (thank you!).

Have an awesome Monday, cheers!

- Peter Taoussanis (taoensso.com <https://www.taoensso.com>)

-- 
-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: (#({:a %}) :b)

[Michael Fogus]

The limitation was only on ->> but I think that is due for a fix in
the next version.


On Thu, Dec 13, 2012 at 5:48 PM, JvJ  wrote:
> Clever, but I always thought -> had to take more than one parameter.  Maybe
> that's only for ->>
>
>
> On Thursday, 13 December 2012 13:35:33 UTC-5, Gary Verhaegen wrote:
>>
>> I've found this gem in The Joy of Clojure :
>>
>> #(-> [%])
>>
>> which would work similarly for any literal, I guess : #(-> {:a %}) in
>> this case. Much nicer than identity, IMHO.
>>
>> On 4 June 2012 15:28, Steven Obua  wrote:
>> > Jay's example has convinced me that redefinition is not a good idea
>> > anyway,
>> > because #(f) is not always equivalent to f when (count [f]) is 1.
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "Clojure" group.
>> > To post to this group, send email to clo...@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+u...@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



-- 
-- http://blog.fogus.me
-- http://github.com/fogus
--

-- 
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: (#({:a %}) :b)

[JvJ]

Clever, but I always thought -> had to take more than one parameter.  Maybe 
that's only for ->>

On Thursday, 13 December 2012 13:35:33 UTC-5, Gary Verhaegen wrote:
>
> I've found this gem in The Joy of Clojure : 
>
> #(-> [%]) 
>
> which would work similarly for any literal, I guess : #(-> {:a %}) in 
> this case. Much nicer than identity, IMHO. 
>
> On 4 June 2012 15:28, Steven Obua > wrote: 
> > Jay's example has convinced me that redefinition is not a good idea 
> anyway, 
> > because #(f) is not always equivalent to f when (count [f]) is 1. 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> > Groups "Clojure" group. 
> > To post to this group, send email to clo...@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+u...@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: (#({:a %}) :b)

[Gary Verhaegen]

I've found this gem in The Joy of Clojure :

#(-> [%])

which would work similarly for any literal, I guess : #(-> {:a %}) in
this case. Much nicer than identity, IMHO.

On 4 June 2012 15:28, Steven Obua  wrote:
> Jay's example has convinced me that redefinition is not a good idea anyway,
> because #(f) is not always equivalent to f when (count [f]) is 1.
>
> --
> 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

Bestcase -- A/B Testing Library for Clojure

[Jean-Denis Greze]

Hi,

I've just released Bestcase -- an easy-to-use A/B and multivariate testing 
library for Clojure [https://github.com/jeandenis/bestcase].  It's heavily 
influenced by A/Bingo <http://www.bingocardcreator.com/abingo> for Rails.

Its main features are:

   - create tests in one line of code
   - test multiple goals per test and multiple tests per page
   - In-memory or redis-backed
   - ring-middleware to ease integration
   - comes with a web-console so you can analyze results and pick winners 
   without having to edit any code or restart your webserver

It's up on Clojars.  A user guide is available on the github wiki [
https://github.com/jeandenis/bestcase/wiki/User-Guide].

Roadmap: Working on a plugin architecture so that you can report tests to 
third party services or libraries (e.g., MixPanel).

Comments and feedback more than welcome.

Thanks and best,

Jean-Denis
jeandenis at gmail.com

-- 
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] 4x library v1 releases, and a new A/B testing library

[Peter Taoussanis]

Hi Robert,

Are you planning any support for ClojureScript with Tower, at all?


No plans yet, but I'd be very happy to take pull-requests (or ideas) if 
anyone is interested!

The localization stuff basically just wraps standard Java facilities to 
make them more useable, so that's not particularly interesting. But the 
translation stuff would be a good candidate for Cljs: it's all-Clojure, 
data-centric, and very simple. There's the translation fn, the dictionary 
compiler, and perhaps one or two utilities that'd need to be brought over. 
Very doable, I'd say.

I'll start thinking about it. And in the meantime anyone interested should 
feel free to get in touch!

>

-- 
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] 4x library v1 releases, and a new A/B testing library

[Robert Stuttaford]

Thanks for your contributions, Peter!

Tower is of particular interest to me. Are you planning any support for 
ClojureScript with Tower, at all? Either way, I know we'll almost certainly 
make use of Tower. We will need to bring what Tower does into our cljs app 
as well. Perhaps we can contribute!

On Monday, November 5, 2012 6:28:08 PM UTC+2, Peter Taoussanis wrote:
>
> Hi all!
>
> I've just put out a number of new releases today. All libraries are up on 
> Clojars. Features & other info on the relevant GitHub pages.
>
> v1.0.0 releases
> ===
> *Carmine* - Redis client & message queue - 
> https://github.com/ptaoussanis/carmine
> *Timbre* - (sane) logging & profiling - 
> https://github.com/ptaoussanis/timbre
> *Tower* - internationalization & translation - 
> https://github.com/ptaoussanis/tower
> *Nippy* - serialization - https://github.com/ptaoussanis/nippy
>
> New releases
> ==
> *Touchstone* - split (A/B) testing - 
> https://github.com/ptaoussanis/touchstone
>
>
> Thanks to all of you that contributed input. As always, am very happy to 
> hear from anyone with problems/ideas/pull-requests/whatever!
>
> Cheers! :-)
>
> Peter Taoussanis,
> ptaoussanis at gmail.com
> https://twitter.com/ptaoussanis
>

-- 
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] 4x library v1 releases, and a new A/B testing library

[Peter Taoussanis]

Hi all!

I've just put out a number of new releases today. All libraries are up on 
Clojars. Features & other info on the relevant GitHub pages.

v1.0.0 releases
===
*Carmine* - Redis client & message queue - 
https://github.com/ptaoussanis/carmine
*Timbre* - (sane) logging & profiling - 
https://github.com/ptaoussanis/timbre
*Tower* - internationalization & translation - 
https://github.com/ptaoussanis/tower
*Nippy* - serialization - https://github.com/ptaoussanis/nippy

New releases
==
*Touchstone* - split (A/B) testing - 
https://github.com/ptaoussanis/touchstone


Thanks to all of you that contributed input. As always, am very happy to 
hear from anyone with problems/ideas/pull-requests/whatever!

Cheers! :-)

Peter Taoussanis,
ptaoussanis at gmail.com
https://twitter.com/ptaoussanis

-- 
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: A/B testing in Clojure?

[Simon Holgate]

I was thinking of something along the lines of django-lean (
https://bitbucket.org/akoha/django-lean/wiki/Home)  - "clean" perhaps :)

I haven't implemented any A/B testing yet so I just wanted to get a feel 
for what other people are doing. The silence seems to indicate that people 
aren't!

Having seen recent discussions about Rails, I can see that that the 
"framework" approach is not popular in the community so a library seems to 
be the way to go. 

I'd definitely be interested in putting something together. Time is a bit 
tight over the next month but I can do some then things free up.

Have you any experience in implementing A/B testing? I've been doing some 
reading and can pass on some pointers to resources if that would be helpful.

Simon

 

On Tuesday, 16 October 2012 23:31:01 UTC+2, millettjon wrote:
>
> I haven't but will be needing to do so in the next month or two. I'd be 
> interested to hear if you made any progress and possibly in collaborating.
>
> Jon
>
> On Monday, October 8, 2012 11:04:10 AM UTC-3, Simon Holgate wrote:
>>
>> Hi,
>>
>> Is anyone doing split (A/B) testing in Clojure? What are you using? Any 
>> pointers on things to consider if I'm implementing it myself?
>>
>> Thanks,
>>
>> Simon
>>
>

-- 
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: A/B testing in Clojure?

[millettjon]

I haven't but will be needing to do so in the next month or two. I'd be 
interested to hear if you made any progress and possibly in collaborating.

Jon

On Monday, October 8, 2012 11:04:10 AM UTC-3, Simon Holgate wrote:
>
> Hi,
>
> Is anyone doing split (A/B) testing in Clojure? What are you using? Any 
> pointers on things to consider if I'm implementing it myself?
>
> Thanks,
>
> Simon
>

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

A/B testing in Clojure?

[Simon Holgate]

Hi,

Is anyone doing split (A/B) testing in Clojure? What are you using? Any 
pointers on things to consider if I'm implementing it myself?

Thanks,

Simon

-- 
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: another why: (flatten #{:a :b}) => () ???

[dmirylenka]

Thanks for the elaborate answer!
It also clears some other doubts I had regarding the core functions.

On Wednesday, August 29, 2012 11:34:56 PM UTC+2, miner wrote:
>
> flatten has been discussed before: 
>
> https://groups.google.com/forum/?fromgroups=#!topic/clojure/ye70iNJ73zc 
>
> See also CLJ-400, but it looks like no patch was submitted. 
>
> http://dev.clojure.org/jira/browse/CLJ-400 
>
> I think the general policy for Clojure is that the core functions of 
> course should work as documented, but they do not necessarily handle 
> undocumented edge cases.  So if you use the wrong kinds of arguments, the 
> implementation does not have to detect your error -- it might throw or just 
> give you non-useful results.  There's a trade-off among ease of 
> implementation, performance and programmer friendliness.  If it's a common 
> mistake, maybe an assertion is warranted.  If I remember correctly, Rich 
> Hickey suggested that someday there might be an option to run a stricter 
> version of Clojure (with lots of assertions) during development, and a 
> faster version with less checking in production. 
>
> Regarding flatten in particular, I would like it to be faster and to do a 
> bit more to help the careless programmer.  I was all set to submit a patch 
> condemning the elegant but slow implementation when I noticed that the new 
> "reducers" version of flatten in 1.5 alphas is amazingly fast.  So that 
> looks like the way to go. 
>
>
>
> On Aug 29, 2012, at 3:47 PM, dmirylenka > 
> wrote: 
>
> > Calling flatten on anything that is not 'sequential?' returns an empty 
> sequence: 
> > 
> > (flatten 1); => () 
> > (flatten "Hi"); => () 
> > 
> > With sets if feels somewhat strange: 
> > 
> > (flatten #{#{:a} #{:b :c}}); => () 
> > 
> > For some reason I expected #{#{:a} #{:b :c}} to equal #{:a :b :c}. 
> > 
> > Ok, the docstring says: "Takes any nested combination of sequential 
> things...", and sets are not sequential... 
> > 
> > But then, why 
> > 
> > (reduce + (flatten #{1 2})); => 0 
> > (r/reduce + (r/flatten #{1 2})); => 3 ? 
>
>

-- 
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: another why: (flatten #{:a :b}) => () ???

[Steve Miner]

flatten has been discussed before:

https://groups.google.com/forum/?fromgroups=#!topic/clojure/ye70iNJ73zc

See also CLJ-400, but it looks like no patch was submitted.

http://dev.clojure.org/jira/browse/CLJ-400

I think the general policy for Clojure is that the core functions of course 
should work as documented, but they do not necessarily handle undocumented edge 
cases.  So if you use the wrong kinds of arguments, the implementation does not 
have to detect your error -- it might throw or just give you non-useful 
results.  There's a trade-off among ease of implementation, performance and 
programmer friendliness.  If it's a common mistake, maybe an assertion is 
warranted.  If I remember correctly, Rich Hickey suggested that someday there 
might be an option to run a stricter version of Clojure (with lots of 
assertions) during development, and a faster version with less checking in 
production.

Regarding flatten in particular, I would like it to be faster and to do a bit 
more to help the careless programmer.  I was all set to submit a patch 
condemning the elegant but slow implementation when I noticed that the new 
"reducers" version of flatten in 1.5 alphas is amazingly fast.  So that looks 
like the way to go.



On Aug 29, 2012, at 3:47 PM, dmirylenka  wrote:

> Calling flatten on anything that is not 'sequential?' returns an empty 
> sequence:
> 
> (flatten 1); => () 
> (flatten "Hi"); => () 
> 
> With sets if feels somewhat strange:
> 
> (flatten #{#{:a} #{:b :c}}); => ()
> 
> For some reason I expected #{#{:a} #{:b :c}} to equal #{:a :b :c}.
> 
> Ok, the docstring says: "Takes any nested combination of sequential 
> things...", and sets are not sequential...
> 
> But then, why
> 
> (reduce + (flatten #{1 2})); => 0
> (r/reduce + (r/flatten #{1 2})); => 3 ?

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

another why: (flatten #{:a :b}) => () ???

[dmirylenka]

Calling flatten on anything that is not 'sequential?' returns an empty 
sequence:

(flatten 1); => () 
(flatten "Hi"); => () 

With sets if feels somewhat strange:

(flatten #{#{:a} #{:b :c}}); => ()

For some reason I expected #{#{:a} #{:b :c}} to equal #{:a :b :c}.

Ok, the docstring says: "Takes any nested combination of sequential 
things...", and sets are not sequential...

But then, why

(reduce + (flatten #{1 2})); => 0
(r/reduce + (r/flatten #{1 2})); => 3 ?

-- 
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: (#({:a %}) :b)

[Steven Obua]

Jay's example has convinced me that redefinition is not a good idea anyway, 
because #(f) is not always equivalent to f when (count [f]) is 1.

-- 
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: (#({:a %}) :b)

[Softaddicts]

Reader macros are syntactic sugar on top of the syntax.
They identify immediately what they stand for unambigously.

I doubt that it would be a good idea to introduce this kind of logic in the 
reader.
That's an open door to chaos. The same token could be used for different 
constructs.

As Meikel said, you can achieve a more readable result using vector and alikes 
to
avoid confusion.

In the same lineage, Clojure has no user alterable reader tables to avoid 
messing
with input interpretation.
That's been a clear statement since the beginning and I would be surprised that 
this
changes.

Don't hold your breath waiting for this to happen :)

Luc


> I doubt that this change would break anything, as the case that has changed 
> has been pretty useless so far.
> 
> On 4 Jun 2012, at 13:32, Moritz Ulrich wrote:
> 
> > I don't think redefining the behavior of fundamental syntax is a good
> > idea. Might break many things.
> 
> -- 
> 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
> 
--
Softaddicts sent by ibisMail from my ipad!

-- 
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: (#({:a %}) :b)

[Jay Fields]

; assume 'recorders' is {:x #(println (System/currentTimeMillis)) ... }
#((recorders %))

the above code has a single form (i.e. count 1), and allows you to get the
fn you desire from a map and immediately execute it.

I've done similar things in prod.

On Mon, Jun 4, 2012 at 8:51 AM, Steven Obua wrote:

> I doubt that this change would break anything, as the case that has
> changed has been pretty useless so far.
>
> On 4 Jun 2012, at 13:32, Moritz Ulrich wrote:
>
> > I don't think redefining the behavior of fundamental syntax is a good
> > idea. Might break many things.
>
> --
> 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: (#({:a %}) :b)

[Steven Obua]

I doubt that this change would break anything, as the case that has changed has 
been pretty useless so far.

On 4 Jun 2012, at 13:32, Moritz Ulrich wrote:

> I don't think redefining the behavior of fundamental syntax is a good
> idea. Might break many things.

-- 
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: (#({:a %}) :b)

[Moritz Ulrich]

I don't think redefining the behavior of fundamental syntax is a good
idea. Might break many things.

On Mon, Jun 4, 2012 at 2:29 PM, Steven Obua  wrote:
> Come to think of it, why not redefine #(...) in the following way:
>
>
> If (count [...]) is 0 or > 1 , then the old semantics stays
> If (count [...]) is 1, then the new semantics kicks in (i.e., without
> enclosing brackets).
>
> This would allow (#({:a %}) :b) to behave in a sane way
>
> In case f is actually a function of no arguments, for #(f) you would get
>
> (fn [] f)
>
> which is also more likely what you actually want compared to the old meaning
>
> (fn [] (f))
>
> which is equivalent to f (and therefore there is no need to write #(f) in
> the first place).
>
>
> On Monday, June 4, 2012 2:53:09 AM UTC+1, Steven Obua wrote:
>>
>> The expression
>>
>> (#({:a %}) :b)
>>
>> should evaluate to {:a :b}, but raises an exception instead:
>>
>> Wrong number of args (0) passed to: PersistentArrayMap
>>
>> This is a pretty irritating bug and makes the #% form essentially unusable
>> for me, because I cannot rely on it but have to always second guess if its
>> use is safe in the current context or not.
>
> --
> 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



-- 
Moritz Ulrich

-- 
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: (#({:a %}) :b)

[Steven Obua]

Come to think of it, why not redefine #(...) in the following way:


If (count [...]) is 0 or > 1 , then the old semantics stays 
If (count [...]) is 1, then the new semantics kicks in (i.e., without 
enclosing brackets).

This would allow (#({:a %}) :b) to behave in a sane way

In case f is actually a function of no arguments, for #(f) you would get 

(fn [] f)

which is also more likely what you actually want compared to the old meaning

(fn [] (f))

which is equivalent to f (and therefore there is no need to write #(f) in 
the first place).


On Monday, June 4, 2012 2:53:09 AM UTC+1, Steven Obua wrote:
>
> The expression
>
> (#({:a %}) :b)
>
> should evaluate to {:a :b}, but raises an exception instead:
>
> Wrong number of args (0) passed to: PersistentArrayMap
>
> This is a pretty irritating bug and makes the #% form essentially unusable 
> for me, because I cannot rely on it but have to always second guess if its 
> use is safe in the current context or not.
>

-- 
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: (#({:a %}) :b)

[Meikel Brandmeyer (kotarak)]

Or simply: #(vector 1 % 3)

Literals are not the only way to create data structures.

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: (#({:a %}) :b)

[nick rothwell]

This one has caught me once or twice as well: #(xxx) evaluates "(xxx)", not 
"xxx". My usual mistake is

... #([1 % 3]) ...

My rather verbose workround is

... #(identity [1 % 3]) ...

-- 
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: (#({:a %}) :b)

[Steven Obua]

Ah, I see. Thanks for the clarifications, at least now I understand why 
#(...) does what it does.

On Monday, June 4, 2012 2:53:09 AM UTC+1, Steven Obua wrote:
>
> The expression
>
> (#({:a %}) :b)
>
> should evaluate to {:a :b}, but raises an exception instead:
>
> Wrong number of args (0) passed to: PersistentArrayMap
>
> This is a pretty irritating bug and makes the #% form essentially unusable 
> for me, because I cannot rely on it but have to always second guess if its 
> use is safe in the current context or not.
>

-- 
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: (#({:a %}) :b)

[Bill Caputo]

On Jun 3, 2012, at 9:35 PM, James Reeves wrote:

> On 4 June 2012 03:00, Bill Caputo  wrote:
>> Someone with more knowledge than me can probably explain better, but my
>> understanding is that the the reader macro shorthand for anonymous functions
>> and the map literal syntax can't both be used together (i.e. it's not a bug,
>> but a reader limitation).
> 
> It's actually because #({:a %}) is equivalent to (fn [x] ({:a x})),
> when he wants (fn [x] {:a x}).
> 
> So it's not a bug, nor a reader limitation, but rather a
> misunderstanding of what #() is short for.

Ahh, that makes a lot more sense. Another foggy understanding clarified :-)


bill

-- 
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: (#({:a %}) :b)

[James Reeves]

On 4 June 2012 03:00, Bill Caputo  wrote:
> Someone with more knowledge than me can probably explain better, but my
> understanding is that the the reader macro shorthand for anonymous functions
> and the map literal syntax can't both be used together (i.e. it's not a bug,
> but a reader limitation).

It's actually because #({:a %}) is equivalent to (fn [x] ({:a x})),
when he wants (fn [x] {:a x}).

So it's not a bug, nor a reader limitation, but rather a
misunderstanding of what #() is short for.

- James

-- 
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: (#({:a %}) :b)

[Michael Gardner]

On Jun 3, 2012, at 8:53 PM, Steven Obua wrote:

> The expression
> 
> (#({:a %}) :b)
> 
> should evaluate to {:a :b}, but raises an exception instead:
> 
> Wrong number of args (0) passed to: PersistentArrayMap
> 
> This is a pretty irritating bug and makes the #% form essentially unusable 
> for me, because I cannot rely on it but have to always second guess if its 
> use is safe in the current context or not.

#(f ...) expands to (fn [...] (f ...)), so #({:a %}) would be (fn [x] ({:a x})).

In order for #({:a %}) to work as you want, the more common usage #(f %) would 
have to become #((f %)). That seems like a poor trade-off to me.

-- 
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: (#({:a %}) :b)

[Bill Caputo]

On Jun 3, 2012, at 8:53 PM, Steven Obua wrote:

> The expression
> 
> (#({:a %}) :b)

either: 

(#(hash-map :a %) :b) 
((fn [x] {:a x}) :b)

will work instead.


Someone with more knowledge than me can probably explain better, but my 
understanding is that the the reader macro shorthand for anonymous functions 
and the map literal syntax can't both be used together (i.e. it's not a bug, 
but a reader limitation).


bill

> 
> should evaluate to {:a :b}, but raises an exception instead:
> 
> Wrong number of args (0) passed to: PersistentArrayMap
> 
> This is a pretty irritating bug and makes the #% form essentially unusable 
> for me, because I cannot rely on it but have to always second guess if its 
> use is safe in the current context or not.
> 
> -- 
> 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

(#({:a %}) :b)

[Steven Obua]

The expression

(#({:a %}) :b)

should evaluate to {:a :b}, but raises an exception instead:

Wrong number of args (0) passed to: PersistentArrayMap

This is a pretty irritating bug and makes the #% form essentially unusable 
for me, because I cannot rely on it but have to always second guess if its 
use is safe in the current context or not.

-- 
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: Small problem: convert [a b c d] into [[[a b] c] d]

[samppi]

Dang. I forgot about reduce. Thanks a lot for the really quick answer!

On Nov 30, 3:45 pm, Martin DeMello  wrote:
> On Tue, Dec 1, 2009 at 4:09 AM, samppi  wrote:
> > The title says it all. Is there a nice, concise, Clojurey way to
> > convert a vector [a b c d] into [[[a b] c] d]? It's fine if the
> > vectors are sequences instead. I can't think of a way without a loop,
> > but I suspect there's a much shorter way.
>
> user=> (reduce vector [1 2 3 4])
> [[[1 2] 3] 4]
>
> martin

-- 
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: Small problem: convert [a b c d] into [[[a b] c] d]

[Martin DeMello]

On Tue, Dec 1, 2009 at 4:09 AM, samppi  wrote:
> The title says it all. Is there a nice, concise, Clojurey way to
> convert a vector [a b c d] into [[[a b] c] d]? It's fine if the
> vectors are sequences instead. I can't think of a way without a loop,
> but I suspect there's a much shorter way.

user=> (reduce vector [1 2 3 4])
[[[1 2] 3] 4]

martin

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

Small problem: convert [a b c d] into [[[a b] c] d]

[samppi]

The title says it all. Is there a nice, concise, Clojurey way to
convert a vector [a b c d] into [[[a b] c] d]? It's fine if the
vectors are sequences instead. I can't think of a way without a loop,
but I suspect there's a much shorter way.

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