Clojure 1.7 is now available • Hacker News Board

Re: Clojure 1.7 is now available

#121

Post by justthistime_ » Wed, Jul 01, 2015, 1:11 PM UTC

pron wrote: post #115

justthistime_ wrote: post #107

Earlier quoted context omitted.

I guess I must have been dreaming when seperate compilation fell apart in Koltin recently due to backward-incompatible changes.

Kotlin announced that until the upcoming 1.0 release there will be breaking changes, but not after. Binary compatibility will not be 100% guaranteed, but it's a high priority.

So there will be basically no change to the status quo?

Looks like Kotlin will join Ceylon in terms of promising things and then failing to ship them. Post-1.0 Ceylon is still breaking compatibility.

Re: Clojure 1.7 is now available

#122

Post by kazinator » Wed, Jul 01, 2015, 2:01 PM UTC

ds300 wrote: post #118

kazinator wrote: post #113

Earlier quoted context omitted.

Transducers are functions. The thing is that they are functions that are designed to serve as the functional argument to reduce. And they pair with ordinary functions which are not transducers. For instance if we have (map inc [1 2]), there exists a transducer function T such that: (reduce T [1 2]) == (map inc [1 2]) I.e. we can somehow do "map inc" using reduce. Okay? Now, the clever thing is this: why don't we allo…

> (reduce (map inc) [1 2]) ;; same as (map inc [1 2]) This is wrong. You've missed the point. (map inc [1 2]) is actually roughly equivalent to (reduce ((map inc) conj) [] [1 2]) which, due to the use of `reduce`, is eager. To get laziness back: (sequence (map inc) [1 2]) Transducers are not reducing functions, they return reducing functions when applied to reducing functions. `((map inc) conj)` is a version of `conj…

I suspected I had to be not quite understanding something, because why would we want, say, a map based on reduce that chokes on lazy lists, in a language where laziness is important.

Re: Clojure 1.7 is now available

#123

Post by sindux » Wed, Jul 01, 2015, 2:32 PM UTC

bad_user wrote: post #77

enoch_r wrote: post #15

Earlier quoted context omitted.

If you have an understanding of functions like map, filter, and reduce, transducers are actually pretty easy. Say you have `(map inc [1 2])`. You can run that, and get `'(2 3)`. A transducer is the `(map inc)` part of that call (slightly confusingly, this isn't partial application or currying). You can apply it to something like `[1 2]`, but you can also compose with it, by combining it with say, `(filter even?)` to…

I think people are seriously underestimating the protocol involved and understanding that protocol is required if you want to build your own transducers compatible streaming, which is always useful. There's also the issue that the protocol in question may not be generic enough. From the presentations I've seen it claims that it might work with Rx streams as well, however I don't think it can deal with back-pressure.…

Adding to weavejester comment, back-pressure is to be handled with core.async channels [1]. I guess in Rich's terms, RX/FRP "complects" the communication of messages with flow of control [2]. Although this last statement may not be true anymore given that RX now has many functions to control the scheduler (eg. observeOn/buffer/delay, etc).

[1] http://clojure.com/blog/2013/06/28/clojure-core-async-channe... [2] http://stackoverflow.com/questions/20632512/comparing-core-a...

Re: Clojure 1.7 is now available

#124

Post by village-idiot » Wed, Jul 01, 2015, 2:45 PM UTC

aoeuasdf1 wrote: post #52

enoch_r wrote: post #15

Earlier quoted context omitted.

If you have an understanding of functions like map, filter, and reduce, transducers are actually pretty easy. Say you have `(map inc [1 2])`. You can run that, and get `'(2 3)`. A transducer is the `(map inc)` part of that call (slightly confusingly, this isn't partial application or currying). You can apply it to something like `[1 2]`, but you can also compose with it, by combining it with say, `(filter even?)` to…

The way you explain it, it's no different from functions and function composition; in which case, why invent new vocabulary? I do remember looking into them before and translating them into Haskell and they ended up not being identical to functions in the trivial sense that you suggest, but I forget how.

Older collection functions were semi-lazy by default. They auto-realized in chunks of 32. Transducers wrap the functions then pass the data through, allowing full-laziness (or not if you want) by default.

They also work well in cases where you don't know if/when a new value is coming, like in channels or observables. This is because they aren't necessarily wed to the seq abstraction from the get-go.

Re: Clojure 1.7 is now available

#125

Post by weavejester » Sun, Jul 05, 2015, 10:33 AM UTC

bad_user wrote: post #111

weavejester wrote: post #109

Earlier quoted context omitted.

Transducers are, I believe, largely orthogonal to back-pressure concerns. They describe only how transform the data at each step.

That's not correct, because if they described only how to transform the data at each step, then you couldn't describe `take` or `flatMap`.

Because Clojure isn't a pure functional language, transducers may be stateful. `take` uses a volatile (i.e. a fast, mutable variable) to retain state. I don't believe a `flatMap` transducer exists in Clojure yet.