On Thu, Nov 01, 2012 at 15:11 +0900, Alan Busby wrote: > On Mon, Oct 29, 2012 at 10:00 PM, Wolodja Wentland <[email protected]> wrote: > > I find this behaviour quite unfortunate because I now have to explicitly > > test > > for nil? and ensure consistent behaviour. This inconsistency violates the > > principle of least-surprise and I am not sure if the current behaviour is > > intentional or merely an unfortunate implementation detail. > > fold wont work in parallel on list/seqs/etc, so if you're trying to > get the improved threading performance out of fold/fold-into-vec > you'll have to supply a vector.
I am aware of that, but just tried to highlight the behaviour with nil. Your ensure-vec function will actually do the right thing™ here, so I might just start using that. It seems to me as if we are currently figuring out which (boilerplate?) functions are missing in reducers.clj and that we will have a nice and well-integrated library at the end. > > P.S. Would it be possible to have something like fold-into-vec in > > clojure.reducers? > > Don't forget fold-into-map and fold-into-map-with, but both of those > will likely require a better merge/merge-with function for maps. :( Oh, fold-into-map and fold-into-map-with would be wonderful and I tried to implement the former along the lines of fold-into-vec, but the performance was abysmal. I am now using fold-into-vec + r/map with zipmap which is better, but I wouldn't consider that optimal. -- Wolodja <[email protected]> 4096R/CAF14EFC 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC
signature.asc
Description: Digital signature
