<div dir="ltr">ROK,<div><br></div><div>A use case I often bump into is modifying some state using the accessors already written for this structure.</div><div><br></div><div>For example, modifying a record:</div><div><br></div><div><div>    PvtFuns = [ fun add_pvt_type/1</div><div>                     , fun add_pvt_vsn/1</div><div>                     , fun maybe_add_pvt_api_key/1</div><div>                     , fun maybe_add_pvt_tree/1</div><div>                     , fun add_pvt_enabled/1</div><div>                     ],</div><div>    NewRecord = lists:foldl(fun(F, C) -> F(C) end, Record, PvtFuns),</div></div><div><br></div><div>Or some opaque structure, with accessors written more seriously:</div><div><br></div><div><div>    NewContext =</div><div>        cb_context:setters(Context, [ {fun cb_context:set_doc/2, []}</div><div>                                                     , {fun cb_context:set_resp_status/2, 'success'}</div><div>                                                     , {fun cb_context:set_resp_data/2, []}</div><div>                                                     , {fun cb_context:set_resp_etag/2, 'undefined'}</div><div>                                                     ])<br></div></div><div><br></div><div>Where setters/2 is a call to lists:foldl/3.</div><div><br></div><div>A pipe operator would turn this structure-specific code into something more readable and editable too.</div><div>Maybe like something like this:</div><div><br></div><div><div>    NewContext = Context</div><div>        |> cb_context:set_doc(_, [])</div><div>        |> cb_context:set_resp_status(_, success)</div><div>        |> cb_context:set_resp_data(_, [])</div><div>        |> cb_context:set_resp_etag(_, undefined)</div></div><div><br></div><div>Where m:f(_, A2) is fun (_1) -> m:f(_1, A2) end; thus redefining _ for pipes (in non-matching contexts…).</div><div><br></div><div>Scoping rules for nested pipes looks like a hard problem, but I am not sure nestedness would be a great thing to have…</div><div><br></div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div><br></div><div>Cheers,</div><div>-- </div><div>Pierre Fenoll</div></div><div><br></div></div></div></div>
<br><div class="gmail_quote">On 9 July 2015 at 19:01, Richard A. O'Keefe <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz" target="_blank">ok@cs.otago.ac.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">For what it's worth, I implemented |> in my Smalltalk system.<br>
It's astonishing how useful it isn't.<br>
I use o in ML and I use . in Haskell but in Smalltalk it<br>
just. does. not. fit.  In the relevant respects (no built-in<br>
currying, distinction between named and anonymous functions)<br>
Erlang and Smalltalk are so similar that I'd expect |> to be<br>
just as useless in Erlang as I found it in Smalltalk.<br>
<br>
(When I say |> was useless, I'm being euphemistic.)<br>
<br>
</blockquote></div><br></div>