This is almost the same as an issue I raised in this group over a year and 
a half ago, here 
I suggested that Clojure should include function with map's syntax but that 
was executed only for side-effects, without constructing sequences.  No one 
else was interested--no problem.   It's still bugging me.

It's not map syntax that I care about at this point.  What's bugging me is 
that there's no standard, built-in way to process multiple sequences for 
side effects without (a) constructing unnecessary sequences or (b) rolling 
my own function with loop/recur or something else.

If I want to process multiple sequences for side-effects in the the way 
that 'for' does, Clojure gives me 'doseq'.  Beautiful.  I can operate on 
the cross product of the sequences, or filter them in various ways.

If I want to process multiple sequences by applying an n-ary function to 
the first element of each of n sequences, then to the second element of 
each sequence, and so on, I can use 'map' or 'mapv', but that means 
constructing unnecessary collections.

Or I can splice my n sequences together, and make a single sequence of 
n-tuples, and use doseq to process it.  (There's an example like this on 
the doseq doc page.)  Or I can process such a sequence with 'reduce'.  More 
unnecessary collections, though.

Or I can use 'dotimes', and index into each of the collections, which is OK 
if they're vectors, but ... ugh. why?

Or I can construct my own function using first and rest or first and next 
on each of my sequences, via loop/recur, for example.   But that seems odd 
to me.  

Isn't this a common use case?  Is processing multiple sequences for 
side-effects with corresponding elements in each application so unusual?  
(Am I the only one?)  Isn't it odd that we have doseq and map but nothing 
that processes multiple sequences for side-effects, in sequence, rather 
than as a cross-product?  

(I admit that in my current use case, the sequences are small, so creating 
a sequence of n-tuples would have only a trivial cost.  It just bugs me, 
though. :-)

I'd still be OK with something that had a map-like syntax, but my current 
inclination is that it would be better for such a function to have 
doseq-style syntax.  The name might be derived from "doseq"--maybe 

(I'd be willing to suggest this in a JIRA ticket, but that doesn't seem 
reasonable unless there's a call for something like this from more than one 

You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
For more options, visit this group at
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 
For more options, visit

Reply via email to