This is almost the same as an issue I raised in this group over a year and a half ago, here <https://groups.google.com/forum/#!msg/clojure/bn5QmxQF7vI/vO1XLSyPXC8J;context-place=forum/clojure>. 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 "doseq*". (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 person.) -- 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.
