Yes you are right, currently a lot of stuff is seq only. I think that reducers provide a lot of eager operations, but not everything.
So yeah, transducers are exactly what you are looking for. If you call `sequence` with the transducer you get laziness, if you call `into` with a collection and a transducer, you get eagerness :). No decision about the evaluation strategy has to be made up until that point, and afaik transducers implement most classical seq constructs. On 11 Oct 2014, at 21:09, Mars0i <marsh...@logical.net> wrote: > I don't think I have any misconceptions. I probably haven't expressed myself > clearly. Clojure has many very useful functions that return lazy sequences. > Analogous functions in other languages perform what are exactly the same > operations, except for the fact that what's returned is not a lazy sequence, > but instead is a different kind of sequential structure. For example, Common > Lisp'smapcar is very much like Clojure's map, but mapcar returns a (non-lazy) > singly-linked list. As you point out, there are also functions in Clojure > that return sequential structures that are not lazy. Moreover, it's easy to > convert a lazy sequence into a non-lazy sequence through use of, for example, > doall or vec. > > However, writing code in Clojure that only used non-lazy sequences would be > unnatural and verbose, as Lee points out. No one would bother doing that. > Part of what's great about Clojure is the convenience of its set of sequence > operations. If you're not using those, you're not getting full benefit from > Clojure. So as a practical matter, one must deal with laziness in Clojure. > > However, almost the same language could be constructed without any laziness, > just by replacing lazy functions such as map with non-lazy analogues. In > that case, you could do all of the same things in those situations that don't > require laziness. (You couldn't use lazy infinite sequences, and you'd have > to worry about keeping large data structures in memory, etc. But in many > situations, those features aren't needed.) > > That's what I mean by "turning off laziness": Replacing every function that > returns a lazy sequence with its closest non-lazy analogue. > > On Saturday, October 11, 2014 12:01:34 PM UTC-5, Jan-Paul Bultmann wrote: > I feel that there are some misconceptions here, > Clojure is not a language that has lazy evaluation, > but is instead completely eager. > Macros are the closest thing that come to laziness, but they are still > different. > However, Clojure has a data structure, that also serves as an abstraction > layer, > that implements laziness, called a sequence or seq. > > Therefor "turning of laziness" makes no real sense. You could say "disable > the laziness of seqs", > but that doesn't really make sense either. It's like disabling the FIFO > nature of a queue or a channel. > If you don't want the properties of a seq, then use another data structure, > like a vector. > > > On 11 Oct 2014, at 18:14, Mars0i <mars...@logical.net> wrote: > >> Thanks Jan-Paul. That's helpful. I wonder whether, if all lazy functions >> were rewritten in terms of transducers, it would then be easy to turn >> laziness on and off. (I am not suggesting that this should be done. No >> doubt it would entail a lot of work, and performance tradeoffs. I'm quite >> happy with Clojure as it is, despite anything negative I might say about >> impacts of laziness in some circumstances.) >> >> On Saturday, October 11, 2014 5:00:36 AM UTC-5, Jan-Paul Bultmann wrote: >> Transducers build up transformation steps, with new generic operations like >> single arg `map` and `filter`, and then apply these transformations to a >> collection using an evaluation function. >> This function decides if operations are done lazily, eagerly, or on a >> channel. >> >> Note that while this makes the place where laziness occurs more obvious, it >> is not really new. >> You can currently infer as well that `map` `filter` `concat` e.t.c are lazy. >> While `mapv` or `filterv` are not. >> >> >> On 11 Oct 2014, at 00:28, Mars0i <mars...@logical.net> wrote: >> >>> >>> >>> On Friday, October 10, 2014 5:20:30 PM UTC-5, Mars0i wrote: >>> Maybe an ideal world would be one in which there was a global setting to >>> turn laziness on and off. When you want it, have it, and know your risks. >>> After looking at the source for some of the lazy functions, I've come to >>> suspect that such a feature would be completely nontrivial. >>> >>> Oh, wait, Rich Hickey's blog post about transducers says: >>> >>> But transducers can also be used for: >>> >>> a la carte laziness >>> ... >>> collection/iteration/laziness-free transforming reductions >>> >>> Not certain what this means. Haven't fully grokked reducers. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clo...@googlegroups.com >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+u...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >>> --- >>> You received this message because you are subscribed to the Google Groups >>> "Clojure" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email toclojure+u...@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 clo...@googlegroups.com >> Note that posts from new members are moderated - please be patient with your >> first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+u...@googlegroups.com. >> For more options, visit https://groups.google.com/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 toclojure+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.
