Reducers API style question

You didn't miss my point. Thanks for the explanation. I guess what I'm saying is that the 'wrapped' bit is unnecessary, since once you've reduced a collection and have a result, the only thing you're likely to reuse is the reduction objects, not the wrapper object. I'm proposing that your API reflect the action of using a reducer on a collection, "hiding" the wrapping step.

transformation := #squared mapping <> #odd filtering <> Set.

(1 to: 3) collect: transformation    -> Set(1 9)

In many respects, if the last thing you specify is the collection to operate on, then the description of the transformation should be right-to-left, eg:

transformation := Set <> #odd filtering <> #squared mapping <> (1 to: 3).

But if you still like the idea of wrapping, then it might make more sense to flip it back around like this:

transformation := (1 to: 3) <> #squared mapping <> #odd filtering <> Set.

As you can see in both these scenarios, there's no verb to indicate that you want to do it. Unless it acts as a virtual collection (which it doesn't seem to do) you'd want the verb, which is why above I was suggesting you give the reducer object(s) to the collection as an action.

transformation := #squared mapping <> #odd filtering <> #+ reducing.

sum := (1 to: 3) inject: 0 into: transformation.

Here the transformation object takes the place of the traditional block, as above with the collect: example. The idea is that the collection protocol need not have to know the difference between a block closure or a reducer and therefore the same APIs we currently use can be reused. At least, some of them anyway.

I also used the collection itself as part of the reducer binding so that it would unique the items. One thing that is a little confusing for me is the use of <> which suggests directionality is not important - but it seems to me that it is somewhat important - unless I'm mistaken, there's no obvious way to 'undo' a transformation, especially if you've done a reduction like inject:into:.

You'd have to know the opposite of +, the opposite of #squared, the opposite of #odd, etc.. all of which tells me that directionality is important. Given you're dealing with reducer objects (and perhaps a couple of others like classes) it might be better to use a more asymmetrical selector.

Off the top of my head, it could be something like ~> to indicate a direction that data will flow through the objects.

transformation := #squared mapping ~> #odd filtering ~> Set.

theAnswer := (1 to: 3) collect: transformation.

I'm keen on the composability of the reducers, just as closures are. The whole thing is very bimadic (as opposed to monadic).

Cheers,

Michael

On 6 May 2014 18:37, Steffen Märcker <[hidden email]> wrote:

Hi Michael,

thanks for your thoughts. I agree, that the reducer terminology should fade into the background. =)

Considering your examples, I am afraid that I failed to make clear what #reduce:init: does and what a reducer object is. Sorry, here's my second attempt:

1) "reduce: block init: value" is #inject:into: ; it serves as an interface on top of which all other enumerations (map, filter, etc.) can be implemented.

2) A reducer is a wrapper on a collection (an object that understands #reduce:init:) providing a 'transformed view' on a collection. For example,

  successors := [:x|x+1] mapping from: (1 to: 10).

creates a Reducers wrapping the interval. When sending #reduce:init: to that reducer, the block is evaluated with the successors, i.e., (2 to: 11).
Reducers can be curried and combined independently of a collection. The message #from: is only used to finally wrap a collection. The actual computation is performed by invoking #reduce:init: (#into: calls #reduce:init:).

   view := #squared mapping <> #odd filtering <> [:x|x+1] mapping.
   wrapped_1 := view from: (1 to: 10).
   sum := wrapped_1 reduce: #+ init: 0. "computation is performed here"
   wrapped_2 := view from: #(1 2 3).
   set := wrapped_2 into: Set. "computation is performed here"

Does this make more sense to you? Or did I completely miss your point?

Best,
Steffen


Am 06.05.2014, 09:02 Uhr, schrieb Michael Lucas-Smith <[hidden email]>:

On 6 May 2014, at 4:27 pm, Steffen Märcker <[hidden email]> wrote:

Hi,

I am about to simplify the API a bit and I am really eager to hear your opinion. Suppose we want to gather squares of odds numbers. Previously, we could write:

  (Reducer map: #squared) <> (Reducer filter: #odd)
     from: #(1 2 3 4 5 6).

The repetition of 'Reducer' makes this pretty verbose. I intend to change this to

  #squared mapping <> #odd filtering
     from: #(1 2 3 4 5 6).

I like this. The ‘reducer’ terminology disappears and is no longer a question of what the code is doing.

However, flattening a nested collection requires no parameter (like mapping or filtering). Thus it does not quite fit this style (flattening is done by a singleton object):

  #squared mapping <> #odd filtering <> ?_flattening_?
     from: #((1 2 3) (4 5 6)).

How would you implement flattening in this API style? So far, I see only two options:

1) Either extending the class side of Flattening to support the composition protocol:
  #squared mapping <> #odd filtering <> Flattening

This would be my preference. I’d feel comfortable if a ‘reducer’ could be a Reducer, class, or finally a closure for the ultimate in flexibility.
The other part of this API that doesn’t sit quite right with me is the ‘from’ method. The reduces let you predefine a program that can execute.. so you’d be applying it to a collection, or running it with a collection, e.g.:

(1 to: 15) reduce: (#squared mapping <> #odd filtering <> [:each | each + 1])

(#squared mapping <> #odd filtering <> [:each | each + 1]) reduce: (1 to: 15)

Not sure which direction reads better. Collection>>reduce: fits in with all the other collection protocols, while Reducer>>reduce: is much more verb-like and owned by the subsystem (reducers) that you’re using (similar to doing BlockClosure>>value: in that respect, since a BlockClosure is a program and so is a Reducer).

Cheers,
Michael