Re: [$Bounty] Emacs plugin for Typed Clojure

2014-02-12 Thread john walker
Ahh, this turned out to be fairly interesting. My first thought was to 
check the aliases using (ns-alias), but it turns out that re-evaluating a 
namespace after removing the alias leaves the original aliases in place. So 
I'm just going to use a regex, which is probably easier anyway.

On Wednesday, February 12, 2014 2:29:31 AM UTC-5, Ambrose Bonnaire-Sergeant 
wrote:
>
> Hi John,
>
> Wow! One thing, if clojure.core.typed is aliases in the current namespace, 
> then the ann* refactor
> should use that alias. If there is no alias, then use the fully qualified 
> namespace. If the var is
> referred into the current ns-map, then use the fully qualified namespace 
> or a namespace alias prefix
> if available.
>
> Thanks,
> Ambrose
>
>
> On Wed, Feb 12, 2014 at 3:18 PM, john walker 
> 
> > wrote:
>
>> I'm still on my first cup, so let me know what you think:
>>
>> https://github.com/johnwalker/typed-clojure-el
>>
>>
>> On Tuesday, February 11, 2014 12:01:36 PM UTC-5, Ambrose 
>> Bonnaire-Sergeant wrote:
>>>
>>> Hi,
>>>
>>> I need a relatively straightforward Emacs plugin for Typed Clojure 
>>> written.
>>>
>>> I'm offering a $200US bounty. If you would also like to see this, please 
>>> bump up the $$.
>>>
>>> If you're interested in claiming, see the bounty 
>>> page
>>>  and 
>>> the Jira issue  for a 
>>> brief description. Please comment or email me if you are interested.
>>>
>>> Thanks,
>>> Ambrose
>>>
>>  -- 
>> 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 unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

-- 
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: [$Bounty] Emacs plugin for Typed Clojure

2014-02-12 Thread Ambrose Bonnaire-Sergeant
Hi John,

I don't mind that ns-aliases can go out of date. Please use the output of
ns-alias as authoritative, and make a documentation note of this quirk.

Thanks,
Ambrose


On Wed, Feb 12, 2014 at 4:03 PM, john walker wrote:

> Ahh, this turned out to be fairly interesting. My first thought was to
> check the aliases using (ns-alias), but it turns out that re-evaluating a
> namespace after removing the alias leaves the original aliases in place. So
> I'm just going to use a regex, which is probably easier anyway.
>
>
> On Wednesday, February 12, 2014 2:29:31 AM UTC-5, Ambrose
> Bonnaire-Sergeant wrote:
>
>> Hi John,
>>
>> Wow! One thing, if clojure.core.typed is aliases in the current
>> namespace, then the ann* refactor
>> should use that alias. If there is no alias, then use the fully qualified
>> namespace. If the var is
>> referred into the current ns-map, then use the fully qualified namespace
>> or a namespace alias prefix
>> if available.
>>
>> Thanks,
>> Ambrose
>>
>>
>> On Wed, Feb 12, 2014 at 3:18 PM, john walker wrote:
>>
>>>  I'm still on my first cup, so let me know what you think:
>>>
>>> https://github.com/johnwalker/typed-clojure-el
>>>
>>>
>>> On Tuesday, February 11, 2014 12:01:36 PM UTC-5, Ambrose
>>> Bonnaire-Sergeant wrote:

 Hi,

 I need a relatively straightforward Emacs plugin for Typed Clojure
 written.

 I'm offering a $200US bounty. If you would also like to see this,
 please bump up the $$.

 If you're interested in claiming, see the bounty 
 page
  and
 the Jira issue  for a
 brief description. Please comment or email me if you are interested.

 Thanks,
 Ambrose

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

-- 
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: [$Bounty] Emacs plugin for Typed Clojure

2014-02-12 Thread john walker
Added.

The next big thing I see is fixing which-function. 

On Wednesday, February 12, 2014 3:07:44 AM UTC-5, Ambrose Bonnaire-Sergeant 
wrote:
>
> Hi John,
>
> I don't mind that ns-aliases can go out of date. Please use the output of 
> ns-alias as authoritative, and make a documentation note of this quirk.
>
> Thanks,
> Ambrose 
>
>
> On Wed, Feb 12, 2014 at 4:03 PM, john walker 
> 
> > wrote:
>
>> Ahh, this turned out to be fairly interesting. My first thought was to 
>> check the aliases using (ns-alias), but it turns out that re-evaluating a 
>> namespace after removing the alias leaves the original aliases in place. So 
>> I'm just going to use a regex, which is probably easier anyway.
>>
>>
>> On Wednesday, February 12, 2014 2:29:31 AM UTC-5, Ambrose 
>> Bonnaire-Sergeant wrote:
>>
>>> Hi John,
>>>
>>> Wow! One thing, if clojure.core.typed is aliases in the current 
>>> namespace, then the ann* refactor
>>> should use that alias. If there is no alias, then use the fully 
>>> qualified namespace. If the var is
>>> referred into the current ns-map, then use the fully qualified namespace 
>>> or a namespace alias prefix
>>> if available.
>>>
>>> Thanks,
>>> Ambrose
>>>
>>>
>>> On Wed, Feb 12, 2014 at 3:18 PM, john walker wrote:
>>>
  I'm still on my first cup, so let me know what you think:

 https://github.com/johnwalker/typed-clojure-el


 On Tuesday, February 11, 2014 12:01:36 PM UTC-5, Ambrose 
 Bonnaire-Sergeant wrote:
>
> Hi,
>
> I need a relatively straightforward Emacs plugin for Typed Clojure 
> written.
>
> I'm offering a $200US bounty. If you would also like to see this, 
> please bump up the $$.
>
> If you're interested in claiming, see the bounty 
> page
>  and 
> the Jira issue  for a 
> brief description. Please comment or email me if you are interested.
>
> Thanks,
> Ambrose
>
  -- 
 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 unsubscribe from this group and stop receiving emails from it, send 
 an email to clojure+u...@googlegroups.com.

 For more options, visit https://groups.google.com/groups/opt_out.

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

-- 
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: [$Bounty] Emacs plugin for Typed Clojure

2014-02-12 Thread john walker
Well, that was easy to find. It will be fixed in the next version of 
clojure mode. If you are impatient, do

C-h f clojure-match-next-def, click on clojure-mode.el

and replace the line

  (when (re-search-backward "^(def\sw*" nil t)

with

  (when (re-search-backward "^(def\\sw*" nil t)

then recompile your clojure-mode.el. This probably will not exist after the 
February 1st snapshot. Source: 
https://github.com/clojure-emacs/clojure-mode/commit/32feee877233a4d98fb934dcbd42789e56dac790

On Wednesday, February 12, 2014 3:24:12 AM UTC-5, john walker wrote:
>
> Added.
>
> The next big thing I see is fixing which-function. 
>
> On Wednesday, February 12, 2014 3:07:44 AM UTC-5, Ambrose 
> Bonnaire-Sergeant wrote:
>>
>> Hi John,
>>
>> I don't mind that ns-aliases can go out of date. Please use the output of 
>> ns-alias as authoritative, and make a documentation note of this quirk.
>>
>> Thanks,
>> Ambrose 
>>
>>
>> On Wed, Feb 12, 2014 at 4:03 PM, john walker wrote:
>>
>>> Ahh, this turned out to be fairly interesting. My first thought was to 
>>> check the aliases using (ns-alias), but it turns out that re-evaluating a 
>>> namespace after removing the alias leaves the original aliases in place. So 
>>> I'm just going to use a regex, which is probably easier anyway.
>>>
>>>
>>> On Wednesday, February 12, 2014 2:29:31 AM UTC-5, Ambrose 
>>> Bonnaire-Sergeant wrote:
>>>
 Hi John,

 Wow! One thing, if clojure.core.typed is aliases in the current 
 namespace, then the ann* refactor
 should use that alias. If there is no alias, then use the fully 
 qualified namespace. If the var is
 referred into the current ns-map, then use the fully qualified 
 namespace or a namespace alias prefix
 if available.

 Thanks,
 Ambrose


 On Wed, Feb 12, 2014 at 3:18 PM, john walker wrote:

>  I'm still on my first cup, so let me know what you think:
>
> https://github.com/johnwalker/typed-clojure-el
>
>
> On Tuesday, February 11, 2014 12:01:36 PM UTC-5, Ambrose 
> Bonnaire-Sergeant wrote:
>>
>> Hi,
>>
>> I need a relatively straightforward Emacs plugin for Typed Clojure 
>> written.
>>
>> I'm offering a $200US bounty. If you would also like to see this, 
>> please bump up the $$.
>>
>> If you're interested in claiming, see the bounty 
>> page
>>  and 
>> the Jira issue  for a 
>> brief description. Please comment or email me if you are interested.
>>
>> Thanks,
>> Ambrose
>>
>  -- 
> 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 unsubscribe from this group and stop receiving emails from it, send 
> an email to clojure+u...@googlegroups.com.
>
> For more options, visit https://groups.google.com/groups/opt_out.
>

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

-- 
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: cond-> variant?

2014-02-12 Thread Alex Baranosky
I wrote pred-cond for Midje way back, which does what you want.
https://github.com/marick/Midje/blob/master/src/midje/clojure/core.clj#L176

Example use:
https://github.com/marick/Midje/blob/master/src/midje/parsing/1_to_explicit_form/facts.clj#L100

Like normal cond pred-cond will short-circuit once it hits a match (so
unlike con->)



On Tue, Feb 11, 2014 at 11:36 PM,  wrote:

>  I use cond-> quite a lot but I find myself often wanting a version that
> uses predicate functions rather than expressions which would seem
> more “threaded”. Am I just missing a better way to write these things?
>
> For example:
>
> (cond-> accounts
>   (empty? accounts) (conj “stuff”))
>
> That just screams for something like:
>
> (condp-> accounts
>   empty? (conj “stuff”))
>
> Then you could thread the predicates:
>
> (condp-> a
>   p1 (f1 args)
>   p2 (f2 args))
>
> which would be:
>
> (let [x (if (p1 a) (f1 a args) a)]
>   (if (p2 x) (f2 x args) x))
>
> Suggestions?
>
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org
> World Singles, LLC - http://worldsingles.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.
>

-- 
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: ISeq documentation and mutual deftypes.

2014-02-12 Thread Mikera
Clearly they are useful as SPI.

But I'd argue they are also API-relevant: if you get hold of a Clojure var 
through the Java API and invoke it via IFn, then these interfaces are 
pretty useful to help you construct parameters and deal with return values. 
They are not completely essential (since you can also do this through the 
core API) but still very handy.

Not a big deal I guess, but I do like the ability to use the Clojure data 
structure interfaces from Java.

On Wednesday, 12 February 2014 12:32:29 UTC+8, Alex Miller wrote:
>
> IFn (along with the new clojure.java.api.Clojure class) are the totality 
> of the official Java API for Clojure.
>
> I would consider some of the other interfaces you mention to effectively 
> be "SPI" (along with "trait" interfaces like Counted, Seqable, Indexed, 
> etc). If something were going to be added to clojure.org, I think it 
> would be along the lines of how to write new impls (not just collections 
> but sequences, functions, whatever) that can conform to the same 
> expectations as built-in objects. 
>
>
> On Tuesday, February 11, 2014 9:07:16 PM UTC-6, Mikera wrote:
>>
>> This is useful information - thanks Alex! 
>>
>> Might be worth putting some of this on a Clojure.org page somewhere, 
>> perhaps linked to the Java interop section?
>>
>> As someone who quite regularly interfaces to Clojure from Java, it would 
>> be useful to make *some* of the interfaces into an official public Java 
>> API. The ones I'm thinking of in particular are:
>> IFn
>> ISeq
>> ILookup
>> IPersistentMap
>> IPersistentVector
>> IPersistentList
>> IPersistentCollection
>> IMeta 
>> IObj (for metadata updates)
>>
>> Together these give just enough API surface area to efficiently navigate 
>> Clojure data structures, which is pretty crucial for interop..
>>
>> It might be a good implementation option to put the "public" parts of 
>> these interfaces in the clojure.java.api package, and have the internal 
>> Clojure interfaces / classes in clojure.lang inherit from these.
>>
>>
>> On Wednesday, 12 February 2014 08:11:18 UTC+8, Alex Miller wrote:
>>>
>>> I'd say there is a range of "public"-ness to the internals of Clojure.
>>>
>>> - The new Clojure API (clojure.java.api.Clojure) is an official public 
>>> API for external callers of Clojure. This API basically consists of ways to 
>>> resolve vars and invoke functions.
>>> - For Clojure users in Clojure, pretty much any var that's public and 
>>> has a docstring, and shows up in the api docs can be considered public API.
>>> - Clojure vars that are private or have no docstring (such that the var 
>>> is omitted from public api docs) are likely places to tread very carefully.
>>> - The Clojure internal Java interfaces are certainly intended to allow 
>>> library builders to create useful stuff that plays in the Clojure world. I 
>>> do not know that anyone has ever said that they are "public", but I 
>>> certainly think that any change to a core interface likely to break 
>>> external users would be considered very carefully. 
>>> - The Clojure internal Java classes should in most cases be considered 
>>> private and subject to change without notice. There are grey areas even 
>>> there.
>>>
>>> In general, we do not place a high value on encapsulation or hiding 
>>> internals. In most cases, the internals are left available if they might be 
>>> useful to an advanced user doing interesting things, with the caveat that 
>>> the weirder things you do, the more likely you are to be accidentally 
>>> broken in a future release.
>>>
>>> Re documentation, I personally would like to have more around the Java 
>>> interfaces, but I don't know whether that will happen. I think 80% of the 
>>> interfaces are pretty obvious but admittedly that last 20% can take a while 
>>> to ferret out. I'm happy to answer questions as I see them on the list.
>>>
>>>
>>> On Tuesday, February 11, 2014 5:02:16 PM UTC-6, John Hume wrote:

 On Tue, Feb 11, 2014 at 7:32 AM, Phillip Lord <
 philli...@newcastle.ac.uk> wrote:

> "John D. Hume"  writes:
> > Other than the new (and quite minimal) Java API for calling
> > Clojure code[1], the details of Clojure's underlying Java classes are
> > considered implementation details and could change from release to 
> release
> > without being considered a breaking change.
>
>
> And the interfaces? I mean, ISeq is defines the sequence abstraction.


 When I said "underlying java classes" I meant "underlying Java classes 
 and interfaces." 

 Although there are contrib and third party libraries that depend on 
 these implementation details, I think the message to the community at 
 large 
 has always been not to depend on them, and as far as I know, the 
 maintainers have not committed to keeping anything other than the newly 
 documented Java API and the existing Clojure API in Clojure stable.

 So if I'm not mistaken, i

Re: ISeq documentation and mutual deftypes.

2014-02-12 Thread Phillip Lord
Mikera  writes:

> This is useful information - thanks Alex! 
>
> Might be worth putting some of this on a Clojure.org page somewhere, 
> perhaps linked to the Java interop section?
>
> As someone who quite regularly interfaces to Clojure from Java, it would be 
> useful to make *some* of the interfaces into an official public Java API. 
> The ones I'm thinking of in particular are:
> IFn
> ISeq
> ILookup
> IPersistentMap
> IPersistentVector
> IPersistentList
> IPersistentCollection
> IMeta 
> IObj (for metadata updates)
>
> Together these give just enough API surface area to efficiently navigate 
> Clojure data structures, which is pretty crucial for interop..


I'm not sure this is just an interop issue. As the website says:

"Clojure is written in terms of abstractions. There are abstractions for
sequences, collections, callability, etc. In addition, Clojure supplies
many implementations of these abstractions. The abstractions are
specified by host interfaces, and the implementations by host classes."

For these abstractions to be useful, they must be usable in "client"
code. Otherwise, they are an implementation detail.

I guess, in the abstract (oops), the problem is that ISeq is a Java
interface, when really it should be a protocol, i.e. defined in Clojure.
In the meantime, documentation would be good!

Phil


-- 
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: ISeq documentation and mutual deftypes.

2014-02-12 Thread Phillip Lord
Brandon Bloom  writes:
>
>> The closest I have got it: 
>> (declare create-alice) 
>> (declare create-brian) 
>
> Yup, that's A-OK. You can also just write (declare create-alice 
> create-brian).
>
> The tricky bit comes in when you actually need to refer to the types by 
> name directly. Say, if you wanted to create mutually recursive deftypes 
> with type hints (maybe for host interop reasons). In that case, you can 
> indirect through interfaces/protocols:
>
> (defprotocol IFoo ...)
> (defprotocol IBar ...)
>
> (deftype Foo [^IBar bar] ...)
> (deftype Bar [^IFoo foo] ...)
>
> If you genuinely need mutually recursive types and can't indirect through 
> protocols (or interfaces), then you probably have a particular JVM interop 
> use case and should just write Java for that purpose.


Thank you, this is a very good answer!

Phil

-- 
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: [$Bounty] Emacs plugin for Typed Clojure

2014-02-12 Thread Ambrose Bonnaire-Sergeant
Hi John,

I gave it a whirl, it's exactly what I wanted.

When you're ready please claim the bounty.

Thanks,
Ambrose

On Wed, Feb 12, 2014 at 4:46 PM, john walker wrote:

> Well, that was easy to find. It will be fixed in the next version of
> clojure mode. If you are impatient, do
>
> C-h f clojure-match-next-def, click on clojure-mode.el
>
> and replace the line
>
>   (when (re-search-backward "^(def\sw*" nil t)
>
> with
>
>   (when (re-search-backward "^(def\\sw*" nil t)
>
> then recompile your clojure-mode.el. This probably will not exist after
> the February 1st snapshot. Source:
> https://github.com/clojure-emacs/clojure-mode/commit/32feee877233a4d98fb934dcbd42789e56dac790
>
>
> On Wednesday, February 12, 2014 3:24:12 AM UTC-5, john walker wrote:
>>
>> Added.
>>
>> The next big thing I see is fixing which-function.
>>
>> On Wednesday, February 12, 2014 3:07:44 AM UTC-5, Ambrose
>> Bonnaire-Sergeant wrote:
>>>
>>> Hi John,
>>>
>>> I don't mind that ns-aliases can go out of date. Please use the output
>>> of ns-alias as authoritative, and make a documentation note of this quirk.
>>>
>>> Thanks,
>>> Ambrose
>>>
>>>
>>> On Wed, Feb 12, 2014 at 4:03 PM, john walker wrote:
>>>
 Ahh, this turned out to be fairly interesting. My first thought was to
 check the aliases using (ns-alias), but it turns out that re-evaluating a
 namespace after removing the alias leaves the original aliases in place. So
 I'm just going to use a regex, which is probably easier anyway.


 On Wednesday, February 12, 2014 2:29:31 AM UTC-5, Ambrose
 Bonnaire-Sergeant wrote:

> Hi John,
>
> Wow! One thing, if clojure.core.typed is aliases in the current
> namespace, then the ann* refactor
> should use that alias. If there is no alias, then use the fully
> qualified namespace. If the var is
> referred into the current ns-map, then use the fully qualified
> namespace or a namespace alias prefix
> if available.
>
> Thanks,
> Ambrose
>
>
> On Wed, Feb 12, 2014 at 3:18 PM, john walker wrote:
>
>>  I'm still on my first cup, so let me know what you think:
>>
>> https://github.com/johnwalker/typed-clojure-el
>>
>>
>> On Tuesday, February 11, 2014 12:01:36 PM UTC-5, Ambrose
>> Bonnaire-Sergeant wrote:
>>>
>>> Hi,
>>>
>>> I need a relatively straightforward Emacs plugin for Typed Clojure
>>> written.
>>>
>>> I'm offering a $200US bounty. If you would also like to see this,
>>> please bump up the $$.
>>>
>>> If you're interested in claiming, see the bounty 
>>> page
>>>  and
>>> the Jira issue  for a
>>> brief description. Please comment or email me if you are interested.
>>>
>>> Thanks,
>>> Ambrose
>>>
>>  --
>> 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 unsubscribe from this group and stop receiving emails from it,
>> send an email to clojure+u...@googlegroups.com.
>>
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>  --
 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 unsubscribe from this group and stop receiving emails from it, send
 an email to clojure+u...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.

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

Re: OT: Enterprise Schedulers

2014-02-12 Thread Adrian Mowat
Hi Luca

Thanks for the links!

I definitely have a lot of hammock time ahead of me :-)

Cheers

Adrian


On 11 Feb 2014, at 14:37, icamts wrote:

> Hi Adrian,
> the answer is more off-topic than the question :) but have a look to Spagic 
> (I'm a member of the developers' team), Mule ESB, Petals ESB or Talend ESB. 
> You may already know Talend as an ETL solution. You'll find tools to define, 
> configure and run instances of services or processes. Monitong application 
> with re-start / re-run facilities. Connectors for services / processes 
> integration.
> 
> In a ESB scenario developers will design simple processes with a quartz or 
> file polling connector followed by a script / custom component designed to 
> accomplist the batch task. 
> 
> Custom components can be written in clojure if you reify the required 
> interface. The only cavevat is the AOT compilation.
> 
> Some other ideas are below, along your problem statement.
> 
> Cheers,
> Luca
> 
> Be controlled by artifacts developers control
> Probably be github friendly
>  
> Put service deployment directory and estensions / plugins directory under 
> version control and copy them as a part of the deployment process. An ESB can 
> be deployed like a simple webapp.
> Provide a direct relationship between an application and its tasks
> 
> Choose meaningful service names. Deploy a local ESB in the same AS of your 
> application and use an in-memory invoker / connector. 
> Support separate sandbox, staging and production environments
> 
>  Use different ESB instances.
> Be scalable
> 
> Single task scalability is up to your code.
> Be distributed - jobs for application X can run on the same host as 
> application X or on a different host or cluster as needed
> 
> Sevices / processes can be run on every ESB instance. Use in-memory invoker / 
> connector or soap invoker / connector.
> Be secure
> 
> Use https for remote connection. Use sftp for file transfer. 
> Be easy to administer
> Job progress and status is visible
> 
> Service progress notification is up to your code and not a monitor console 
> feature. Process running step is available. 
> Alert when a job fails
> 
> Use a mail connector to alert on job fails
> Easy to re-run a job
> 
> Restart / rerun through monitoring console. 
> Easy to spin up new hosts and/or move all processing to a different host
> 
> Deploy a new instance with the same configuration. No running service can be 
> moved. Running processes may be moved. It depends on workflow engine 
> implementation details.
> Provide a standard way of organising assets like files and configs across all 
> our applications
>  
> (Not sure what you mean.)
> Comply with our hybrid infrastructure (stuff runs internally and in the cloud)
> Data can move internal -> cloud
>  
> Is it an ETL task?
> Data can move cloud -> internal
> 
> Same as before 
> Data can be processed entirely within a host
>  
> That's so
> Support different ways of triggering a job
> Scheduled tasks
> 
> Use a quartz input connector 
> Run when file x arrives
> 
> Use a file poller input connector 
> Run job y after job x completes
>  
> Use an output connector to trigger the next job start or design a process 
> with jobs in a sequence.
> 
> -- 
> 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 a topic in the Google 
> Groups "Clojure" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/clojure/95W4MlkFgnY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.


Adrian Mowat

Tweet: @mowat27

Am I being a bit short?  Here's why: http://emailcharter.org/, 
http://inboxzero.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: range-sum

2014-02-12 Thread Vincent
On Friday, February 7, 2014 2:23:33 AM UTC, Sean Corfield wrote:
>
> On Feb 6, 2014, at 12:58 PM, Stuart Sierra 
> > 
> wrote:
>
> I think (reduce + (range N)) is commonly used in **examples**, not 
> necessarily in real applications.
>
>
> I'd have to agree: I don't see anything like that in our 20kloc at World 
> Singles. I see a handful of (reduce + data) for arbitrary series of data 
> values.
>

On a slightly different topic: why reduce and not apply?

user=> (time (reduce + (range 1000)))
"Elapsed time: 402.17 msecs"
499500
user=> (time (apply + (range 1000)))
"Elapsed time: 361.099043 msecs"
499500

 

> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org/
>
> "Perfection is the enemy of the good."
> -- Gustave Flaubert, French realist novelist (1821-1880)
>

-- 
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: range-sum

2014-02-12 Thread Stuart Sierra
On Wednesday, February 12, 2014 8:46:41 AM UTC-5, Vincent wrote:
>
> On a slightly different topic: why reduce and not apply?
>

The implementation of `+` with more than 2 arguments uses `reduce` 
internally. So they amount to the same thing.

There isn't really a performance difference:

user=> (dotimes [i 7] (time (reduce + (range 1000
"Elapsed time: 354.475 msecs"
"Elapsed time: 346.235 msecs"
"Elapsed time: 348.124 msecs"
"Elapsed time: 348.894 msecs"
"Elapsed time: 379.9 msecs"
"Elapsed time: 356.337 msecs"
"Elapsed time: 362.788 msecs"
nil
user=> (dotimes [i 7] (time (apply + (range 1000
"Elapsed time: 360.067 msecs"
"Elapsed time: 353.281 msecs"
"Elapsed time: 345.694 msecs"
"Elapsed time: 355.162 msecs"
"Elapsed time: 346.511 msecs"
"Elapsed time: 350.61 msecs"
"Elapsed time: 353.674 msecs"
nil

-- 
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: [$Bounty] Emacs plugin for Typed Clojure

2014-02-12 Thread john walker
OK, thanks! I realigned the repository name / filename / modename to be 
both more correct and compliant with your fork. My version can now be seen 
here:

https://github.com/johnwalker/typed-clojure-mode

I didn't immediately see how to claim a bounty, but I see that the issue 
has to be marked as resolved first. I'm going to send in a CA tonight too, 
since I was planning on trying gsoc anyway.

On Wednesday, February 12, 2014 6:44:08 AM UTC-5, Ambrose Bonnaire-Sergeant 
wrote:
>
> Hi John,
>
> I gave it a whirl, it's exactly what I wanted.
>
> When you're ready please claim the bounty.
>
> Thanks,
> Ambrose
>
> On Wed, Feb 12, 2014 at 4:46 PM, john walker 
> 
> > wrote:
>
>> Well, that was easy to find. It will be fixed in the next version of 
>> clojure mode. If you are impatient, do
>>
>> C-h f clojure-match-next-def, click on clojure-mode.el
>>
>> and replace the line
>>
>>   (when (re-search-backward "^(def\sw*" nil t)
>>
>> with
>>
>>   (when (re-search-backward "^(def\\sw*" nil t)
>>
>> then recompile your clojure-mode.el. This probably will not exist after 
>> the February 1st snapshot. Source: 
>> https://github.com/clojure-emacs/clojure-mode/commit/32feee877233a4d98fb934dcbd42789e56dac790
>>
>>
>> On Wednesday, February 12, 2014 3:24:12 AM UTC-5, john walker wrote:
>>>
>>> Added.
>>>
>>> The next big thing I see is fixing which-function. 
>>>
>>> On Wednesday, February 12, 2014 3:07:44 AM UTC-5, Ambrose 
>>> Bonnaire-Sergeant wrote:

 Hi John,

 I don't mind that ns-aliases can go out of date. Please use the output 
 of ns-alias as authoritative, and make a documentation note of this quirk.

 Thanks,
 Ambrose 


 On Wed, Feb 12, 2014 at 4:03 PM, john walker wrote:

> Ahh, this turned out to be fairly interesting. My first thought was to 
> check the aliases using (ns-alias), but it turns out that re-evaluating a 
> namespace after removing the alias leaves the original aliases in place. 
> So 
> I'm just going to use a regex, which is probably easier anyway.
>
>
> On Wednesday, February 12, 2014 2:29:31 AM UTC-5, Ambrose 
> Bonnaire-Sergeant wrote:
>
>> Hi John,
>>
>> Wow! One thing, if clojure.core.typed is aliases in the current 
>> namespace, then the ann* refactor
>> should use that alias. If there is no alias, then use the fully 
>> qualified namespace. If the var is
>> referred into the current ns-map, then use the fully qualified 
>> namespace or a namespace alias prefix
>> if available.
>>
>> Thanks,
>> Ambrose
>>
>>
>> On Wed, Feb 12, 2014 at 3:18 PM, john walker wrote:
>>
>>>  I'm still on my first cup, so let me know what you think:
>>>
>>> https://github.com/johnwalker/typed-clojure-el
>>>  
>>>
>>> On Tuesday, February 11, 2014 12:01:36 PM UTC-5, Ambrose 
>>> Bonnaire-Sergeant wrote:

 Hi,

 I need a relatively straightforward Emacs plugin for Typed Clojure 
 written.

 I'm offering a $200US bounty. If you would also like to see this, 
 please bump up the $$.

 If you're interested in claiming, see the bounty 
 page
  and 
 the Jira issue  for a 
 brief description. Please comment or email me if you are interested.

 Thanks,
 Ambrose

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

Re: [$Bounty] Emacs plugin for Typed Clojure

2014-02-12 Thread Ambrose Bonnaire-Sergeant
I guess it takes awhile to propagate to BountySource.

Did you have any projects in mind for GSoC? Perhaps more Typed Clojure work?

Thanks,
Ambrose

On Wed, Feb 12, 2014 at 11:32 PM, john walker wrote:

> OK, thanks! I realigned the repository name / filename / modename to be
> both more correct and compliant with your fork. My version can now be seen
> here:
>
> https://github.com/johnwalker/typed-clojure-mode
>
> I didn't immediately see how to claim a bounty, but I see that the issue
> has to be marked as resolved first. I'm going to send in a CA tonight too,
> since I was planning on trying gsoc anyway.
>
>
> On Wednesday, February 12, 2014 6:44:08 AM UTC-5, Ambrose
> Bonnaire-Sergeant wrote:
>
>> Hi John,
>>
>> I gave it a whirl, it's exactly what I wanted.
>>
>> When you're ready please claim the bounty.
>>
>> Thanks,
>> Ambrose
>>
>> On Wed, Feb 12, 2014 at 4:46 PM, john walker wrote:
>>
>>> Well, that was easy to find. It will be fixed in the next version of
>>> clojure mode. If you are impatient, do
>>>
>>> C-h f clojure-match-next-def, click on clojure-mode.el
>>>
>>> and replace the line
>>>
>>>   (when (re-search-backward "^(def\sw*" nil t)
>>>
>>> with
>>>
>>>   (when (re-search-backward "^(def\\sw*" nil t)
>>>
>>> then recompile your clojure-mode.el. This probably will not exist after
>>> the February 1st snapshot. Source: https://github.com/clojure-
>>> emacs/clojure-mode/commit/32feee877233a4d98fb934dcbd42789e56dac790
>>>
>>>
>>> On Wednesday, February 12, 2014 3:24:12 AM UTC-5, john walker wrote:

 Added.

 The next big thing I see is fixing which-function.

 On Wednesday, February 12, 2014 3:07:44 AM UTC-5, Ambrose
 Bonnaire-Sergeant wrote:
>
> Hi John,
>
> I don't mind that ns-aliases can go out of date. Please use the output
> of ns-alias as authoritative, and make a documentation note of this quirk.
>
> Thanks,
> Ambrose
>
>
> On Wed, Feb 12, 2014 at 4:03 PM, john walker wrote:
>
>> Ahh, this turned out to be fairly interesting. My first thought was
>> to check the aliases using (ns-alias), but it turns out that 
>> re-evaluating
>> a namespace after removing the alias leaves the original aliases in 
>> place.
>> So I'm just going to use a regex, which is probably easier anyway.
>>
>>
>> On Wednesday, February 12, 2014 2:29:31 AM UTC-5, Ambrose
>> Bonnaire-Sergeant wrote:
>>
>>> Hi John,
>>>
>>> Wow! One thing, if clojure.core.typed is aliases in the current
>>> namespace, then the ann* refactor
>>> should use that alias. If there is no alias, then use the fully
>>> qualified namespace. If the var is
>>> referred into the current ns-map, then use the fully qualified
>>> namespace or a namespace alias prefix
>>> if available.
>>>
>>> Thanks,
>>> Ambrose
>>>
>>>
>>> On Wed, Feb 12, 2014 at 3:18 PM, john walker 
>>> wrote:
>>>
  I'm still on my first cup, so let me know what you think:

 https://github.com/johnwalker/typed-clojure-el


 On Tuesday, February 11, 2014 12:01:36 PM UTC-5, Ambrose
 Bonnaire-Sergeant wrote:
>
> Hi,
>
> I need a relatively straightforward Emacs plugin for Typed Clojure
> written.
>
> I'm offering a $200US bounty. If you would also like to see this,
> please bump up the $$.
>
> If you're interested in claiming, see the bounty 
> page
>  and
> the Jira issue  for
> a brief description. Please comment or email me if you are interested.
>
> Thanks,
> Ambrose
>
  --
 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 unsubscribe from this group and stop receiving emails from it,
 send an email to clojure+u...@googlegroups.com.

 For more options, visit https://groups.google.com/groups/opt_out.

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

Re: [$Bounty] Emacs plugin for Typed Clojure

2014-02-12 Thread Alex Ott
Hi John

it would be nice to add the

;;;###autoload

cookie for minor-mode definition...



On Wed, Feb 12, 2014 at 4:32 PM, john walker wrote:

> OK, thanks! I realigned the repository name / filename / modename to be
> both more correct and compliant with your fork. My version can now be seen
> here:
>
> https://github.com/johnwalker/typed-clojure-mode
>
> I didn't immediately see how to claim a bounty, but I see that the issue
> has to be marked as resolved first. I'm going to send in a CA tonight too,
> since I was planning on trying gsoc anyway.
>
>
> On Wednesday, February 12, 2014 6:44:08 AM UTC-5, Ambrose
> Bonnaire-Sergeant wrote:
>
>> Hi John,
>>
>> I gave it a whirl, it's exactly what I wanted.
>>
>> When you're ready please claim the bounty.
>>
>> Thanks,
>> Ambrose
>>
>> On Wed, Feb 12, 2014 at 4:46 PM, john walker wrote:
>>
>>> Well, that was easy to find. It will be fixed in the next version of
>>> clojure mode. If you are impatient, do
>>>
>>> C-h f clojure-match-next-def, click on clojure-mode.el
>>>
>>> and replace the line
>>>
>>>   (when (re-search-backward "^(def\sw*" nil t)
>>>
>>> with
>>>
>>>   (when (re-search-backward "^(def\\sw*" nil t)
>>>
>>> then recompile your clojure-mode.el. This probably will not exist after
>>> the February 1st snapshot. Source: https://github.com/clojure-
>>> emacs/clojure-mode/commit/32feee877233a4d98fb934dcbd42789e56dac790
>>>
>>>
>>> On Wednesday, February 12, 2014 3:24:12 AM UTC-5, john walker wrote:

 Added.

 The next big thing I see is fixing which-function.

 On Wednesday, February 12, 2014 3:07:44 AM UTC-5, Ambrose
 Bonnaire-Sergeant wrote:
>
> Hi John,
>
> I don't mind that ns-aliases can go out of date. Please use the output
> of ns-alias as authoritative, and make a documentation note of this quirk.
>
> Thanks,
> Ambrose
>
>
> On Wed, Feb 12, 2014 at 4:03 PM, john walker wrote:
>
>> Ahh, this turned out to be fairly interesting. My first thought was
>> to check the aliases using (ns-alias), but it turns out that 
>> re-evaluating
>> a namespace after removing the alias leaves the original aliases in 
>> place.
>> So I'm just going to use a regex, which is probably easier anyway.
>>
>>
>> On Wednesday, February 12, 2014 2:29:31 AM UTC-5, Ambrose
>> Bonnaire-Sergeant wrote:
>>
>>> Hi John,
>>>
>>> Wow! One thing, if clojure.core.typed is aliases in the current
>>> namespace, then the ann* refactor
>>> should use that alias. If there is no alias, then use the fully
>>> qualified namespace. If the var is
>>> referred into the current ns-map, then use the fully qualified
>>> namespace or a namespace alias prefix
>>> if available.
>>>
>>> Thanks,
>>> Ambrose
>>>
>>>
>>> On Wed, Feb 12, 2014 at 3:18 PM, john walker 
>>> wrote:
>>>
  I'm still on my first cup, so let me know what you think:

 https://github.com/johnwalker/typed-clojure-el


 On Tuesday, February 11, 2014 12:01:36 PM UTC-5, Ambrose
 Bonnaire-Sergeant wrote:
>
> Hi,
>
> I need a relatively straightforward Emacs plugin for Typed Clojure
> written.
>
> I'm offering a $200US bounty. If you would also like to see this,
> please bump up the $$.
>
> If you're interested in claiming, see the bounty 
> page
>  and
> the Jira issue  for
> a brief description. Please comment or email me if you are interested.
>
> Thanks,
> Ambrose
>
  --
 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 unsubscribe from this group and stop receiving emails from it,
 send an email to clojure+u...@googlegroups.com.

 For more options, visit https://groups.google.com/groups/opt_out.

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

Re: meta circular clojure

2014-02-12 Thread Herwig Hochleitner
2014-02-12 5:18 GMT+01:00 t x :

>
>   If no such evaluator exists, where is the complexity of a
> clojure-in-clojure evaluator that I failed to mention above?
>

Clojure is a compiled language. This means that even if you leave out any
platform issues like bytecode generation, there is still an analysis phase
separate from evaluation.
The most visible effect of this in terms of language semantics is, that
every name in a given piece of code has to be fully resolved (to a lexical
binding, a namespace var or a class) when it is analyzed/compiled, before
evaluation can begin.
Thus the need for declare in case of circular call graphs.

That's not to say that a clojure analyzer and interpreter couldn't fit on
2-3 pages of code (depending on your page size and choice of font :-). I
believe the CLJS analyzer isn't that much larger (or used not to be,
anyway).

cheers

-- 
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: [$Bounty] Emacs plugin for Typed Clojure

2014-02-12 Thread john walker
Thanks Alex, I've added this.

On Wednesday, February 12, 2014 10:39:49 AM UTC-5, Alex Ott wrote:
>
> Hi John
>
> it would be nice to add the 
>
> ;;;###autoload
>
> cookie for minor-mode definition...
>
>
>
> On Wed, Feb 12, 2014 at 4:32 PM, john walker 
> 
> > wrote:
>
>> OK, thanks! I realigned the repository name / filename / modename to be 
>> both more correct and compliant with your fork. My version can now be seen 
>> here:
>>
>> https://github.com/johnwalker/typed-clojure-mode
>>
>> I didn't immediately see how to claim a bounty, but I see that the issue 
>> has to be marked as resolved first. I'm going to send in a CA tonight too, 
>> since I was planning on trying gsoc anyway.
>>
>>
>> On Wednesday, February 12, 2014 6:44:08 AM UTC-5, Ambrose 
>> Bonnaire-Sergeant wrote:
>>
>>> Hi John,
>>>
>>> I gave it a whirl, it's exactly what I wanted.
>>>
>>> When you're ready please claim the bounty.
>>>
>>> Thanks,
>>> Ambrose
>>>
>>> On Wed, Feb 12, 2014 at 4:46 PM, john walker wrote:
>>>
 Well, that was easy to find. It will be fixed in the next version of 
 clojure mode. If you are impatient, do

 C-h f clojure-match-next-def, click on clojure-mode.el

 and replace the line

   (when (re-search-backward "^(def\sw*" nil t)

 with

   (when (re-search-backward "^(def\\sw*" nil t)

 then recompile your clojure-mode.el. This probably will not exist after 
 the February 1st snapshot. Source: https://github.com/clojure-
 emacs/clojure-mode/commit/32feee877233a4d98fb934dcbd42789e56dac790


 On Wednesday, February 12, 2014 3:24:12 AM UTC-5, john walker wrote:
>
> Added.
>
> The next big thing I see is fixing which-function. 
>
> On Wednesday, February 12, 2014 3:07:44 AM UTC-5, Ambrose 
> Bonnaire-Sergeant wrote:
>>
>> Hi John,
>>
>> I don't mind that ns-aliases can go out of date. Please use the 
>> output of ns-alias as authoritative, and make a documentation note of 
>> this 
>> quirk.
>>
>> Thanks,
>> Ambrose 
>>
>>
>> On Wed, Feb 12, 2014 at 4:03 PM, john walker wrote:
>>
>>> Ahh, this turned out to be fairly interesting. My first thought was 
>>> to check the aliases using (ns-alias), but it turns out that 
>>> re-evaluating 
>>> a namespace after removing the alias leaves the original aliases in 
>>> place. 
>>> So I'm just going to use a regex, which is probably easier anyway.
>>>
>>>
>>> On Wednesday, February 12, 2014 2:29:31 AM UTC-5, Ambrose 
>>> Bonnaire-Sergeant wrote:
>>>
 Hi John,

 Wow! One thing, if clojure.core.typed is aliases in the current 
 namespace, then the ann* refactor
 should use that alias. If there is no alias, then use the fully 
 qualified namespace. If the var is
 referred into the current ns-map, then use the fully qualified 
 namespace or a namespace alias prefix
 if available.

 Thanks,
 Ambrose


 On Wed, Feb 12, 2014 at 3:18 PM, john walker 
 wrote:

>  I'm still on my first cup, so let me know what you think:
>
> https://github.com/johnwalker/typed-clojure-el
>  
>
> On Tuesday, February 11, 2014 12:01:36 PM UTC-5, Ambrose 
> Bonnaire-Sergeant wrote:
>>
>> Hi,
>>
>> I need a relatively straightforward Emacs plugin for Typed 
>> Clojure written.
>>
>> I'm offering a $200US bounty. If you would also like to see this, 
>> please bump up the $$.
>>
>> If you're interested in claiming, see the bounty 
>> page
>>  and 
>> the Jira issue  for 
>> a brief description. Please comment or email me if you are 
>> interested.
>>
>> Thanks,
>> Ambrose
>>
>  -- 
> 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 unsubscribe from this group and stop receiving emails from it, 
> send an email to clojure+u...@googlegroups.com.
>
> For more options, visit https://groups.google.com/groups/opt_out.
>
>>

Keyword equality check

2014-02-12 Thread Arkadiusz Komarzewski
Hi,

I wonder how is equality of keywords implemented in Clojure?

I have this piece of Java code executed in one classloader:
Keyword a = (Keyword) RT.var("clojure.core", "keyword").invoke("keyword");

Then, when I pass it to another part of my application (which uses another 
classloader) and do this:
Keyword b = (Keyword) RT.var("clojure.core", "keyword").invoke("keyword");
assert a == b;

Assertion passes.
Why does it work? If I'm correct, keywords are interned, but since they 
were created in separate classloaders shouldn't that assert fail?

-- 
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: Keyword equality check

2014-02-12 Thread Jozef Wagner
Interning table uses keyword's symbol as a key, and the symbols are
compared by value. See
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Keyword.java#L37


On Wed, Feb 12, 2014 at 5:23 PM, Arkadiusz Komarzewski <
akomarzew...@gmail.com> wrote:

> Hi,
>
> I wonder how is equality of keywords implemented in Clojure?
>
> I have this piece of Java code executed in one classloader:
> Keyword a = (Keyword) RT.var("clojure.core", "keyword").invoke("keyword");
>
> Then, when I pass it to another part of my application (which uses another
> classloader) and do this:
> Keyword b = (Keyword) RT.var("clojure.core", "keyword").invoke("keyword");
> assert a == b;
>
> Assertion passes.
> Why does it work? If I'm correct, keywords are interned, but since they
> were created in separate classloaders shouldn't that assert fail?
>
> --
> 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.
>

-- 
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: [$Bounty] Emacs plugin for Typed Clojure

2014-02-12 Thread john walker
I don't actually know yet. I have an idea that I'll submit ~Saturday that 
could be pretty cool.

On Wednesday, February 12, 2014 10:37:31 AM UTC-5, Ambrose 
Bonnaire-Sergeant wrote:
>
> I guess it takes awhile to propagate to BountySource.
>
> Did you have any projects in mind for GSoC? Perhaps more Typed Clojure 
> work?
>
> Thanks,
> Ambrose
>
> On Wed, Feb 12, 2014 at 11:32 PM, john walker 
> 
> > wrote:
>
>> OK, thanks! I realigned the repository name / filename / modename to be 
>> both more correct and compliant with your fork. My version can now be seen 
>> here:
>>
>> https://github.com/johnwalker/typed-clojure-mode
>>
>> I didn't immediately see how to claim a bounty, but I see that the issue 
>> has to be marked as resolved first. I'm going to send in a CA tonight too, 
>> since I was planning on trying gsoc anyway.
>>
>>
>> On Wednesday, February 12, 2014 6:44:08 AM UTC-5, Ambrose 
>> Bonnaire-Sergeant wrote:
>>
>>> Hi John,
>>>
>>> I gave it a whirl, it's exactly what I wanted.
>>>
>>> When you're ready please claim the bounty.
>>>
>>> Thanks,
>>> Ambrose
>>>
>>> On Wed, Feb 12, 2014 at 4:46 PM, john walker wrote:
>>>
 Well, that was easy to find. It will be fixed in the next version of 
 clojure mode. If you are impatient, do

 C-h f clojure-match-next-def, click on clojure-mode.el

 and replace the line

   (when (re-search-backward "^(def\sw*" nil t)

 with

   (when (re-search-backward "^(def\\sw*" nil t)

 then recompile your clojure-mode.el. This probably will not exist after 
 the February 1st snapshot. Source: https://github.com/clojure-
 emacs/clojure-mode/commit/32feee877233a4d98fb934dcbd42789e56dac790


 On Wednesday, February 12, 2014 3:24:12 AM UTC-5, john walker wrote:
>
> Added.
>
> The next big thing I see is fixing which-function. 
>
> On Wednesday, February 12, 2014 3:07:44 AM UTC-5, Ambrose 
> Bonnaire-Sergeant wrote:
>>
>> Hi John,
>>
>> I don't mind that ns-aliases can go out of date. Please use the 
>> output of ns-alias as authoritative, and make a documentation note of 
>> this 
>> quirk.
>>
>> Thanks,
>> Ambrose 
>>
>>
>> On Wed, Feb 12, 2014 at 4:03 PM, john walker wrote:
>>
>>> Ahh, this turned out to be fairly interesting. My first thought was 
>>> to check the aliases using (ns-alias), but it turns out that 
>>> re-evaluating 
>>> a namespace after removing the alias leaves the original aliases in 
>>> place. 
>>> So I'm just going to use a regex, which is probably easier anyway.
>>>
>>>
>>> On Wednesday, February 12, 2014 2:29:31 AM UTC-5, Ambrose 
>>> Bonnaire-Sergeant wrote:
>>>
 Hi John,

 Wow! One thing, if clojure.core.typed is aliases in the current 
 namespace, then the ann* refactor
 should use that alias. If there is no alias, then use the fully 
 qualified namespace. If the var is
 referred into the current ns-map, then use the fully qualified 
 namespace or a namespace alias prefix
 if available.

 Thanks,
 Ambrose


 On Wed, Feb 12, 2014 at 3:18 PM, john walker 
 wrote:

>  I'm still on my first cup, so let me know what you think:
>
> https://github.com/johnwalker/typed-clojure-el
>  
>
> On Tuesday, February 11, 2014 12:01:36 PM UTC-5, Ambrose 
> Bonnaire-Sergeant wrote:
>>
>> Hi,
>>
>> I need a relatively straightforward Emacs plugin for Typed 
>> Clojure written.
>>
>> I'm offering a $200US bounty. If you would also like to see this, 
>> please bump up the $$.
>>
>> If you're interested in claiming, see the bounty 
>> page
>>  and 
>> the Jira issue  for 
>> a brief description. Please comment or email me if you are 
>> interested.
>>
>> Thanks,
>> Ambrose
>>
>  -- 
> 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 unsubscribe from this group and stop receiving emails from it, 
> send an 

Re: meta circular clojure

2014-02-12 Thread Herwig Hochleitner
2014-02-12 5:36 GMT+01:00 Di Xu :

>
>  all lisp dialect provide `read` function, so if you want to build an
> evaluator, you could just use this function and don't need to do lexical
> and syntax analysis.
>

Maybe your understanding of these terms is different from mine, in my view:
A lisp evaluator needs to do syntactic and lexical analysis. Those are both
performed after the data structures have been parsed by `read` and then
macroexpanded by the compiler. Macroexpansion could be considered part of
syntactic analysis for most macros.

Read doesn't do any analysis at all. Usually it's completely independent
from language semantics.
In clojure, there is a slight complexion in the form of syntax-quote (`)
which uses the compilation environment to determine symbol namespaces.


# Example

;; this is the primitive let* form, to which let macroexpands
(let* [a (init a b c)] (process a))

Both kinds of analyses (syntactic, lexical) have to be done by every
compiler or evaluator at some point. Compilers tend to do it during compile
time.

## Syntactic Analysis:

Here syntax analysis mandates that the second parameter is a literal vector
with (mod ... 2) elements and a symbol w.o. namespace as every second
element.

If this condition is not met, the compiler can and should fail with a
syntax error

## Lexical Analysis:

Lexical analysis will try to resolve the names `init`, `process`, `b`, `c`
to either their innermost lexical bindings or namespace vars or refers.
The outer `a` that `init` is called with, is also resolved to an outside
binding. The inner `a` (argument to `process`) is always bound to it's
(lexical) rebinding in the let* form.

In this phase, unbound-name errors are thrown if the analyzer can't find
the origin of a binding.

hope someone finds this nitpick useful
kind regards

-- 
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: Keyword equality check

2014-02-12 Thread Herwig Hochleitner
I'm willing to bet that both classloaders have the same clojure runtime in
a common base classloader.
i.e. that cl1.loadClass("clojure.lang.RT") ==
cl2.loadClass("clojure.lang.RT");

If the two clojure runtimes were distinct, the assert would indeed fail.
Also .equals return false and this assignment would fail: Keyword kw =
getKwFromDifferentClassloader();
This would work: Object kw = getKwFromDifferentClassloader();

See here:
http://stackoverflow.com/questions/5375349/class-instance-obtained-through-multiple-class-loader

For reference: This is a printout of the return value of nrepl/start-server
in a completely separated classloader, save for bootstrap classes in the
java library (an architecture that I use for my services)

{# #,
 # 4003,
 # #,
 # #,
 # nil,
 # #,
 # #}

Notice how the printer prints out the {} correctly, because it dispatches
on java.util.Map (a common base class from the bootstrap classloader), but
fails to recognize the Keywords of a different clojure runtime.
>From experiments, I can assure you that (not= :port #)
Similarly, assoc on this map would fail, because it's only recognized as a
j.u.Map, but not as a c.l.PersistentMap.

cheers


2014-02-12 17:45 GMT+01:00 Jozef Wagner :

> Interning table uses keyword's symbol as a key, and the symbols are
> compared by value. See
> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Keyword.java#L37
>
>
> On Wed, Feb 12, 2014 at 5:23 PM, Arkadiusz Komarzewski <
> akomarzew...@gmail.com> wrote:
>
>> Hi,
>>
>> I wonder how is equality of keywords implemented in Clojure?
>>
>> I have this piece of Java code executed in one classloader:
>> Keyword a = (Keyword) RT.var("clojure.core", "keyword").invoke("keyword");
>>
>> Then, when I pass it to another part of my application (which uses
>> another classloader) and do this:
>> Keyword b = (Keyword) RT.var("clojure.core", "keyword").invoke("keyword");
>> assert a == b;
>>
>> Assertion passes.
>> Why does it work? If I'm correct, keywords are interned, but since they
>> were created in separate classloaders shouldn't that assert fail?
>>
>> --
>> 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.
>>
>
>  --
> 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.
>

-- 
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] zcube 0.0.1

2014-02-12 Thread Fabien Todescato


Hi, clojure community. It is my pleasure to announce zcube[1], a Clojure 
library all about counting trees for analytical purposes.

The intent is to compute aggregate sums over multiple hierarchical dimensions, 
based on the (old) algorithmic ideas exposed in [2] by Pr. Minato et Al, and 
implemented in an immutable setting suitable for concurrent and functional 
programming.

Feedback welcome, thanks.

[1]https://github.com/ftod/zcube
[2]http://www-alg.ist.hokudai.ac.jp/~thomas/TCSTR/tcstr_05_3/tcstr_05_3.pdf

-- 
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: range-sum

2014-02-12 Thread Vincent
On Wednesday, February 12, 2014 2:47:07 PM UTC, Stuart Sierra wrote:
>
> On Wednesday, February 12, 2014 8:46:41 AM UTC-5, Vincent wrote:
>>
>> On a slightly different topic: why reduce and not apply?
>>
>
> The implementation of `+` with more than 2 arguments uses `reduce` 
> internally. So they amount to the same thing.
>

Ah ok, interesting. I do seem to have, in the past, come across a function 
that was significantly faster when used with apply rather than reduce, but 
I can't remember which one.



> There isn't really a performance difference:
>
> user=> (dotimes [i 7] (time (reduce + (range 1000
> "Elapsed time: 354.475 msecs"
> "Elapsed time: 346.235 msecs"
> "Elapsed time: 348.124 msecs"
> "Elapsed time: 348.894 msecs"
> "Elapsed time: 379.9 msecs"
> "Elapsed time: 356.337 msecs"
> "Elapsed time: 362.788 msecs"
> nil
> user=> (dotimes [i 7] (time (apply + (range 1000
> "Elapsed time: 360.067 msecs"
> "Elapsed time: 353.281 msecs"
> "Elapsed time: 345.694 msecs"
> "Elapsed time: 355.162 msecs"
> "Elapsed time: 346.511 msecs"
> "Elapsed time: 350.61 msecs"
> "Elapsed time: 353.674 msecs"
> nil
>

Thanks,
Vincent 

-- 
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: range-sum

2014-02-12 Thread John Wiseman
In the olden lisp days, reduce was often preferred to apply because apply
could hit limits on the number of arguments that could be passed to a
function.  Is that a potential issue with clojure?

Thanks,
John



On Wed, Feb 12, 2014 at 12:06 PM, Vincent  wrote:

> On Wednesday, February 12, 2014 2:47:07 PM UTC, Stuart Sierra wrote:
>>
>> On Wednesday, February 12, 2014 8:46:41 AM UTC-5, Vincent wrote:
>>>
>>> On a slightly different topic: why reduce and not apply?
>>>
>>
>> The implementation of `+` with more than 2 arguments uses `reduce`
>> internally. So they amount to the same thing.
>>
>
> Ah ok, interesting. I do seem to have, in the past, come across a function
> that was significantly faster when used with apply rather than reduce, but
> I can't remember which one.
>
>
>
>> There isn't really a performance difference:
>>
>> user=> (dotimes [i 7] (time (reduce + (range 1000
>> "Elapsed time: 354.475 msecs"
>> "Elapsed time: 346.235 msecs"
>> "Elapsed time: 348.124 msecs"
>> "Elapsed time: 348.894 msecs"
>> "Elapsed time: 379.9 msecs"
>> "Elapsed time: 356.337 msecs"
>> "Elapsed time: 362.788 msecs"
>> nil
>> user=> (dotimes [i 7] (time (apply + (range 1000
>> "Elapsed time: 360.067 msecs"
>> "Elapsed time: 353.281 msecs"
>> "Elapsed time: 345.694 msecs"
>> "Elapsed time: 355.162 msecs"
>> "Elapsed time: 346.511 msecs"
>> "Elapsed time: 350.61 msecs"
>> "Elapsed time: 353.674 msecs"
>> nil
>>
>
> Thanks,
> Vincent
>
> --
> 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.
>

-- 
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: range-sum

2014-02-12 Thread Sean Corfield
On Feb 12, 2014, at 5:46 AM, Vincent  wrote:
> On Friday, February 7, 2014 2:23:33 AM UTC, Sean Corfield wrote:
> On Feb 6, 2014, at 12:58 PM, Stuart Sierra  wrote:
>> I think (reduce + (range N)) is commonly used in *examples*, not necessarily 
>> in real applications.
> I'd have to agree: I don't see anything like that in our 20kloc at World 
> Singles. I see a handful of (reduce + data) for arbitrary series of data 
> values.
> On a slightly different topic: why reduce and not apply?

Stuart addressed the performance (non-)issue but I think the intent of (reduce 
+ data) is much clearer than (apply + data). To me, apply says "I have 
arbitrary arguments that I've constructed programmatically and now I want to 
call a function with those arguments" whereas reduce says "I have a collection 
and want to apply this function cumulatively across that collection".

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)





signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: cond-> variant?

2014-02-12 Thread Sean Corfield
On Feb 12, 2014, at 1:34 AM, Alex Baranosky  
wrote:
> I wrote pred-cond for Midje way back, which does what you want. 
> https://github.com/marick/Midje/blob/master/src/midje/clojure/core.clj#L176

That doesn't appear to thread each expression through the "results" so it isn't 
really a variant of cond-> but between that and the source of cond-> I suspect 
I will just end up rolling my own...

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)





signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: cond-> variant?

2014-02-12 Thread Sean Corfield
Here's what I ended up with - minor variants of cond-> and cond->>

(defmacro condp->
  "Takes an expression and a set of predicate/form pairs. Threads expr (via ->)
  through each form for which the corresponding predicate is true of expr.
  Note that, unlike cond branching, condp-> threading does not short circuit
  after the first true test expression."
  [expr & clauses]
  (assert (even? (count clauses)))
  (let [g (gensym)
pstep (fn [[pred step]] `(if (~pred ~g) (-> ~g ~step) ~g))]
`(let [~g ~expr
   ~@(interleave (repeat g) (map pstep (partition 2 clauses)))]
   ~g)))

(defmacro condp->>
  "Takes an expression and a set of predicate/form pairs. Threads expr (via ->>)
  through each form for which the corresponding predicate is true of expr.
  Note that, unlike cond branching, condp->> threading does not short circuit
  after the first true test expression."
  [expr & clauses]
  (assert (even? (count clauses)))
  (let [g (gensym)
pstep (fn [[pred step]] `(if (~pred ~g) (->> ~g ~step) ~g))]
`(let [~g ~expr
   ~@(interleave (repeat g) (map pstep (partition 2 clauses)))]
   ~g)))

On Feb 12, 2014, at 2:34 PM, Sean Corfield  wrote:

> On Feb 12, 2014, at 1:34 AM, Alex Baranosky  
> wrote:
>> I wrote pred-cond for Midje way back, which does what you want. 
>> https://github.com/marick/Midje/blob/master/src/midje/clojure/core.clj#L176
> 
> That doesn't appear to thread each expression through the "results" so it 
> isn't really a variant of cond-> but between that and the source of cond-> I 
> suspect I will just end up rolling my own...





signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: range-sum

2014-02-12 Thread Mars0i


On Wednesday, February 12, 2014 2:33:34 PM UTC-6, John Wiseman wrote:
>
> In the olden lisp days, reduce was often preferred to apply because apply 
> could hit limits on the number of arguments that could be passed to a 
> function.  
>

Still an issue with some Common Lisps.  I've hit the limit in CLISP and 
LispWorks, but several other Common Lisps, including my favorite, SBCL, 
don't seem to have a limit.
 

> Is that a potential issue with clojure?
>

(range 1)

Then copy its output from the terminal window.

(apply + ' )

CompilerException java.lang.ClassFormatError: Invalid method Code length 
109957 in class file user$eval1179, 
compiling:(/private/var/folders/AV/AVc7bySmE4a+vcamS7JSTE+++TQ/-Tmp-/form-init2649824128421176665.clj:1: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 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: Keyword equality check

2014-02-12 Thread Alex Miller
I think it's a little more subtle than that.  Symbols are composed of a 
String name and a String namespace. When symbols are created they intern 
each of those Strings. Interned Strings are comparable by identity across 
the JVM. Symbol equals() compares name and namespace. Keyword extends from 
Symbol and calls into the Symbol interning and inherits the equals() 
implementation. 

As Jozef mentions, the Keyword intern table is held in a static map in 
Keyword and that would not be shared if you had multiple Clojure 
classloaders. However, I think the Keyword intern table is largely to avoid 
creating multiple instances of the same Keyword (as well as safely cleaning 
them up if no one is using them anymore). This is all irrelevant for the 
equality comparison in the original post.


On Wednesday, February 12, 2014 10:45:38 AM UTC-6, Jozef Wagner wrote:
>
> Interning table uses keyword's symbol as a key, and the symbols are 
> compared by value. See 
> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Keyword.java#L37
>
>
> On Wed, Feb 12, 2014 at 5:23 PM, Arkadiusz Komarzewski <
> akomar...@gmail.com > wrote:
>
>> Hi,
>>
>> I wonder how is equality of keywords implemented in Clojure?
>>
>> I have this piece of Java code executed in one classloader:
>> Keyword a = (Keyword) RT.var("clojure.core", "keyword").invoke("keyword");
>>
>> Then, when I pass it to another part of my application (which uses 
>> another classloader) and do this:
>> Keyword b = (Keyword) RT.var("clojure.core", "keyword").invoke("keyword");
>> assert a == b;
>>
>> Assertion passes.
>> Why does it work? If I'm correct, keywords are interned, but since they 
>> were created in separate classloaders shouldn't that assert fail?
>>  
>> -- 
>> 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 unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

-- 
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: range-sum

2014-02-12 Thread Mars0i


On Wednesday, February 12, 2014 5:14:42 PM UTC-6, Mars0i wrote:

> On Wednesday, February 12, 2014 2:33:34 PM UTC-6, John Wiseman wrote:
>>
>> Is that a potential issue with clojure?
>>
>
> (range 1)
>
> Then copy its output from the terminal window.
>
> (apply + ' )
>
> CompilerException java.lang.ClassFormatError: Invalid method Code length 
> 109957 in class file user$eval1179, 
> compiling:(/private/var/folders/AV/AVc7bySmE4a+vcamS7JSTE+++TQ/-Tmp-/form-init2649824128421176665.clj:1:1)
>  
>
>

But '(reduce  +' has the same difficulty.  The limit was somewhere between 
5000 and 8000 arguments.  I can live with 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
--- 
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: Keyword equality check

2014-02-12 Thread Alex Miller
Reading a little more closely, that's an identity comparison in Java, not 
an equals comparison in Clojure (who uses Java anyways? :). So I would 
retract my last statement. The question is really whether the two 
classloaders are deferring the load of the common class to a parent 
classloader that loads the same Keyword class. You can ask the Keyword 
classes you have for their classloader and then look through the parents to 
investigate that question.



On Wednesday, February 12, 2014 5:32:07 PM UTC-6, Alex Miller wrote:
>
> I think it's a little more subtle than that.  Symbols are composed of a 
> String name and a String namespace. When symbols are created they intern 
> each of those Strings. Interned Strings are comparable by identity across 
> the JVM. Symbol equals() compares name and namespace. Keyword extends from 
> Symbol and calls into the Symbol interning and inherits the equals() 
> implementation. 
>
> As Jozef mentions, the Keyword intern table is held in a static map in 
> Keyword and that would not be shared if you had multiple Clojure 
> classloaders. However, I think the Keyword intern table is largely to avoid 
> creating multiple instances of the same Keyword (as well as safely cleaning 
> them up if no one is using them anymore). This is all irrelevant for the 
> equality comparison in the original post.
>
>
> On Wednesday, February 12, 2014 10:45:38 AM UTC-6, Jozef Wagner wrote:
>>
>> Interning table uses keyword's symbol as a key, and the symbols are 
>> compared by value. See 
>> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Keyword.java#L37
>>
>>
>> On Wed, Feb 12, 2014 at 5:23 PM, Arkadiusz Komarzewski <
>> akomar...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I wonder how is equality of keywords implemented in Clojure?
>>>
>>> I have this piece of Java code executed in one classloader:
>>> Keyword a = (Keyword) RT.var("clojure.core", 
>>> "keyword").invoke("keyword");
>>>
>>> Then, when I pass it to another part of my application (which uses 
>>> another classloader) and do this:
>>> Keyword b = (Keyword) RT.var("clojure.core", 
>>> "keyword").invoke("keyword");
>>> assert a == b;
>>>
>>> Assertion passes.
>>> Why does it work? If I'm correct, keywords are interned, but since they 
>>> were created in separate classloaders shouldn't that assert fail?
>>>  
>>> -- 
>>> 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 unsubscribe from this group and stop receiving emails from it, send 
>>> an email to clojure+u...@googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>>

-- 
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: range-sum

2014-02-12 Thread John Wiseman
Just to be clear, and to check my understanding, that's not an issue with
the number of arguments, right?  It's a limit on the size of a literal or
something?

I ask because (apply + (range 1)) works fine, but maybe I've missed
some subtlety.

Thanks,
John



On Wed, Feb 12, 2014 at 3:32 PM, Mars0i  wrote:

>
>
> On Wednesday, February 12, 2014 5:14:42 PM UTC-6, Mars0i wrote:
>
>> On Wednesday, February 12, 2014 2:33:34 PM UTC-6, John Wiseman wrote:
>>
>>> Is that a potential issue with clojure?
>>>
>>
>> (range 1)
>>
>> Then copy its output from the terminal window.
>>
>> (apply + ' )
>>
>> CompilerException java.lang.ClassFormatError: Invalid method Code length
>> 109957 in class file user$eval1179, compiling:(/private/var/
>> folders/AV/AVc7bySmE4a+vcamS7JSTE+++TQ/-Tmp-/form-
>> init2649824128421176665.clj:1:1)
>>
>
> But '(reduce  +' has the same difficulty.  The limit was somewhere between
> 5000 and 8000 arguments.  I can live with 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
> ---
> 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.
>

-- 
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: range-sum

2014-02-12 Thread Mars0i
Good question.  I don't know.  Maybe it's in the read stage, rather than in 
evaluating arguments for + ?

On Wednesday, February 12, 2014 5:43:18 PM UTC-6, John Wiseman wrote:
>
> Just to be clear, and to check my understanding, that's not an issue with 
> the number of arguments, right?  It's a limit on the size of a literal or 
> something?
>
> I ask because (apply + (range 1)) works fine, but maybe I've missed 
> some subtlety.
>
> Thanks,
> John
>
>
>
> On Wed, Feb 12, 2014 at 3:32 PM, Mars0i 
> > wrote:
>
>>
>>
>> On Wednesday, February 12, 2014 5:14:42 PM UTC-6, Mars0i wrote:
>>
>>> On Wednesday, February 12, 2014 2:33:34 PM UTC-6, John Wiseman wrote:
>>>
 Is that a potential issue with clojure?

>>>
>>> (range 1)
>>>
>>> Then copy its output from the terminal window.
>>>
>>> (apply + ' )
>>>
>>> CompilerException java.lang.ClassFormatError: Invalid method Code length 
>>> 109957 in class file user$eval1179, compiling:(/private/var/
>>> folders/AV/AVc7bySmE4a+vcamS7JSTE+++TQ/-Tmp-/form-
>>> init2649824128421176665.clj:1:1) 
>>>
>>
>> But '(reduce  +' has the same difficulty.  The limit was somewhere 
>> between 5000 and 8000 arguments.  I can live with that.
>>
>> -- 
>> 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 unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

-- 
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: [ANN] zcube 0.0.1

2014-02-12 Thread Timothy Washington
+1

I can already think of a few places I'd like to try this. Looks very cool.


Tim Washington
Interruptsoftware.com 


On Wed, Feb 12, 2014 at 1:13 PM, Fabien Todescato  wrote:

> Hi, clojure community. It is my pleasure to announce zcube[1], a Clojure 
> library all about counting trees for analytical purposes.
>
> The intent is to compute aggregate sums over multiple hierarchical 
> dimensions, based on the (old) algorithmic ideas exposed in [2] by Pr. Minato 
> et Al, and implemented in an immutable setting suitable for concurrent and 
> functional programming.
>
> Feedback welcome, thanks.
>
> [1]https://github.com/ftod/zcube
> [2]http://www-alg.ist.hokudai.ac.jp/~thomas/TCSTR/tcstr_05_3/tcstr_05_3.pdf
>
>  --
> 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.
>

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