problem compiling a file from with in slime while it works fine when I do a lein jar

2012-06-09 Thread Sunil S Nandihalli
Hi Everybody,
 I am trying to write a code using the thrift in clojure. The files
generated by thrift are present and I am able to run lein jar and it
successfully creates a jar. but when I am inside emacs and I try to do C-c
C-k it fails to load(import) the class file corresponding to one of the
classes generated by thrift. Can somebody help me as to how I can fix this.
I am able to do run the code as-well using "lein run" . So, the only
problem is I am unable to work with it interactively in slime. Can somebody
help me fix this problem?
Thanks
Sunil.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Doseq, map-style

2012-06-09 Thread Baishampayan Ghose
> I would love to have a version of doseq that works like map (similar to
> "each" in other dynamic languages). In other words, instead of (doseq [log
> logs] (println log)), I would say something like (each println logs).
>
> Is there a built-in Clojure method that works like this?

Since Clojure 1.4 you can try mapv. mapv is like map but returns a
vector of results and hence is not lazy. There is also filterv which
works similarly.

Regards,
BG

-- 
Baishampayan Ghose
b.ghose at gmail.com

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en


Re: Explaining the thrush -> operator.

2012-06-09 Thread Baishampayan Ghose
Technically speaking, the -> & ->> macros are _not_ the thrush
combinators. Fogus wrote about them sometime back
http://blog.fogus.me/2010/09/28/thrush-in-clojure-redux/ and I think
you should mention that in your document too.

Nevertheless, very useful document!

Regards,
BG

On Fri, Jun 8, 2012 at 11:32 PM, fenton  wrote:
> I created a tutorial explaining what the thrush -> and ->> operator is.
>
> https://github.com/ftravers/PublicDocumentation/blob/master/clojure-thrush.md
>
> My tutorials are aimed at people who appreciate VERY explicit explanations,
> which I think there is a bit of a gap among current internet available
> literature.
>
> --
> 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



-- 
Baishampayan Ghose
b.ghose at gmail.com

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en


AW: Re: Doseq, map-style

2012-06-09 Thread Meikel Brandmeyer
Hi,

the doseq has the additional benefit of its ugliness which makes side-effects 
stand out. ;)

Kind regards
Meikel

-Ursprüngliche Nachricht-
Von: Sean Corfield 
An: clojure@googlegroups.com
Gesendet: Sa, 09 Jun 2012, 04:50:53 MESZ
Betreff: Re: Doseq, map-style

On Thu, Jun 7, 2012 at 8:32 PM, David Jacobs  wrote:
> I would love to have a version of doseq that works like map (similar to
> "each" in other dynamic languages). In other words, instead of (doseq [log
> logs] (println log)), I would say something like (each println logs).

Since that implies a side-effecting function, I'm curious as to how
much that would really be needed in Clojure?
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"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 post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Re: Doseq, map-style

2012-06-09 Thread Baishampayan Ghose
On Sat, Jun 9, 2012 at 6:13 PM, Meikel Brandmeyer  wrote:
> the doseq has the additional benefit of its ugliness which makes
> side-effects stand out. ;)

+1

Regards,
BG

-- 
Baishampayan Ghose
b.ghose at gmail.com

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en


Re: load namespace programmatically

2012-06-09 Thread Leandro Oliveira
Yes. Thank you Andy.

[ ]s
Leandro.

On Fri, Jun 8, 2012 at 10:18 PM, Andy Fingerhut wrote:

> Does this do what you want?
>
> (defn require-from-string [s]
>  (require (symbol s)))
>
> Andy
>
> On Jun 8, 2012, at 5:37 PM, Leandro Oliveira wrote:
>
> > Hi,
> >
> > What is the best way to implement require-from-string?
> >
> > Ex:
> >
> > # require-from-string words like require but accepts namespaces as
> strings.
> >
> > (def namespace-from-user  (ask-user))
> > (require-from-string namespace-from-user)
> >
> > # now the namespace chosen by user is loaded.
> >
> >
> >
> > Best regards
> >
> > [ ]s
> > Leandro.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Doseq, map-style

2012-06-09 Thread Jim - FooBar();

Why not make it yourself? Something like this perhaps?

(defmacro doeach [f coll]
`(doseq [x# ~coll] (~f x#)))

Itis good if you name it "doeach" instead of each to imply side-effects 
(just like doseq)...


Hope that helps...

Jim


On 08/06/12 04:32, David Jacobs wrote:
I would love to have a version of doseq that works like map (similar 
to "each" in other dynamic languages). In other words, instead of 
(doseq [log logs] (println log)), I would say something like (each 
println logs).


Is there a built-in Clojure method that works like this?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient 
with your first post.

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en 


--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en


Re: Doseq, map-style

2012-06-09 Thread Jim - FooBar();

I just saw this has been already answered! I apologise for the noise!

Jim

On 09/06/12 16:45, Jim - FooBar(); wrote:

Why not make it yourself? Something like this perhaps?

(defmacro doeach [f coll]
`(doseq [x# ~coll] (~f x#)))

Itis good if you name it "doeach" instead of each to imply 
side-effects (just like doseq)...


Hope that helps...

Jim


On 08/06/12 04:32, David Jacobs wrote:
I would love to have a version of doseq that works like map (similar 
to "each" in other dynamic languages). In other words, instead of 
(doseq [log logs] (println log)), I would say something like (each 
println logs).


Is there a built-in Clojure method that works like this?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient 
with your first post.

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en 




--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en


Re: Is still idiomatic the ant simulation code?

2012-06-09 Thread JuanManuel Gimeno Illa
Can you elaborate some suggestions?

Juan Manuel

On Friday, June 8, 2012 3:44:16 PM UTC+2, Stuart Sierra wrote:
>
> The ants demo is definitely dated. It's not terrible, but the code could 
> use some polishing/simplifying using newer additions to the language.
> -S
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Explaining the thrush -> operator.

2012-06-09 Thread fenton
Noted and updated!  Thx.

On Friday, June 8, 2012 11:02:50 AM UTC-7, fenton wrote:
>
> I created a tutorial explaining what the thrush -> and ->> operator is.
>
>
> https://github.com/ftravers/PublicDocumentation/blob/master/clojure-thrush.md
>
> My tutorials are aimed at people who appreciate VERY explicit 
> explanations, which I think there is a bit of a gap among current internet 
> available literature.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: [PATCH] RFC: Add Functions `tabify` And `untabify`

2012-06-09 Thread Stuart Sierra
On Fri, Jun 8, 2012 at 5:55 PM, OGINO Masanori  wrote:
> There are many negative votes for the proposal and the main doubt is
> "do you need to make them in closure.string?"

Hi Ogino,

Please don't misinterpret my comments as saying you're wasting time.
By all means, keep working on this. `tabify` and functions like it
could be useful to others, I just don't know yet.

If you can demonstrate an improvement to clojure.repl by adding these
functions, then I think that's enough justification to add them --
maybe first as private fns in clojure.repl. Later on, if they seem
generally useful, we can incorporate them into clojure.string.

Thanks,
-Stuart

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en


Re: Explaining the thrush -> operator.

2012-06-09 Thread myriam abramson
This is all very nice but it seems to me to be a case of less is more (or
more is less).  I mean, if I am used to read inside out easily, this
operator just makes my life harder. I don't plan to use it but
unfortunately to understand other people's code, I have to switch mindset.

On Sat, Jun 9, 2012 at 12:27 PM, fenton  wrote:

> Noted and updated!  Thx.
>
>
> On Friday, June 8, 2012 11:02:50 AM UTC-7, fenton wrote:
>>
>> I created a tutorial explaining what the thrush -> and ->> operator is.
>>
>> https://github.com/ftravers/**PublicDocumentation/blob/**
>> master/clojure-thrush.md
>>
>> My tutorials are aimed at people who appreciate VERY explicit
>> explanations, which I think there is a bit of a gap among current internet
>> available literature.
>>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

What happened to clojure.contrib.laz-seqs

2012-06-09 Thread Base
Sorry for rehashing the contrib issue once again...I cannot seem to figure 
out what happened to this library...

Thanks

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: problem compiling a file from with in slime while it works fine when I do a lein jar

2012-06-09 Thread Sunil S Nandihalli
while I couldn't get it to work from with-in slime .. I was able to get
around the problem by doing a
lein repl
where I could run the (s-expressions) for debugging purposes..
I just thought of updating the mailing list should somebody else come
across the same problem..
Sunil.

On Sat, Jun 9, 2012 at 3:43 PM, Sunil S Nandihalli <
sunil.nandiha...@gmail.com> wrote:

> Hi Everybody,
>  I am trying to write a code using the thrift in clojure. The files
> generated by thrift are present and I am able to run lein jar and it
> successfully creates a jar. but when I am inside emacs and I try to do C-c
> C-k it fails to load(import) the class file corresponding to one of the
> classes generated by thrift. Can somebody help me as to how I can fix this.
> I am able to do run the code as-well using "lein run" . So, the only
> problem is I am unable to work with it interactively in slime. Can somebody
> help me fix this problem?
> Thanks
> Sunil.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Doseq, map-style

2012-06-09 Thread Alex Baranosky
I'd just use doseq.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Doseq, map-style

2012-06-09 Thread David Jacobs
Thanks, guys.

I know there are easy ways to implement what I want. However, I'm more curious 
as to why the language itself doesn't support this style of mapping 
side-effects.

In other words, why does doseq not follow map's lead here. Is there a 
philosophical difference underlying the syntax difference (doseq [elem coll] (f 
coll)) and (each f coll)?

It seems to me that the side-effecty nature of (doseq) isn't quite enough to 
justify the syntax difference between map and doseq. I guess one could say that 
because doseq is built for side-effects, which are often multiline, doseq 
should easily accept multiline statements. However, my imaginary each macro 
could do the same: (each #(do … …) coll).

What am I missing?

Thanks!
David

On Friday, June 8, 2012 at 7:00 AM, Lars Nilsson wrote:

> On Fri, Jun 8, 2012 at 9:54 AM, Allen Johnson  (mailto:akjohnso...@gmail.com)> wrote:
> > Combine map with dorun and you get the same effect:
> >  
> > (dorun (map println logs))
> >  
> > http://clojure.github.com/clojure/clojure.core-api.html#clojure.core/dorun
> >  
> > Allen
> >  
> > On Thu, Jun 7, 2012 at 11:32 PM, David Jacobs  > (mailto:da...@wit.io)> wrote:
> > > I would love to have a version of doseq that works like map (similar to
> > > "each" in other dynamic languages). In other words, instead of (doseq [log
> > > logs] (println log)), I would say something like (each println logs).
> > >  
> > > Is there a built-in Clojure method that works like this?
>  
> Not a built-in, but...
>  
> (defmacro for-each [f x] `(doseq [item# ~x] (~f item#)))
>  
> I suppose this solution is blindingly obvious though.
>  
> Also, I would be curious if there's any significant performance
> difference using (dorun (map ...)) as I assume an intermediate result
> is built and then thrown away. Or perhaps it's insignificant compared
> to what the unspecified function does that is passed to map for
> performing the side-effect work..
>  
> Lars Nilsson
>  
> --  
> 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 
> (mailto: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 
> (mailto:clojure+unsubscr...@googlegroups.com)
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>  



-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en


Re: Function minimizer a la fminunc

2012-06-09 Thread David Jacobs
Thanks! That section of Incanter must be new, I haven't seen it till now. Will 
check it out and report back.


On Friday, June 8, 2012 at 7:15 AM, Lars Nilsson wrote:

> On Fri, Jun 8, 2012 at 12:30 AM, David Jacobs  (mailto:da...@wit.io)> wrote:
> > Has anyone written a function minimizer in Clojure (or in Java)? I want
> > something like Octave's fminunc [0], where I can pass in a function and a
> > parameter list and find the parameters that minimize the function. Anyone
> > know of one?
> > 
> > [0] http://octave.sourceforge.net/octave/function/fminunc.html
> 
> Perhaps Incanter has something suitable?
> 
> http://liebke.github.com/incanter/optimize-api.html#incanter.optimize/non-linear-model
> 
> Couldn't say for sure if this is exactly what you're looking for but
> if nothing else, you get a lot of building blocks to build upon.
> 
> Lars Nilsson
> 
> -- 
> 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 
> (mailto: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 
> (mailto:clojure+unsubscr...@googlegroups.com)
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en



-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en


Re: Emulating inheritance on protocols in ClojureScript.

2012-06-09 Thread semperos
Reviving this thread to see if anyone has any info at this point. Looking 
at the implementation of extend-type in JVM Clojure and ClojureScript, it's 
obvious that in ClojureScript it's not a simple "wrapper" macro for a 
specific use of extend, like it is in JVM Clojure.

As this particular mechanism is not currently available in ClojureScript, 
does anyone (1) know if extend is slated to make its way into 
ClojureScript, or (2) have a specific idiom to accomplish the same thing?

-Daniel

On Saturday, January 14, 2012 1:42:15 AM UTC-5, Takahiro Hozumi wrote:
>
> Hi, 
> I want to set a default behavior on a protocol. 
> The following article describes how to implement inheritance in 
> Clojure by using `extend`, but `extend` doesn't exist in 
> ClojureScript. 
> Is there a way to set a default behavior on a protocol in 
> ClojureScript? 
>
> (david-mcneil.com :blog), Implementation "inheritance" in Clojure 
>
> http://david-mcneil.com/post/1475458103/implementation-inheritance-in-clojure 
>
> Thanks.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Emulating inheritance on protocols in ClojureScript.

2012-06-09 Thread David Nolen
Patch welcome! :)

On Sat, Jun 9, 2012 at 9:02 PM, semperos wrote:

> Reviving this thread to see if anyone has any info at this point. Looking
> at the implementation of extend-type in JVM Clojure and ClojureScript, it's
> obvious that in ClojureScript it's not a simple "wrapper" macro for a
> specific use of extend, like it is in JVM Clojure.
>
> As this particular mechanism is not currently available in ClojureScript,
> does anyone (1) know if extend is slated to make its way into
> ClojureScript, or (2) have a specific idiom to accomplish the same thing?
>
> -Daniel
>
>
> On Saturday, January 14, 2012 1:42:15 AM UTC-5, Takahiro Hozumi wrote:
>>
>> Hi,
>> I want to set a default behavior on a protocol.
>> The following article describes how to implement inheritance in
>> Clojure by using `extend`, but `extend` doesn't exist in
>> ClojureScript.
>> Is there a way to set a default behavior on a protocol in
>> ClojureScript?
>>
>> (david-mcneil.com :blog), Implementation "inheritance" in Clojure
>> http://david-mcneil.com/post/**1475458103/implementation-**
>> inheritance-in-clojure
>>
>> Thanks.
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: Doseq, map-style

2012-06-09 Thread Kurt Harriger
 
You could also (dorun (map f coll)) 

It is actually interesting you brought this up as I was recently 
contrasting the OO principle "tell don't ask" with the functional way of 
doing things.  In OO a void method taking a visitor is preferred over 
return values.  One could perhaps say that (dorun (map f (generator))) is 
pretty much the same thing as (each (generator) f) except that generator is 
now a pure side effect free function where as visitors generally speaking 
have side effects, although this isn't required for example (each coll 
identity) is just as easy to use and test. 

The more I thought about it the more I began to realize that the OO visitor 
approach may still have some advantages over the functional approach.  In a 
typed language the generator can overload based on the visitor's type 
signature, this makes refactoring and evolving code easier while still 
preserving backward compatibility as different versions of a visitor might 
have different method parameter types.  Of course you could do this in 
clojure explicitly but is less elegant ie (map f (generator 
:non-default-type)) and is generally considered confusing to have functions 
return different return types depending on their parameters. It is probably 
better to just choose a different function name instead.

One other difference that is not as easy to emulate functionally is when 
the generator spawns multiple threads and delegates the work where each 
worker may call the visitor back on different threads.  In clojure you can 
easily (pmap f (generator)), however this requires generator to create a 
sequence of return values from a specific thread regardless of how many 
threads are used to generate the sequence or process the sequence, 
ultimately the generator must first bring all these results together on a 
single thread creating a synchronization bottleneck that does not 
necessarily need to exist when using side effects instead of return values. 
 For example, the side effect might be to write its results to a database 
and the generator might partition the work to each visitor never expecting 
a reply from any of them, the visitor might even forward the request to a 
different machine on the network since no return value is expected or 
required.  

Many will say that side-effecting functions are more difficult to test then 
pure functions... However after writing about 4000 lines of clojure code, I 
realized that things in practice are never quite as simple as they seem. 
 As functions are composed the data structures they work with grow larger 
and more complex and this leads to maps containing maps containing lists 
containing maps and a minor change downstream can ripple through the 
program.  Tests become significantly more complex and fragile as the input 
and output structures grow in complexity.

This reminded me of another OO code smell "Don't talk to strangers" and 
the Law of Demeter, instead sending and returning maps of lists of maps I 
started returning maps of functions.  This provided additional decoupling 
that enabled me to refactor a bit more easily additionally maps of maps of 
lists of maps often need to be fully computed where as a map containing 
functions allows me to defer computation until it is actually required 
which may in many cases be never. Although very idiomatic to use keywords 
to get from maps, I have started to think of this as a code smell and 
instead prefer to (def value :value) and use this var instead of the 
keyword because it allows me to later replace the implementation or rename 
properties if it is necessary to refactor and I want to minimize changes to 
existing code or make changes to the existing code in small incremental 
units rather than all at once.  

It is also very hard to write a useful program that does not contain 
side-effects or reads data from an impure datasource and I used midje to 
mock functions that such as (get-current-time), many times my function did 
not use that function directly but was used by another function that my 
function called.  I began to see this as a code smell in OO I would mock 
the object that uses get-current-time not get-current-time itself which 
then gave me the idea to start passing the functions used by the function 
under test to the function as additional parameters, for testing I could 
pass in an alternative function such as (constantly true) or (identity). 
 However, some functions required many functions so I began to group these 
into maps and began to realize that I was reinventing OO programming... 
perhaps there is a good reason lisp programmers invented CLOS in the first 
place.  

I'm starting to go off topic, and don't mean to troll, but your question as 
innocent as it seems is perhaps one of the most important differences 
between OO and functional programming ("Tell don't ask").  Perhaps the 
functional solution is monads... but most find these confusing for some 
reason and are hardly idiomatic.  I di

Re: Doseq, map-style

2012-06-09 Thread Walter Tetzner
>
> Is there a philosophical difference underlying the syntax difference
> (doseq [elem coll] (f coll)) and (each f coll)?
>

`doseq' is the side-effecty version of `'for', not map. It lets you do
things like

user> (doseq [x (range 100)
  :while (< x 20)
  :when (even? x)]
 (println x))
0
2
4
6
8
10
12
14
16
18

If you want a side-effecty version of map, I would avoid the macro
suggested earlier, and just do

(def each (comp dorun map))

or

(defn each [f coll] (doseq [x coll] (f x)))

-Walter

On Sat, Jun 9, 2012 at 5:08 PM, David Jacobs  wrote:

> Thanks, guys.
>
> I know there are easy ways to implement what I want. However, I'm more
> curious as to why the language itself doesn't support this style of mapping
> side-effects.
>
> In other words, why does doseq not follow map's lead here. Is there a
> philosophical difference underlying the syntax difference (doseq [elem
> coll] (f coll)) and (each f coll)?
>
> It seems to me that the side-effecty nature of (doseq) isn't quite enough
> to justify the syntax difference between map and doseq. I guess one could
> say that because doseq is built for side-effects, which are often
> multiline, doseq should easily accept multiline statements. However, my
> imaginary each macro could do the same: (each #(do … …) coll).
>
> What am I missing?
>
> Thanks!
> David
>
> On Friday, June 8, 2012 at 7:00 AM, Lars Nilsson wrote:
>
> > On Fri, Jun 8, 2012 at 9:54 AM, Allen Johnson  akjohnso...@gmail.com)> wrote:
> > > Combine map with dorun and you get the same effect:
> > >
> > > (dorun (map println logs))
> > >
> > >
> http://clojure.github.com/clojure/clojure.core-api.html#clojure.core/dorun
> > >
> > > Allen
> > >
> > > On Thu, Jun 7, 2012 at 11:32 PM, David Jacobs  da...@wit.io)> wrote:
> > > > I would love to have a version of doseq that works like map (similar
> to
> > > > "each" in other dynamic languages). In other words, instead of
> (doseq [log
> > > > logs] (println log)), I would say something like (each println logs).
> > > >
> > > > Is there a built-in Clojure method that works like this?
> >
> > Not a built-in, but...
> >
> > (defmacro for-each [f x] `(doseq [item# ~x] (~f item#)))
> >
> > I suppose this solution is blindingly obvious though.
> >
> > Also, I would be curious if there's any significant performance
> > difference using (dorun (map ...)) as I assume an intermediate result
> > is built and then thrown away. Or perhaps it's insignificant compared
> > to what the unspecified function does that is passed to map for
> > performing the side-effect work..
> >
> > Lars Nilsson
> >
> > --
> > 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 (mailto:
> 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 (mailto:
> clojure+unsubscr...@googlegroups.com)
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> >
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
>

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

clojurescript crate library fails on non-nested list of tags

2012-06-09 Thread Sean Neilan
Hey All,

I was wondering if anybody has a work-around for doing a list of tags like
this:
(crate/html (list [:div.class1] [:div.class2]))

Because it causes the browser repl to hang up & gives
Uncaught [:div.class1] is not a valid tag name.

If I have a single div as the root, it works just fine.

-Sean

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

Reloading file doesn't reload the multimethod dispatch function

2012-06-09 Thread Orion Hickman
This one threw me, hard. I do all my development with a long running
process (as, I'm sure, most people do). Is there some way we can tweak
the implementation to avoid this problem?

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en


Re: Reloading file doesn't reload the multimethod dispatch function

2012-06-09 Thread Phil Hagelberg
On Sat, Jun 9, 2012 at 9:04 PM, Orion Hickman
 wrote:
> This one threw me, hard. I do all my development with a long running
> process (as, I'm sure, most people do). Is there some way we can tweak
> the implementation to avoid this problem?

Unfortunately defonce semantics on defmulti is intentional.

Usually what I do as a workaround is clear the defmulti right before
defining it:

(def mymulti nil)
(defmulti mymulti type)

Ugly but preferable to the alternative.

I believe the motivation behind the current behaviour is to preserve
the method table upon reload; the unchanging dispatch function may
just be collateral damage. I haven't looked at the implementation of
defmulti, but it may be possible to have reloads change the dispatch
function without clearing the method table.

-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


Re: clojurescript crate library fails on non-nested list of tags

2012-06-09 Thread Dave Sann
probably something like:

(map crate/html (list [:div.class1] [:div.class2]))

untested.

If you want to modify the dom in the process - then you could use doseq.

D




On Sunday, 10 June 2012 13:54:28 UTC+10, Sean Neilan wrote:
>
> Hey All,
>
> I was wondering if anybody has a work-around for doing a list of tags like 
> this:
> (crate/html (list [:div.class1] [:div.class2]))
>
> Because it causes the browser repl to hang up & gives
> Uncaught [:div.class1] is not a valid tag name.
>
> If I have a single div as the root, it works just fine.
>
> -Sean
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Re: What happened to clojure.contrib.laz-seqs

2012-06-09 Thread Sean Corfield
On Sat, Jun 9, 2012 at 11:21 AM, Base  wrote:
> Sorry for rehashing the contrib issue once again...I cannot seem to figure
> out what happened to this library...

The short answer is nothing. It stopped being maintained, along with
several other modules in the old contrib package.

The longer answer is here:
http://clojuredocs.org/clojure_contrib/clojure.contrib.lazy-seqs -
most of the functions went somewhere else.
-- 
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"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