RE: doall

2018-05-16 Thread Sean Corfield
(zipmap inviteds (repeat 1))

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

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood


From: clojure@googlegroups.com <clojure@googlegroups.com> on behalf of Renata 
Soares <renata.sd...@gmail.com>
Sent: Wednesday, May 16, 2018 10:08:58 AM
To: Clojure
Subject: doall

Hello,

I have this vec called inviteds [:2 :4]

and I want to produce something like (hash-map :2 1, :4 1)

(doall (map #(hash-map % 1) inviteds))

but returns ({:2 1} {:4 1})

How can I produce the same result as (hash-map :2 1, :4 1) with doall (or other 
similar function)?

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

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


Re: doall

2018-05-16 Thread Justin Smith
as an aside, :1 etc. are bad keywords (accepted by some readers and not
others, technically not valid according to the docs), and usually the
presence of keywords like that indicates over-eager keywordizing of json
input, or a misunderstanding of clojure hash-maps

On Wed, May 16, 2018 at 12:38 PM Mauricio Aldazosa <
mauricio.aldaz...@gmail.com> wrote:

> Hi Renata,
>
> The problem with your code is that it is using *map* at the top level,
> which is a function that returns a lazy sequence. You are asking clojure to
> do something like:
>
> *Take each number n in inviteds and create a sequence of hash maps, where
> each hash map has n as a key and 1 as it's value.*
>
> But what you really want is a function at the top level that returns a
> hash map. As Colin shows, you can use *into* (here is a slightly
> different way than the one he used):
>
> *Take each number in inviteds and create a sequence of pairs. Each pair
> should have the number as it's first value, and 1 as the second. Then take
> those pairs, and "pour" them into a hash map.*
>
> (->> inviteds
>  (map (fn [number] (vector number 1)))
>  (into {}))
>
> You could also do it via *reduce*:
>
> *Start with an empty hash map, then assoc each number in inviteds with 1
> as it's value*:
>
> (reduce (fn [m number] (assoc m number 1))
> {}
> inviteds)
>
> Cheers,
> Mauricio
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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


Re: doall

2018-05-16 Thread Mauricio Aldazosa
Hi Renata,

The problem with your code is that it is using *map* at the top level,
which is a function that returns a lazy sequence. You are asking clojure to
do something like:

*Take each number n in inviteds and create a sequence of hash maps, where
each hash map has n as a key and 1 as it's value.*

But what you really want is a function at the top level that returns a hash
map. As Colin shows, you can use *into* (here is a slightly different way
than the one he used):

*Take each number in inviteds and create a sequence of pairs. Each pair
should have the number as it's first value, and 1 as the second. Then take
those pairs, and "pour" them into a hash map.*

(->> inviteds
 (map (fn [number] (vector number 1)))
 (into {}))

You could also do it via *reduce*:

*Start with an empty hash map, then assoc each number in inviteds with 1 as
it's value*:

(reduce (fn [m number] (assoc m number 1))
{}
inviteds)

Cheers,
Mauricio

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


Re: doall

2018-05-16 Thread Colin Yates
If you have a sequence of maps then merge is your friend:

(def maps = [{:2 1} {:4 1}])
(apply merge maps)

To create convert a sequence into a map whose key is always 1:
(into {} (map (fn [x] [x 1]) [:2 :4]))  

HTH

> On 16 May 2018, at 18:08, Renata Soares <renata.sd...@gmail.com> wrote:
> 
> Hello,
> 
> I have this vec called inviteds [:2 :4]
> 
> and I want to produce something like (hash-map :2 1, :4 1)
> 
> (doall (map #(hash-map % 1) inviteds))
> 
> but returns ({:2 1} {:4 1})
> 
> How can I produce the same result as (hash-map :2 1, :4 1) with doall (or 
> other similar function)?
> 
> 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 
> <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 
> <mailto:clojure+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

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


Re: doall

2018-05-16 Thread Laurens Van Houtven
Hi Renada,


The magic function you're looking for is called "frequencies":
https://clojuredocs.org/clojure.core/frequencies

You could look at its implementation if you want to know how to implement
this :)


lvh

On Wed, May 16, 2018 at 12:08 PM, Renata Soares <renata.sd...@gmail.com>
wrote:

> Hello,
>
> I have this vec called *inviteds* [:2 :4]
>
> and I want to produce something like (hash-map :2 1, :4 1)
>
> (doall (map #(hash-map % 1) *inviteds*))
>
> but returns ({:2 1} {:4 1})
>
> How can I produce the same result as (hash-map :2 1, :4 1) with doall (or
> other similar function)?
>
> 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 unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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


doall

2018-05-16 Thread Renata Soares
Hello,

I have this vec called *inviteds* [:2 :4]

and I want to produce something like (hash-map :2 1, :4 1)

(doall (map #(hash-map % 1) *inviteds*))

but returns ({:2 1} {:4 1})

How can I produce the same result as (hash-map :2 1, :4 1) with doall (or 
other similar function)?

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


doall example

2014-05-16 Thread Brian Craft
I came across this today in a library:

results (seq (doall (filter modified? files)))]

I believe the seq is to coerce the empty list to nil. What is the doall for?

Context here:

https://github.com/ibdknox/watchtower/blob/master/src/watchtower/core.clj

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


Re: doall example

2014-05-16 Thread James Reeves
The doall evaluates all items in the seq, effectively removing any lazy
evaluation. In this case it's necessary because the filter is checking the
modification date of the file, which is obviously mutable.

- James



On 17 May 2014 00:39, Brian Craft craft.br...@gmail.com wrote:

 I came across this today in a library:

 results (seq (doall (filter modified? files)))]

 I believe the seq is to coerce the empty list to nil. What is the doall
 for?

 Context here:

 https://github.com/ibdknox/watchtower/blob/master/src/watchtower/core.clj

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


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


Re: doall example

2014-05-16 Thread Brian Craft
Ah, thanks. Seems like there's still a race, though. In a long list of 
files, a sequence like

1) doall evaluates modification date of the first file, which is less than 
*last-pass*, so it is filtered out
2) something touches the first file
3) the doall finishes evaluating the rest of the list, after which 
*last-pass* is set to the current time

Now the first file has been updated, but still has modification date less 
than *last-pass*, and will be filtered out of the next pass as well.



On Friday, May 16, 2014 4:50:19 PM UTC-7, James Reeves wrote:

 The doall evaluates all items in the seq, effectively removing any lazy 
 evaluation. In this case it's necessary because the filter is checking the 
 modification date of the file, which is obviously mutable.

 - James



 On 17 May 2014 00:39, Brian Craft craft...@gmail.com javascript:wrote:

 I came across this today in a library:

 results (seq (doall (filter modified? files)))]

 I believe the seq is to coerce the empty list to nil. What is the doall 
 for?

 Context here:

 https://github.com/ibdknox/watchtower/blob/master/src/watchtower/core.clj
  
 -- 
 You received this message because you are subscribed to the Google
 Groups Clojure group.
 To post to this group, send email to clo...@googlegroups.comjavascript:
 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 javascript:
 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 javascript:.
 For more options, visit https://groups.google.com/d/optout.




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


(type (doall x))

2009-06-24 Thread Volker Sarodnick

Hello,

I'm rather new to clojure and still fighting with the
basics. Just new I wondering why (type (doall x)) is still
clojure.lang.LazySeq? Probably easy but I get no clue, could
anyone help?

user (def x (range 0 (* 2.0 Math/PI) 0.1))
#'user/x
user (ns user
  (:require [clojure.contrib.generic.math-functions :as gmath]))
nil
user (gmath/sin (doall x))
; Evaluation aborted.
No method in multimethod 'sin' for dispatch value: class clojure.lang.LazySeq


user (type x)
clojure.lang.LazySeq
user (type (doall x))
clojure.lang.LazySeq


Thanks
Volker
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

--~--~-~--~~~---~--~~
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: (type (doall x))

2009-06-24 Thread Konrad Hinsen

On Jun 24, 2009, at 11:24, Volker wrote:

 I'm rather new to clojure and still fighting with the
 basics. Just new I wondering why (type (doall x)) is still
 clojure.lang.LazySeq? Probably easy but I get no clue, could
 anyone help?

A lazy seq is a data structure whose elements are built on demand  
*and then stored*. It remains a lazy seq forever. Perhaps you thought  
that a lazy seq is just an intermediate data type that becomes a list  
once all elements are there? This is not possible, because an object  
cannot change its type. Or perhaps you expected doall to convert a  
lazy seq into a list? That's not what it does, it returns exactly the  
same object that is passed as its argument, it just forces evaluation  
of all elements.

 user (def x (range 0 (* 2.0 Math/PI) 0.1))
 #'user/x
 user (ns user
   (:require [clojure.contrib.generic.math-functions :as gmath]))
 nil
 user (gmath/sin (doall x))
 ; Evaluation aborted.
 No method in multimethod 'sin' for dispatch value: class
 clojure.lang.LazySeq

That wouldn't work even if doall converted x to another collection  
data type. If you want to apply sin to sequences, you have to provide  
a method for applying sin to sequences - which is of course perfectly  
well possible:

(defmethod gmath/sin clojure.lang.ISeq
   [coll]
   (map gmath/sin coll))

That should work (I didn't test it), but I would probably prefer to see
(map gmath/sin (doall x))
written out explicitly.

Konrad.

--~--~-~--~~~---~--~~
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: (type (doall x))

2009-06-24 Thread Volker

Thank you:

(map gmath/sin x)

did the trick!

Volker

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



doall, dorun, doseq, for

2009-03-03 Thread Mark Volkmann

Does this seem like a good way to choose between doall, dorun, doseq
and for to evaluate all the items in sequences?

Ask these questions:

Do you already have the lazy sequence in a variable or do you still
need to build it?
If you already have it, use dorun or doall. Otherwise use doseq or for.
While code inside a dorun or doall could build the sequence, using
doseq and for are considered more idiomatic/readable.
Also, they provide list comprehension features such as processing more
than one sequence and filtering with :when/:while.

For example, instead of using the following to get a new sequence
where all the items are multiplied by two:
(doall (map #(* % 2) my-coll))
use this:
(for [item my-coll] (* item 2))

Are you only interested in side effects of the evaluations or do you
need to retain the results?
If you only need side effects, use dorun or doseq. If you need the
results, use doall or for.

-- 
R. Mark Volkmann
Object Computing, Inc.

--~--~-~--~~~---~--~~
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
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: doall, dorun, doseq, for

2009-03-03 Thread Laurent PETIT
Hello Mark,

Just one point :

2009/3/3 Mark Volkmann r.mark.volkm...@gmail.com


 Does this seem like a good way to choose between doall, dorun, doseq
 and for to evaluate all the items in sequences?

 Ask these questions:

 Do you already have the lazy sequence in a variable or do you still
 need to build it?
 If you already have it, use dorun or doall. Otherwise use doseq or for.
 While code inside a dorun or doall could build the sequence, using
 doseq and for are considered more idiomatic/readable.
 Also, they provide list comprehension features such as processing more
 than one sequence and filtering with :when/:while.

 For example, instead of using the following to get a new sequence
 where all the items are multiplied by two:
 (doall (map #(* % 2) my-coll))
 use this:
 (for [item my-coll] (* item 2))


I don't think it is a good example, since it conveys the idea that it could
be interesting to use doall or for for mapping a coll to multiply its items.
This example, in which there is no side effect at all in the inner loop, is
really typical of the use of map ! And forcing the sequence there gives you
nothing (?)

Maybe a more interesting example could be something that touches global
vars, or does IO, ... ?

--~--~-~--~~~---~--~~
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
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: doall, dorun, doseq, for

2009-03-03 Thread Laurent PETIT
2009/3/3 Mark Volkmann r.mark.volkm...@gmail.com


 On Tue, Mar 3, 2009 at 9:12 AM, Laurent PETIT laurent.pe...@gmail.com
 wrote:
  Hello Mark,
 
  Just one point :
 
  2009/3/3 Mark Volkmann r.mark.volkm...@gmail.com
 
  Does this seem like a good way to choose between doall, dorun, doseq
  and for to evaluate all the items in sequences?
 
  Ask these questions:
 
  Do you already have the lazy sequence in a variable or do you still
  need to build it?
  If you already have it, use dorun or doall. Otherwise use doseq or for.
  While code inside a dorun or doall could build the sequence, using
  doseq and for are considered more idiomatic/readable.
  Also, they provide list comprehension features such as processing more
  than one sequence and filtering with :when/:while.
 
  For example, instead of using the following to get a new sequence
  where all the items are multiplied by two:
  (doall (map #(* % 2) my-coll))
  use this:
  (for [item my-coll] (* item 2))
 
  I don't think it is a good example, since it conveys the idea that it
 could
  be interesting to use doall or for for mapping a coll to multiply its
 items.
  This example, in which there is no side effect at all in the inner loop,
 is
  really typical of the use of map ! And forcing the sequence there gives
 you
  nothing (?)
 
  Maybe a more interesting example could be something that touches global
  vars, or does IO, ... ?

 Very good point! With what I'm doing, simply multiplying items by two,
 you'd want the result to be an unevaluated, lazy sequence which is why
 map would be preferred.

 But supposing I was doing something like you suggested where I really
 do want to force the evaluation of all the items in the sequence, do
 my rules of thumb make sense?


I haven't thought really hard about it, what it written seems correct to me.

But I think the first point is a little bit dangerous without a side note :
if you already have the seq, then call 'doall or 'dorun on it.
Indeed, if you're dealing with a seq that is passed around, you may end up
calling dorun or doall on the seq in several places in the code, which may
lead to problems if you have side effects in them !
So to prevent this risk : either the call to 'doall or 'dorun is factorized,
and it will certainly be factorized near the place where the seq is
generated (thus almost falling back to your second case you don't have
generated the seq yet), either you haven't side effects at all, and you
fall back to an idiomatic use of 'map or another lazy-seq generating
function, without the need to call 'doall or 'dorun on them.

HTH,

-- 
Laurent




 --
 R. Mark Volkmann
 Object Computing, Inc.

 


--~--~-~--~~~---~--~~
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
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: doall, dorun, doseq, for - Debugging as a side effect?

2009-03-03 Thread Peter Wolf

RE: Side Effects

What about logging?   Without a debugger I use lots of print's to debug 
my code... and that often produces confusing results as things may not 
get evaluated in the order I expect.

For that matter, now that we have integrated Java debuggers, what does 
setting a breakpoint really mean?  And what does it imply about the 
state of all the variables outside the current scope?

How do others think about debugging lazy code?

P

Laurent PETIT wrote:
 2009/3/3 Mark Volkmann r.mark.volkm...@gmail.com 
 mailto:r.mark.volkm...@gmail.com


 On Tue, Mar 3, 2009 at 9:12 AM, Laurent PETIT
 laurent.pe...@gmail.com mailto:laurent.pe...@gmail.com wrote:
  Hello Mark,
 
  Just one point :
 
  2009/3/3 Mark Volkmann r.mark.volkm...@gmail.com
 mailto:r.mark.volkm...@gmail.com
 
  Does this seem like a good way to choose between doall, dorun,
 doseq
  and for to evaluate all the items in sequences?
 
  Ask these questions:
 
  Do you already have the lazy sequence in a variable or do you still
  need to build it?
  If you already have it, use dorun or doall. Otherwise use doseq
 or for.
  While code inside a dorun or doall could build the sequence, using
  doseq and for are considered more idiomatic/readable.
  Also, they provide list comprehension features such as
 processing more
  than one sequence and filtering with :when/:while.
 
  For example, instead of using the following to get a new sequence
  where all the items are multiplied by two:
  (doall (map #(* % 2) my-coll))
  use this:
  (for [item my-coll] (* item 2))
 
  I don't think it is a good example, since it conveys the idea
 that it could
  be interesting to use doall or for for mapping a coll to
 multiply its items.
  This example, in which there is no side effect at all in the
 inner loop, is
  really typical of the use of map ! And forcing the sequence
 there gives you
  nothing (?)
 
  Maybe a more interesting example could be something that touches
 global
  vars, or does IO, ... ?

 Very good point! With what I'm doing, simply multiplying items by two,
 you'd want the result to be an unevaluated, lazy sequence which is why
 map would be preferred.

 But supposing I was doing something like you suggested where I really
 do want to force the evaluation of all the items in the sequence, do
 my rules of thumb make sense?


 I haven't thought really hard about it, what it written seems correct 
 to me.

 But I think the first point is a little bit dangerous without a side 
 note : if you already have the seq, then call 'doall or 'dorun on it.
 Indeed, if you're dealing with a seq that is passed around, you may 
 end up calling dorun or doall on the seq in several places in the 
 code, which may lead to problems if you have side effects in them !
 So to prevent this risk : either the call to 'doall or 'dorun is 
 factorized, and it will certainly be factorized near the place where 
 the seq is generated (thus almost falling back to your second case 
 you don't have generated the seq yet), either you haven't side 
 effects at all, and you fall back to an idiomatic use of 'map or 
 another lazy-seq generating function, without the need to call 'doall 
 or 'dorun on them.

 HTH,

 -- 
 Laurent
  



 --
 R. Mark Volkmann
 Object Computing, Inc.






 


--~--~-~--~~~---~--~~
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
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: doall, dorun, doseq, for

2009-03-03 Thread Chouser

On Tue, Mar 3, 2009 at 10:03 AM, Mark Volkmann
r.mark.volkm...@gmail.com wrote:

 Does this seem like a good way to choose between doall, dorun, doseq
 and for to evaluate all the items in sequences?

 Ask these questions:

 Do you already have the lazy sequence in a variable or do you still
 need to build it?
 If you already have it, use dorun or doall. Otherwise use doseq or for.

If you have a lazy sequence with side-effects, you almost certainly
don't want to let it out of your sight.  You're likely to get very
strange behavior unless you're exceedingly careful.  Most likely, if
you've got a lazy seq with side effects you should force it with dorun
or doall immediately.  Use doall if you care about the values in the
produced seq, otherwise use dorun.

This means that dorun should almost always show up right next to the
form producing the lazy seq, which means doseq is very likely a better
choice, as it is more efficient and usually more succinct than dorun
combined with a lazy-seq producer.

'for' is in rather a different category, since unlike the others it
produces a lazy seq rather than forcing anything.  Use 'for' when it's
a more convenient way to express the lazy seq you want than the
equivalent combination of map, filter, take-while, etc.

--Chouser

--~--~-~--~~~---~--~~
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
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: doall, dorun, doseq, for

2009-03-03 Thread Meikel Brandmeyer

Hi,

Am 03.03.2009 um 16:42 schrieb Chouser:


If you have a lazy sequence with side-effects, you almost certainly
don't want to let it out of your sight.  You're likely to get very
strange behavior unless you're exceedingly careful.  Most likely, if
you've got a lazy seq with side effects you should force it with dorun
or doall immediately.  Use doall if you care about the values in the
produced seq, otherwise use dorun.

This means that dorun should almost always show up right next to the
form producing the lazy seq, which means doseq is very likely a better
choice, as it is more efficient and usually more succinct than dorun
combined with a lazy-seq producer.


What is the use case for dorun? It returns nil, so it can itself only
be called as a side-effect. From doall and dorun, only doall makes
sense to me. It is either called immediately

  (doall (map ...))

Or when giving the seq out of the hands:

  (with-some resource
...
(doall the-seq))

Why should there ever be the need to call dorun?

And by the way: the output of the following code doesn't lie.

  (let [the-seq (map #(* % 2) (range 100))]
(doseq [x the-seq]
  (println Just produced: x)))


'for' is in rather a different category, since unlike the others it
produces a lazy seq rather than forcing anything.  Use 'for' when it's
a more convenient way to express the lazy seq you want than the
equivalent combination of map, filter, take-while, etc.


I must confess, I almost never used for... Maybe I should
try to use it more often.

Sincerely
Meikel



smime.p7s
Description: S/MIME cryptographic signature


Re: doall, dorun, doseq, for

2009-03-03 Thread Laurent PETIT
2009/3/3 Meikel Brandmeyer m...@kotka.de

 Hi,

 Am 03.03.2009 um 16:42 schrieb Chouser:

  If you have a lazy sequence with side-effects, you almost certainly
 don't want to let it out of your sight.  You're likely to get very
 strange behavior unless you're exceedingly careful.  Most likely, if
 you've got a lazy seq with side effects you should force it with dorun
 or doall immediately.  Use doall if you care about the values in the
 produced seq, otherwise use dorun.

 This means that dorun should almost always show up right next to the
 form producing the lazy seq, which means doseq is very likely a better
 choice, as it is more efficient and usually more succinct than dorun
 combined with a lazy-seq producer.


 What is the use case for dorun? It returns nil, so it can itself only
 be called as a side-effect. From doall and dorun, only doall makes
 sense to me. It is either called immediately

  (doall (map ...))

 Or when giving the seq out of the hands:

  (with-some resource
...
(doall the-seq))

 Why should there ever be the need to call dorun?


If you still want to force a veeerry long seq for side effect, without
fearing to face an OutOfMemory error ?



 And by the way: the output of the following code doesn't lie.

  (let [the-seq (map #(* % 2) (range 100))]
(doseq [x the-seq]
  (println Just produced: x)))

  'for' is in rather a different category, since unlike the others it
 produces a lazy seq rather than forcing anything.  Use 'for' when it's
 a more convenient way to express the lazy seq you want than the
 equivalent combination of map, filter, take-while, etc.


 I must confess, I almost never used for... Maybe I should
 try to use it more often.

 Sincerely
 Meikel



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Clojure group.
To post to this group, send email to clojure@googlegroups.com
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: doall, dorun, doseq, for

2009-03-03 Thread Meikel Brandmeyer

Hi Laurent,

Am 03.03.2009 um 17:03 schrieb Laurent PETIT:


Why should there ever be the need to call dorun?



If you still want to force a veeerry long seq for side effect,  
without fearing to face an OutOfMemory error ?


  (let [some-lng-seq ]
(dorun some-lng-seq)
...)

How does dorun help here? In such a scenario
dorun only helps, if you don't hold onto the head.
But that means you loose the seq immediately
without using the return value at all. So you made
the seq purely for side-effects. And at that point
I boldly claim you should have used doseq in the
first place

Sincerely
Meikel



smime.p7s
Description: S/MIME cryptographic signature


Re: doall, dorun, doseq, for

2009-03-03 Thread Chouser

On Tue, Mar 3, 2009 at 10:56 AM, Meikel Brandmeyer m...@kotka.de wrote:

 This means that dorun should almost always show up right next to the
 form producing the lazy seq, which means doseq is very likely a better
 choice, as it is more efficient and usually more succinct than dorun
 combined with a lazy-seq producer.

 What is the use case for dorun? It returns nil, so it can itself only
 be called as a side-effect.

This was kind of my point.  In every case I can think of at the
moment, I would prefer doseq over dorun.

  (let [the-seq (map #(* % 2) (range 100))]
    (doseq [x the-seq]
      (println Just produced: x)))

So here's an example of where you could use dorun.

  (dorun (map #(println Just produced:  (* % 2))
  (range 100)))

But I think what you had was at least as clear.  Though there's no
need for 'map' if you're going to use doseq:

  (doseq [x (range 100)]
(println Just produced: (* x 2)))

And no need for doseq if you're using a simple range:

  (dotimes [x 100]
(println Just produced: (* x 2)))

 'for' is in rather a different category, since unlike the others it
 produces a lazy seq rather than forcing anything.  Use 'for' when it's
 a more convenient way to express the lazy seq you want than the
 equivalent combination of map, filter, take-while, etc.

 I must confess, I almost never used for... Maybe I should
 try to use it more often.

I like 'for' when I need nested behavior:

  (for [x '(a b c), y '(d e f)]
[x y])

vs.

  (mapcat (fn [x] (map #(vector x %)
   '(d e f)))
  '(a b c))

Of course it also does handy things with :when, :while, and :let, as
does doseq.

--Chouser

--~--~-~--~~~---~--~~
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
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: doall, dorun, doseq, for

2009-03-03 Thread Laurent PETIT
Correct. It seems that we are agreeing that we agree :-)

2009/3/3 Meikel Brandmeyer m...@kotka.de

 Hi Laurent,

 Am 03.03.2009 um 17:03 schrieb Laurent PETIT:

  Why should there ever be the need to call dorun?



 If you still want to force a veeerry long seq for side effect, without
 fearing to face an OutOfMemory error ?


  (let [some-lng-seq ]
(dorun some-lng-seq)
...)

 How does dorun help here? In such a scenario
 dorun only helps, if you don't hold onto the head.
 But that means you loose the seq immediately
 without using the return value at all. So you made
 the seq purely for side-effects. And at that point
 I boldly claim you should have used doseq in the
 first place

 Sincerely
 Meikel



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Clojure group.
To post to this group, send email to clojure@googlegroups.com
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: doall, dorun, doseq, for

2009-03-03 Thread Mark Volkmann

On Tue, Mar 3, 2009 at 9:42 AM, Chouser chou...@gmail.com wrote:

 If you have a lazy sequence with side-effects, you almost certainly
 don't want to let it out of your sight.  You're likely to get very
 strange behavior unless you're exceedingly careful.  Most likely, if
 you've got a lazy seq with side effects you should force it with dorun
 or doall immediately.  Use doall if you care about the values in the
 produced seq, otherwise use dorun.

 This means that dorun should almost always show up right next to the
 form producing the lazy seq, which means doseq is very likely a better
 choice, as it is more efficient and usually more succinct than dorun
 combined with a lazy-seq producer.

I agree that using doseq instead of dorun results in code that is
easier to read. I don't understand though why it is more efficient.
They both walk the entire sequence, neither holds onto the head and
both return nil. Why is doseq more efficient than dorun?

-- 
R. Mark Volkmann
Object Computing, Inc.

--~--~-~--~~~---~--~~
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
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: doall, dorun, doseq, for

2009-03-03 Thread Chouser

On Tue, Mar 3, 2009 at 2:54 PM, Mark Volkmann r.mark.volkm...@gmail.com wrote:

 I agree that using doseq instead of dorun results in code that is
 easier to read. I don't understand though why it is more efficient.
 They both walk the entire sequence, neither holds onto the head and
 both return nil. Why is doseq more efficient than dorun?

A simple doseq does run about as fast as dorun on the same seq.  Bus
something like this would be more likely (let's pretend inc has useful
side-effects):

  (defn f [] (dorun (map #(inc %) (range 1000

  (defn f2 [] (doseq [i (range 1000)] (inc i)))

The results would be the same, but dorun requires 'map', which creates
another seq.  'doseq' is able to accomplish the same work with less
allocation.

  user= (time (f))
  Elapsed time: 1685.796066 msecs

  user= (time (f2))
  Elapsed time: 531.730209 msecs

--Chouser

--~--~-~--~~~---~--~~
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
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: time lies, even with doall

2009-01-30 Thread Michael Wood

On Mon, Jan 26, 2009 at 6:24 AM, e evier...@gmail.com wrote:
 ok, I'll check that stuff out.  Thanks.

 It occurs to me this is being compared to something in ruby called
 partition.  I like that name.  partition-by ... but maybe it was opted to
 use the simpler name, which I can appreciate.

There is already a function called partition:

user= (doc partition)
-
clojure.core/partition
([n coll] [n step coll])
  Returns a lazy sequence of lists of n items each, at offsets step
  apart. If step is not supplied, defaults to n, i.e. the partitions
  do not overlap.
nil
user= (range 21)
(0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20)
user= (partition 7 (range 21))
((0 1 2 3 4 5 6) (7 8 9 10 11 12 13) (14 15 16 17 18 19 20))
user= (partition 2 (range 21))
((0 1) (2 3) (4 5) (6 7) (8 9) (10 11) (12 13) (14 15) (16 17) (18 19))
user= (partition 2 3 (range 21))
((0 1) (3 4) (6 7) (9 10) (12 13) (15 16) (18 19))

Note: If the collection cannot be divided evenly then some elements at
the end are discarded.

-- 
Michael Wood esiot...@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
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: NewBie Q: doall forces eval and dorun not; but why?

2009-01-26 Thread e
cool.  Thanks for the info about #{}.  I'm glad I learned about that.  To
learn even more, what is the reasoning behind that choice?  I've seen the
sharp used for other things in clojure; is there a connection?

On Mon, Jan 26, 2009 at 1:36 AM, Meikel Brandmeyer m...@kotka.de wrote:

 Hi,

 Am 26.01.2009 um 06:05 schrieb e:

  interesting to me that  wasn't used for anything to add to the literal
 syntax.  folks in another thread were using sequences for set theory.  But
 maybe there needs to be a set notation.  If that makes sense, {} should be
 sets, just like in math,  should be vectors, just like in math, and []
 could be maps.  I know, I know, it's kinda late to be arguing to change this
 stuff.  Another idea that fits in better would be to use  as an
 alternative to quoting a list . . . and still not do anything for sets.


 There is already literal syntax for all the collection types:

 - [] = vector
 - {} = hash-map
 - #{} = set

 What are you missing?

 Try to blend out experiences from other fields. Eg. we never
 used  for vectors in math, only (). So even this comparison
 is only your personal experience. It's good to have such
 experience when learning a new language, but it should not
 get into your way. Whenever you end up with But in this other
 field/language we do/have/can , you should take a step
 back and forget about the other field/language and look
 simply at Clojure. We cannot cater all the previous experiences
 of all the Clojure users

 Just my 2¢.

 Sincerely
 Meikel



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Clojure group.
To post to this group, send email to clojure@googlegroups.com
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: NewBie Q: doall forces eval and dorun not; but why?

2009-01-26 Thread Christian Vest Hansen

On Mon, Jan 26, 2009 at 3:20 PM, e evier...@gmail.com wrote:
 cool.  Thanks for the info about #{}.  I'm glad I learned about that.  To
 learn even more, what is the reasoning behind that choice?  I've seen the
 sharp used for other things in clojure; is there a connection?

It activates a special read-table for the following character, so it
is often used for special syntax.

See the Dispatch under macro characters here: http://clojure.org/reader


 On Mon, Jan 26, 2009 at 1:36 AM, Meikel Brandmeyer m...@kotka.de wrote:

 Hi,

 Am 26.01.2009 um 06:05 schrieb e:

 interesting to me that  wasn't used for anything to add to the literal
 syntax.  folks in another thread were using sequences for set theory.  But
 maybe there needs to be a set notation.  If that makes sense, {} should be
 sets, just like in math,  should be vectors, just like in math, and []
 could be maps.  I know, I know, it's kinda late to be arguing to change this
 stuff.  Another idea that fits in better would be to use  as an
 alternative to quoting a list . . . and still not do anything for sets.

 There is already literal syntax for all the collection types:

 - [] = vector
 - {} = hash-map
 - #{} = set

 What are you missing?

 Try to blend out experiences from other fields. Eg. we never
 used  for vectors in math, only (). So even this comparison
 is only your personal experience. It's good to have such
 experience when learning a new language, but it should not
 get into your way. Whenever you end up with But in this other
 field/language we do/have/can , you should take a step
 back and forget about the other field/language and look
 simply at Clojure. We cannot cater all the previous experiences
 of all the Clojure users

 Just my 2¢.

 Sincerely
 Meikel



 




-- 
Venlig hilsen / Kind regards,
Christian Vest Hansen.

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



time lies, even with doall

2009-01-25 Thread e

The IRC channel folks helped me implement what we discovered was
already called separate in contribs.  My point was to do a partition
that generated the two lists (passes pred) and (fails pred) in one
pass without recursion.

We ended up with:

(defn filt-rem [pred coll]
(loop [l1 () l2 () [f  r] coll]
  (if f
(if (pred f)
  (recur (conj l1 f) l2 r)
  (recur l1 (conj l2 f) r))
(list l1 l2

-- the name reaming filter and remove, I was thinking

There's some branching there, so perhaps it's not the most efficient
code.

Here's what's in contrib, and as Tim showed me in the pquicksort
discussion, that last bit could be replaced by remove:

(defn separate
  Returns a vector:
   [ (filter f s), (filter (complement f) s) ]
  [f s]
  [(filter f s) (filter (complement f) s)])

Well, the recursive one that does two passes blows away filt-rem,
according to 'time'.  But if I just count in my head, they both take
about as long.

Yes, I started throwing doall all over the place.  The other thing is
we definately aren't talking about milliseconds.  I.m not trying to
measure how much time is spent in the reader or compiler or whatever.
I care about the user waiting for the answer, and that's what I'm
trying to time.

Here's what I'm seeing, even though I don't believe it:

(def l1 (doall (take 5 (repeatedly #(rand-int 3000)  ;;; I
don't know if doall goes there, just shotgunning it at this point

(time (filt-rem #( % 1500) (doall l1)))  I've tried doall in
various places with no help
Elapsed time: 63.158 msecs-- no way.  It took like 12
seconds

(time (separate #( % 1500) (doall l1))) ;; doall here
actually did something even though already done above
Elapsed time: 12.701 msecs--- no way.  12 seconds, I
counted.  Definitely longer than 12 msecs.

Questions:

1) Is there anything wrong with filt-rem or anything to improve it?
2) why are the times reportedly so different when I can tell they
return in about the same amount of time?

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
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: time lies, even with doall

2009-01-25 Thread Emeka
Hi e,

I'm still learning the basics, very much like you( I guess you are ahead of
me in Clojure). However, I have a question for you and not an answer to your
questions. Why do you have doall here (def l1 (doall (take 5 (repeatedly
#(rand-int 3000) . From my little knowledge of Clojure, take 5 would
cause 'repeatedly' to be limited to 5 times and (repeatedly #(rand-int
3000) is an argument of take , so (take 5 (repeatedly #(rand-int 3000)
given same results as your  (doall (take 5 (repeatedly #(rand-int
3000 and by adding doall  you are just increasing 'noise', that's my 2
cents.
Doall , do, dorun are used in calling  multiple functions(I hope am like
:)), like (do (doo noot) (move niger delta)) .

Emeka

--~--~-~--~~~---~--~~
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
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: time lies, even with doall

2009-01-25 Thread e
people are paying a lot of attention to pure functional languages, which I
think mean ones that don't ever destroy data structures out from under
people pointing at them.  Instead, people who need different views just get
their own different views -- possibly reusing common components.

This other thing called lazy seems to mean that you don't need to do any
work until someone asks for the results. . . .and then you do the minimum
amount of work that's being asked for.  I've heard of a Unix analogy: if you
do a grep of just the first 5 times some pattern occurs, the whole pipeline
can shut down after those 5 are found.  The leading 'grep' needn't actually
keep scanning the file (incidentally, I'm not sure that works right on
windows/DOS pipes, where a copy of the whole file is sent across the pipe
before even finding out what's being asked for).

I'm hoping that doall gets rid of the laziness folks take a lot of pride
in . . . .and makes it work like DOS.  Otherwise, the timing won't really
work.  I'm asking with this question whether the contrib version is still
being lazy and returning to (time) without doing much . . . and if so, how
can I force it to actually do the work?

On Sun, Jan 25, 2009 at 11:04 AM, Emeka emekami...@gmail.com wrote:

 Hi e,

 I'm still learning the basics, very much like you( I guess you are ahead of
 me in Clojure). However, I have a question for you and not an answer to your
 questions. Why do you have doall here (def l1 (doall (take 5
 (repeatedly #(rand-int 3000) . From my little knowledge of Clojure, take
 5 would cause 'repeatedly' to be limited to 5 times and (repeatedly
 #(rand-int 3000) is an argument of take , so (take 5 (repeatedly
 #(rand-int 3000) given same results as your  (doall (take 5
 (repeatedly #(rand-int 3000 and by adding doall  you are just increasing
 'noise', that's my 2 cents.
 Doall , do, dorun are used in calling  multiple functions(I hope am like
 :)), like (do (doo noot) (move niger delta)) .

 Emeka




 


--~--~-~--~~~---~--~~
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
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: time lies, even with doall

2009-01-25 Thread e
oh, so anyway, i put it in that specific place because I wasn't sure if,
without it, l1 would just be some sort of smart, lazy list that only exists
when you start trying to get the values.  I didn't think so, but, again, I'm
just trying to shotgun the problem.

On Sun, Jan 25, 2009 at 1:57 PM, e evier...@gmail.com wrote:

 people are paying a lot of attention to pure functional languages, which
 I think mean ones that don't ever destroy data structures out from under
 people pointing at them.  Instead, people who need different views just get
 their own different views -- possibly reusing common components.

 This other thing called lazy seems to mean that you don't need to do any
 work until someone asks for the results. . . .and then you do the minimum
 amount of work that's being asked for.  I've heard of a Unix analogy: if you
 do a grep of just the first 5 times some pattern occurs, the whole pipeline
 can shut down after those 5 are found.  The leading 'grep' needn't actually
 keep scanning the file (incidentally, I'm not sure that works right on
 windows/DOS pipes, where a copy of the whole file is sent across the pipe
 before even finding out what's being asked for).

 I'm hoping that doall gets rid of the laziness folks take a lot of pride
 in . . . .and makes it work like DOS.  Otherwise, the timing won't really
 work.  I'm asking with this question whether the contrib version is still
 being lazy and returning to (time) without doing much . . . and if so, how
 can I force it to actually do the work?


 On Sun, Jan 25, 2009 at 11:04 AM, Emeka emekami...@gmail.com wrote:

 Hi e,

 I'm still learning the basics, very much like you( I guess you are ahead
 of me in Clojure). However, I have a question for you and not an answer to
 your questions. Why do you have doall here (def l1 (doall (take 5
 (repeatedly #(rand-int 3000) . From my little knowledge of Clojure, take
 5 would cause 'repeatedly' to be limited to 5 times and (repeatedly
 #(rand-int 3000) is an argument of take , so (take 5 (repeatedly
 #(rand-int 3000) given same results as your  (doall (take 5
 (repeatedly #(rand-int 3000 and by adding doall  you are just increasing
 'noise', that's my 2 cents.
 Doall , do, dorun are used in calling  multiple functions(I hope am like
 :)), like (do (doo noot) (move niger delta)) .

 Emeka




 



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



NewBie Q: doall forces eval and dorun not; but why?

2009-01-25 Thread wubbie

Hi,

I saw dorun and doall  in core.clj as follows:
That is, doall just calls dorun.
My question is, how come doall does force eval and dorun does not.
thanks in advance,
-sun

(defn dorun
  ([coll]
   (when (and (seq coll) (or (first coll) true))
 (recur (rest coll
  ([n coll]
   (when (and (seq coll) (pos? n) (or (first coll) true))
 (recur (dec n) (rest coll)

(defn doall
  ([coll]
   (dorun coll)
   coll)
  ([n coll]
   (dorun n coll)
   coll))

--~--~-~--~~~---~--~~
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
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: time lies, even with doall

2009-01-25 Thread Stephen C. Gilardi


On Jan 25, 2009, at 5:24 PM, e wrote:


Do folks in the contrib group like this new implementation?


To make contributions to clojure-contrib, you'll need to have a  
Contributor Agreement on file with Rich. Please see http://clojure.org/contributing 
 .


I think your implementation is an improvement over the current  
clojure.contrib.seq-utils/separate.


I have some suggestions:

	- there's precedent for functions that do one thing or another based  
on a predicate to be named with a -by suffix.
	- using vectors for the intermediate results will allow the separated  
outputs to preserve the order of the input which might be helpful to  
some callers. Since it will still give good performance, I'd opt for  
that and promise it in the doc string.
	- you might also consider using the names first and rest for the  
destructured names you called f and r. I would imagine that's a bit  
controversial (because the local names would shadow useful functions),  
but arguably it would make the implementation easier to read.

- returning a vector of vectors seems good to me.

Here's an implementation:

user  (defn separate-by [pred coll]
 (loop [in [] out [] [f  r] coll]
   (if f
 (if (pred f)
   (recur (conj in f) out r)
   (recur in (conj out f) r))
 [in out])))

#'user/separate-by
user (separate-by odd? [1 2 3 4 5 6 7])
[[1 3 5 7] [2 4 6]]
user

Whatever you propose will need a doc string.

After Rich receives your Contributor Agreement and your name is up on  
the clojure.org/contributing page, please enter an issue against  
clojure-contrib noting that your alternate implementation for the  
current clojure.contrib.seq-utils/separate has higher performance  
while still being maintainable and correct. Include a complete copy of  
the code you propose, preferably as a patch.


Once the issue is up, I'd follow up in this thread with the issue  
number requesting that Stuart consider resolving the issue by adopting  
your contribution.


--Steve



smime.p7s
Description: S/MIME cryptographic signature


Re: NewBie Q: doall forces eval and dorun not; but why?

2009-01-25 Thread Stephen C. Gilardi


On Jan 25, 2009, at 5:51 PM, wubbie wrote:


I saw dorun and doall  in core.clj as follows:
That is, doall just calls dorun.
My question is, how come doall does force eval and dorun does not.
thanks in advance,


Both force evaluation. Immediately before either returns, there is a  
fully realized sequence in memory.


The difference is in their return value:

- dorun returns nil. A call to dorun indicates:

	all the work I want done is done in the evaluation of the elements  
of the sequence, I don't plan to work with the entire sequence after  
it's realized


- doall returns the head of the realized sequence. A call to doall  
indicates:


	not only do I want the entire sequence realized, I also want to use  
the resulting sequence subsequently


It's good form to save or otherwise use the value returned by doall.

--Steve



smime.p7s
Description: S/MIME cryptographic signature


Re: NewBie Q: doall forces eval and dorun not; but why?

2009-01-25 Thread Laurent PETIT
2009/1/26 Stephen C. Gilardi squee...@mac.com


 On Jan 25, 2009, at 5:51 PM, wubbie wrote:

 I saw dorun and doall  in core.clj as follows:
 That is, doall just calls dorun.
 My question is, how come doall does force eval and dorun does not.
 thanks in advance,


 Both force evaluation. Immediately before either returns, there is a fully
 realized sequence in memory.


Are you sure ? I think the point of dorun is to prevent this case : with
dorun, the elements of the sequence can be garbage collected once dorun goes
on with the rest of the sequence, thus preventing to blow up the memory.


 The difference is in their return value:

 - dorun returns nil. A call to dorun indicates:

 all the work I want done is done in the evaluation of the elements of the
 sequence, I don't plan to work with the entire sequence after it's realized

 - doall returns the head of the realized sequence. A call to doall
 indicates:

 not only do I want the entire sequence realized, I also want to use the
 resulting sequence subsequently

 It's good form to save or otherwise use the value returned by doall.

 --Steve



--~--~-~--~~~---~--~~
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
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: NewBie Q: doall forces eval and dorun not; but why?

2009-01-25 Thread wubbie

Oh, I see the return value for doall.

When I look at dorun it is different than lots of other functions.
Unlinke lots of other functions that do conj, cons, etc. dorun just
extract each element of coll.  Is each element get evaluated if it's a
code?

Thanks
-sun



(defn dorun
  ([coll]
   (when (and (seq coll) (or (first coll) true))
 (recur (rest coll



On Jan 25, 6:21 pm, Stephen C. Gilardi squee...@mac.com wrote:
 On Jan 25, 2009, at 5:51 PM, wubbie wrote:

  I saw dorun and doall  in core.clj as follows:
  That is, doall just calls dorun.
  My question is, how come doall does force eval and dorun does not.
  thanks in advance,

 Both force evaluation. Immediately before either returns, there is a  
 fully realized sequence in memory.

 The difference is in their return value:

 - dorun returns nil. A call to dorun indicates:

         all the work I want done is done in the evaluation of the elements  
 of the sequence, I don't plan to work with the entire sequence after  
 it's realized

 - doall returns the head of the realized sequence. A call to doall  
 indicates:

         not only do I want the entire sequence realized, I also want to use  
 the resulting sequence subsequently

 It's good form to save or otherwise use the value returned by doall.

 --Steve

  smime.p7s
 3KViewDownload
--~--~-~--~~~---~--~~
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
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: NewBie Q: doall forces eval and dorun not; but why?

2009-01-25 Thread Stephen C. Gilardi



On Jan 25, 2009, at 6:45 PM, Laurent PETIT wrote:


2009/1/26 Stephen C. Gilardi squee...@mac.com

Both force evaluation. Immediately before either returns, there is  
a fully realized sequence in memory.


Are you sure ? I think the point of dorun is to prevent this case :  
with dorun, the elements of the sequence can be garbage collected  
once dorun goes on with the rest of the sequence, thus preventing  
to blow up the memory.



Right you are! Thanks for the correction. I was recalling the case of  
filter retaining the head even when it wasn't intended to. In  
reading the code for dorun, I incorrectly concluded that the coll  
argument unavoidably kept the head as well.


Instead, recur takes care of that and dorun works exactly as one might  
hope.


--Steve



smime.p7s
Description: S/MIME cryptographic signature


Re: NewBie Q: doall forces eval and dorun not; but why?

2009-01-25 Thread wubbie

then, back to my original question.
They (dorun do all) differe ONLY in return value.
Then how come one forces eval and the other not?

-sun


On Jan 25, 7:18 pm, Stephen C. Gilardi squee...@mac.com wrote:
  On Jan 25, 2009, at 6:45 PM, Laurent PETIT wrote:

  2009/1/26 Stephen C. Gilardi squee...@mac.com

  Both force evaluation. Immediately before either returns, there is  
  a fully realized sequence in memory.

  Are you sure ? I think the point of dorun is to prevent this case :  
  with dorun, the elements of the sequence can be garbage collected  
  once dorun goes on with the rest of the sequence, thus preventing  
  to blow up the memory.

 Right you are! Thanks for the correction. I was recalling the case of  
 filter retaining the head even when it wasn't intended to. In  
 reading the code for dorun, I incorrectly concluded that the coll  
 argument unavoidably kept the head as well.

 Instead, recur takes care of that and dorun works exactly as one might  
 hope.

 --Steve

  smime.p7s
 3KViewDownload
--~--~-~--~~~---~--~~
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
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: NewBie Q: doall forces eval and dorun not; but why?

2009-01-25 Thread Stephen C. Gilardi


On Jan 25, 2009, at 7:35 PM, wubbie wrote:


then, back to my original question.
They (dorun do all) differe ONLY in return value.
Then how come one forces eval and the other not?


Both force evaluation. Is there something that makes you think  
otherwise?


In the case of dorun, the members of the sequence are evaluated and  
then immediately thrown away.


In the case of doall, the members of the sequence are evaluated and  
the entire sequence is kept in memory and returned. None of the  
members are thrown away because the coll argument (which is also the  
returned value) holds a reference (in the java sense) to the first  
item, the first item holds a reference to the second item, and so on  
all the way down the chain.


--Steve



smime.p7s
Description: S/MIME cryptographic signature


Re: NewBie Q: doall forces eval and dorun not; but why?

2009-01-25 Thread Stephen C. Gilardi


On Jan 25, 2009, at 7:47 PM, Stephen C. Gilardi wrote:

In the case of dorun, the members of the sequence are evaluated and  
then immediately thrown away.


Immediately overstates it... they are left unreferenced and get  
thrown away when the Java garbage collector notices they are  
unreferenced and collects them as garbage.


--Steve



smime.p7s
Description: S/MIME cryptographic signature


Re: NewBie Q: doall forces eval and dorun not; but why?

2009-01-25 Thread wubbie

Thanks Steve for the clear explanation.
Now I get it...
But a question on ... are evaluated and then immediately thrown
away.
I believe the evaluation is done in (or (first coll) true)).
My question is that extracting out first coll is same as evaluating
first coll?
For example (first '( (+ 1 2) (+ 3 4))) returns (+ 1 2) not the
evaluated
result, which is 3.
Wait... I just tried (first (list (+ 1 2) (+ 3 4))) and got 3!
So (list a b c) is different than '( a b c)? I thought they are
equivalent!

-sun




On Jan 25, 7:47 pm, Stephen C. Gilardi squee...@mac.com wrote:
 On Jan 25, 2009, at 7:35 PM, wubbie wrote:

  then, back to my original question.
  They (dorun do all) differe ONLY in return value.
  Then how come one forces eval and the other not?

 Both force evaluation. Is there something that makes you think  
 otherwise?

 In the case of dorun, the members of the sequence are evaluated and  
 then immediately thrown away.

 In the case of doall, the members of the sequence are evaluated and  
 the entire sequence is kept in memory and returned. None of the  
 members are thrown away because the coll argument (which is also the  
 returned value) holds a reference (in the java sense) to the first  
 item, the first item holds a reference to the second item, and so on  
 all the way down the chain.

 --Steve

  smime.p7s
 3KViewDownload
--~--~-~--~~~---~--~~
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
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: NewBie Q: doall forces eval and dorun not; but why?

2009-01-25 Thread Stephen C. Gilardi


On Jan 25, 2009, at 8:05 PM, wubbie wrote:


Wait... I just tried (first (list (+ 1 2) (+ 3 4))) and got 3!
So (list a b c) is different than '( a b c)? I thought they are
equivalent!


Right, as your experiment shows, the ' in '(a b c) quotes both the  
list itself and all of its contents.


Using vectors to hold your data can be a convenient way to experiment  
because you don't have to worry about avoiding the special evaluation  
rules for lists.


user= [(+ 1 2) (+ 3 4)]
[3 7]

One strategy for working with Clojure is to favor using:

- lists mostly for function calls,
- vectors, maps, and sets mostly for collecting data, and
- seqs (and the seq functions) mostly for manipulating data.

Clojure's rich set of literal syntax for collections other than lists  
is very helpful in keeping code readable while following that strategy.


--Steve



smime.p7s
Description: S/MIME cryptographic signature


Re: time lies, even with doall

2009-01-25 Thread e
ok, I'll check that stuff out.  Thanks.

It occurs to me this is being compared to something in ruby called
partition.  I like that name.  partition-by ... but maybe it was opted to
use the simpler name, which I can appreciate.

On that subject, I know filter is standard from other languages like
Haskell, but I had to learn that it meant retain-if.  To me, filter
sounds synonymous with remove.  Other candidates: keep, preserve.
Also, that -by convention sounds right for partition or separate, but in
the case of filter and remove, if sounds better.  I suggest breaking from
the filter tradition and going with retain-if and remove-if.

On Sun, Jan 25, 2009 at 6:10 PM, Stephen C. Gilardi squee...@mac.comwrote:


 On Jan 25, 2009, at 5:24 PM, e wrote:

  Do folks in the contrib group like this new implementation?


 To make contributions to clojure-contrib, you'll need to have a Contributor
 Agreement on file with Rich. Please see http://clojure.org/contributing .

 I think your implementation is an improvement over the current
 clojure.contrib.seq-utils/separate.

 I have some suggestions:

- there's precedent for functions that do one thing or another based
 on a predicate to be named with a -by suffix.
- using vectors for the intermediate results will allow the
 separated outputs to preserve the order of the input which might be helpful
 to some callers. Since it will still give good performance, I'd opt for that
 and promise it in the doc string.
- you might also consider using the names first and rest for the
 destructured names you called f and r. I would imagine that's a bit
 controversial (because the local names would shadow useful functions), but
 arguably it would make the implementation easier to read.
- returning a vector of vectors seems good to me.

 Here's an implementation:

 user  (defn separate-by [pred coll]
 (loop [in [] out [] [f  r] coll]
   (if f
 (if (pred f)
   (recur (conj in f) out r)
   (recur in (conj out f) r))
 [in out])))

 #'user/separate-by
 user (separate-by odd? [1 2 3 4 5 6 7])
 [[1 3 5 7] [2 4 6]]
 user

 Whatever you propose will need a doc string.

 After Rich receives your Contributor Agreement and your name is up on the
 clojure.org/contributing page, please enter an issue against
 clojure-contrib noting that your alternate implementation for the current
 clojure.contrib.seq-utils/separate has higher performance while still being
 maintainable and correct. Include a complete copy of the code you propose,
 preferably as a patch.

 Once the issue is up, I'd follow up in this thread with the issue number
 requesting that Stuart consider resolving the issue by adopting your
 contribution.

 --Steve



--~--~-~--~~~---~--~~
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
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: NewBie Q: doall forces eval and dorun not; but why?

2009-01-25 Thread e
interesting to me that  wasn't used for anything to add to the literal
syntax.  folks in another thread were using sequences for set theory.  But
maybe there needs to be a set notation.  If that makes sense, {} should be
sets, just like in math,  should be vectors, just like in math, and []
could be maps.  I know, I know, it's kinda late to be arguing to change this
stuff.  Another idea that fits in better would be to use  as an
alternative to quoting a list . . . and still not do anything for sets.

On Sun, Jan 25, 2009 at 8:25 PM, Stephen C. Gilardi squee...@mac.comwrote:


 On Jan 25, 2009, at 8:05 PM, wubbie wrote:

  Wait... I just tried (first (list (+ 1 2) (+ 3 4))) and got 3!
 So (list a b c) is different than '( a b c)? I thought they are
 equivalent!


 Right, as your experiment shows, the ' in '(a b c) quotes both the list
 itself and all of its contents.

 Using vectors to hold your data can be a convenient way to experiment
 because you don't have to worry about avoiding the special evaluation rules
 for lists.

 user= [(+ 1 2) (+ 3 4)]
 [3 7]

 One strategy for working with Clojure is to favor using:

- lists mostly for function calls,
- vectors, maps, and sets mostly for collecting data, and
- seqs (and the seq functions) mostly for manipulating data.

 Clojure's rich set of literal syntax for collections other than lists is
 very helpful in keeping code readable while following that strategy.

 --Steve



--~--~-~--~~~---~--~~
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
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: NewBie Q: doall forces eval and dorun not; but why?

2009-01-25 Thread Meikel Brandmeyer

Hi,

Am 26.01.2009 um 06:05 schrieb e:

interesting to me that  wasn't used for anything to add to the  
literal syntax.  folks in another thread were using sequences for  
set theory.  But maybe there needs to be a set notation.  If that  
makes sense, {} should be sets, just like in math,  should be  
vectors, just like in math, and [] could be maps.  I know, I know,  
it's kinda late to be arguing to change this stuff.  Another idea  
that fits in better would be to use  as an alternative to quoting  
a list . . . and still not do anything for sets.


There is already literal syntax for all the collection types:

- [] = vector
- {} = hash-map
- #{} = set

What are you missing?

Try to blend out experiences from other fields. Eg. we never
used  for vectors in math, only (). So even this comparison
is only your personal experience. It's good to have such
experience when learning a new language, but it should not
get into your way. Whenever you end up with But in this other
field/language we do/have/can , you should take a step
back and forget about the other field/language and look
simply at Clojure. We cannot cater all the previous experiences
of all the Clojure users

Just my 2¢.

Sincerely
Meikel



smime.p7s
Description: S/MIME cryptographic signature


doall vs. dorun

2009-01-20 Thread Mark Volkmann

Can someone describe a situation where it is preferable to use doall
instead of dorun? I see in the documentation that it retains the head
and returns it, thus causing the entire seq to reside in memory at one
time, but I'm not sure why I'd want that.

-- 
R. Mark Volkmann
Object Computing, Inc.

--~--~-~--~~~---~--~~
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
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: doall vs. dorun

2009-01-20 Thread Nathanael Cunningham
Pretty much any lazy-seq thats reading data from somewhere that might give
up on you if you take to long. For example: Your using line-seq to read from
a socket, but the sequence wont be read through until the user does
something.

On Tue, Jan 20, 2009 at 3:32 PM, Mark Volkmann r.mark.volkm...@gmail.comwrote:


 Can someone describe a situation where it is preferable to use doall
 instead of dorun? I see in the documentation that it retains the head
 and returns it, thus causing the entire seq to reside in memory at one
 time, but I'm not sure why I'd want that.

 --
 R. Mark Volkmann
 Object Computing, Inc.

 



-- 
-Nate

--~--~-~--~~~---~--~~
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
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: doall vs. dorun

2009-01-20 Thread Stuart Sierra

On Jan 20, 3:32 pm, Mark Volkmann r.mark.volkm...@gmail.com wrote:
 Can someone describe a situation where it is preferable to use doall
 instead of dorun?

Here's one:

(defn read-my-file []
  (with-open [reader (BufferedReader. (FileReader. my-file.txt))]
(doall (line-seq reader

line-seq returns a lazy sequence, but you have to consume that
sequence before with-open closes the file.

-Stuart Sierra
--~--~-~--~~~---~--~~
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
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: doall vs. dorun

2009-01-20 Thread Mark Triggs

In addition to what others have said, I also tend to use doall when
working with agent actions that return sequences (i.e. to force any
computation to happen in the agent's thread and not in the caller's)

Cheers,

Mark

On Wed, Jan 21, 2009 at 7:32 AM, Mark Volkmann
r.mark.volkm...@gmail.com wrote:

 Can someone describe a situation where it is preferable to use doall
 instead of dorun? I see in the documentation that it retains the head
 and returns it, thus causing the entire seq to reside in memory at one
 time, but I'm not sure why I'd want that.

 --
 R. Mark Volkmann
 Object Computing, Inc.

 


--~--~-~--~~~---~--~~
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
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: doall vs. dorun

2009-01-20 Thread Mark Volkmann

On Tue, Jan 20, 2009 at 3:14 PM, Stuart Sierra
the.stuart.sie...@gmail.com wrote:

 On Jan 20, 3:32 pm, Mark Volkmann r.mark.volkm...@gmail.com wrote:
 Can someone describe a situation where it is preferable to use doall
 instead of dorun?

 Here's one:

 (defn read-my-file []
  (with-open [reader (BufferedReader. (FileReader. my-file.txt))]
(doall (line-seq reader

 line-seq returns a lazy sequence, but you have to consume that
 sequence before with-open closes the file.

How is it different if you change doall to dorun? According to
their doc strings, they both can be used to force any effects. Walks
through the successive rests of the seq

-- 
R. Mark Volkmann
Object Computing, Inc.

--~--~-~--~~~---~--~~
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
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: doall vs. dorun

2009-01-20 Thread Stephen C. Gilardi


On Jan 20, 2009, at 5:32 PM, Mark Volkmann wrote:


Here's one:

(defn read-my-file []
(with-open [reader (BufferedReader. (FileReader. my-file.txt))]
  (doall (line-seq reader

line-seq returns a lazy sequence, but you have to consume that
sequence before with-open closes the file.


How is it different if you change doall to dorun? According to
their doc strings, they both can be used to force any effects. Walks
through the successive rests of the seq


Using doall will cause read-my-file to return a seq of all the lines.  
dorun will return nil.


Here's a simpler example:

user= (doall (map #(do (prn %) %) [1 2 3]))
1
2
3
(1 2 3)
user= (dorun (map #(do (prn %) %) [1 2 3]))
1
2
3
nil
user=

(Note the difference in return value.)

--Steve



smime.p7s
Description: S/MIME cryptographic signature


Re: doall vs. dorun

2009-01-20 Thread Cosmin Stejerean
On Tue, Jan 20, 2009 at 4:32 PM, Mark Volkmann r.mark.volkm...@gmail.comwrote:


 On Tue, Jan 20, 2009 at 3:14 PM, Stuart Sierra
 the.stuart.sie...@gmail.com wrote:
 
  On Jan 20, 3:32 pm, Mark Volkmann r.mark.volkm...@gmail.com wrote:
  Can someone describe a situation where it is preferable to use doall
  instead of dorun?
 
  Here's one:
 
  (defn read-my-file []
   (with-open [reader (BufferedReader. (FileReader. my-file.txt))]
 (doall (line-seq reader
 
  line-seq returns a lazy sequence, but you have to consume that
  sequence before with-open closes the file.

 How is it different if you change doall to dorun? According to
 their doc strings, they both can be used to force any effects. Walks
 through the successive rests of the seq


Use dorun when you want to do something purely for the side effects. If you
don't need what doall would return then you can use dorun instead to clearly
indicate your intent.

-- 
Cosmin Stejerean
http://offbytwo.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
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: doall vs. dorun

2009-01-20 Thread Mark Volkmann

Thanks Steve and Cosmin! I understand it now.

On Tue, Jan 20, 2009 at 4:53 PM, Stephen C. Gilardi squee...@mac.com wrote:

 On Jan 20, 2009, at 5:32 PM, Mark Volkmann wrote:

 Here's one:

 (defn read-my-file []
 (with-open [reader (BufferedReader. (FileReader. my-file.txt))]
  (doall (line-seq reader

 line-seq returns a lazy sequence, but you have to consume that
 sequence before with-open closes the file.

 How is it different if you change doall to dorun? According to
 their doc strings, they both can be used to force any effects. Walks
 through the successive rests of the seq

 Using doall will cause read-my-file to return a seq of all the lines. dorun
 will return nil.

 Here's a simpler example:

user= (doall (map #(do (prn %) %) [1 2 3]))
1
2
3
(1 2 3)
user= (dorun (map #(do (prn %) %) [1 2 3]))
1
2
3
nil
user=

 (Note the difference in return value.)

 --Steve





-- 
R. Mark Volkmann
Object Computing, Inc.

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



Curiosity: why doesn't (count (doall (range 1000000000))) exhaust memory?

2008-12-21 Thread Jason

Yet another question, this time just a curiosity.  Sorry for the
plethora of posts, but I'm trying to make sure I understand lazy seqs
properly.

Why doesn't (count (doall (range 100))) cause an out-of memory
error?  doall says it causes the entire seq to reside in memory at one
time, yet:

user (count (range 1))  ; uses no memory, as expected
1
user (count (doall (range 1))) ; still uses no memory!?
1
user (count (doall (range 5))) ; even bigger, still no heap
growth
5
user (count (doall (map identity (range 1 ; now as
expected
; Out of memory

Thanks,
Jason
--~--~-~--~~~---~--~~
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
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: Curiosity: why doesn't (count (doall (range 1000000000))) exhaust memory?

2008-12-21 Thread Stephen C. Gilardi


On Dec 21, 2008, at 6:44 PM, Jason wrote:


Why doesn't (count (doall (range 100))) cause an out-of memory
error?  doall says it causes the entire seq to reside in memory at one
time, yet:


(range n) produces an object that is a seq, not just one that's seq- 
able. Its rest operation is not implemented using lazy-cons, instead  
it returns an object that implements the rest seq in a self-contained  
way: a Range object that starts one increment higher. (see  
clojure.lang.Range, implementation of first and rest)


Holding onto the head in this case, does not keep a realized chain of  
objects in memory. Instead it holds the first one only. Subsequent  
rests are generated one by one during the doall and then discarded.


Your map example turns this into a chain of lazy-cons objects with the  
associated much greater memory use.


The doc for doall should probably be updated to say something along  
the lines of it may cause the sequence to reside in memory all at  
once.


--Steve



smime.p7s
Description: S/MIME cryptographic signature


Re: doall and dorun

2008-12-16 Thread Christian Vest Hansen

I think I'll be putting my money on (for) returning a cached lazy seq,
and (macroexpand) also tells me that there's a lazy-cons hidin in
there:

user= (macroexpand '(for [i (range 1 3)] (do (println i) i)))
(let* [iter__4007 (clojure.core/fn iter__7 [s__8]
(clojure.core/when-first [i s__8] (clojure.core/when true (if true
(clojure.core/lazy-cons (do (println i) i) (iter__7 (clojure.core/rest
s__8))) (recur (clojure.core/rest s__8))] (iter__4007 (range 1
3)))

So the side-effects are only executed once, and then the result is
cached, and if you ask Rich he'd probably tell you that that is by
design.

On Tue, Dec 16, 2008 at 7:02 AM, Brian Doyle brianpdo...@gmail.com wrote:
 I'll take a crack at this.  It may appear that the doall and dorun return
 something
 different with subsequent calls but they don't actually.   The doall always
 returns
 the sequence (1 2) and dorun always returns nil.

 The first time (doall x) is called the for loop executes and prints 1 2 (a
 side effect
 and is not returned from the for loop) and then returns the seq.  The second
 time
 it's called x is already assigned the seq and just returns it. It does not
 execute
 the for loop again.

 The dorun call is similar, but instead of returning the seq of the for loop,
 it always
 returns nil.  According to the api docs, dorun is used to force side
 effects.

 On Mon, Dec 15, 2008 at 9:19 PM, wubbie sunj...@gmail.com wrote:

 Hello,

 doall and dorun returns different results from seond run on...
 e.g.
 user= (def x (for [i (range 1 3)] (do (println i) i)))
 #'user/x
 user= (doall x)
 1
 2
 (1 2)
 user= (doall x)
 (1 2)
 user= (doall x)
 (1 2)
 user=

 user= (def x (for [i (range 1 3)] (do (println i) i)))
 #'user/x
 user= (dorun x)
 1
 2
 nil
 user= (dorun x)
 nil
 user= (dorun x)
 nil
 user=


 What's the explanation for that?

 thanks
 sun






 




-- 
Venlig hilsen / Kind regards,
Christian Vest Hansen.

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



doall and dorun

2008-12-15 Thread wubbie

Hello,

doall and dorun returns different results from seond run on...
e.g.
user= (def x (for [i (range 1 3)] (do (println i) i)))
#'user/x
user= (doall x)
1
2
(1 2)
user= (doall x)
(1 2)
user= (doall x)
(1 2)
user=

user= (def x (for [i (range 1 3)] (do (println i) i)))
#'user/x
user= (dorun x)
1
2
nil
user= (dorun x)
nil
user= (dorun x)
nil
user=


What's the explanation for that?

thanks
sun



--~--~-~--~~~---~--~~
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
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: doall and dorun

2008-12-15 Thread Brian Doyle
I'll take a crack at this.  It may appear that the doall and dorun return
something
different with subsequent calls but they don't actually.   The doall always
returns
the sequence (1 2) and dorun always returns nil.

The first time (doall x) is called the for loop executes and prints 1 2 (a
side effect
and is not returned from the for loop) and then returns the seq.  The second
time
it's called x is already assigned the seq and just returns it. It does not
execute
the for loop again.

The dorun call is similar, but instead of returning the seq of the for loop,
it always
returns nil.  According to the api docs, dorun is used to force side
effects.

On Mon, Dec 15, 2008 at 9:19 PM, wubbie sunj...@gmail.com wrote:


 Hello,

 doall and dorun returns different results from seond run on...
 e.g.
 user= (def x (for [i (range 1 3)] (do (println i) i)))
 #'user/x
 user= (doall x)
 1
 2
 (1 2)
 user= (doall x)
 (1 2)
 user= (doall x)
 (1 2)
 user=

 user= (def x (for [i (range 1 3)] (do (println i) i)))
 #'user/x
 user= (dorun x)
 1
 2
 nil
 user= (dorun x)
 nil
 user= (dorun x)
 nil
 user=


 What's the explanation for that?

 thanks
 sun



 


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