<html><head></head><body>I'm surprised nobody mentioned erlando: <a href="https://github.com/rabbitmq/erlando">https://github.com/rabbitmq/erlando</a><br>
-- <br>
Best wishes,<br>
Dmitry Belyaev<br><br><div class="gmail_quote">On 10 July 2015 3:44:55 AM AEST, Fred Hebert <mononcqc@ferd.ca> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">On 07/09, José Valim wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">I agree with the general feelings of the thread. F# relies on currying.<br />Elixir relies on macros (it is actually closer to the thread operator found<br />in some lisps).<br /><br />Also F# has most of its standard library expecting the "subject" as last<br />argument (due to currying). Elixir defaults to the first argument. Erlang,<br />for better or worse, has them mixed (see binary and lists modules).</blockquote><br /><br />I agree with this. The only workable form I could imagine could go <br />something like this with macros, without major changes to the language:<br /><br />pipe(Init, a(_, X), b(Y, _), c(_, _, 41.12)), where '_' gets replaced by <br />the threaded in 'Init' state. The obvious problem is lack of <br />composition:<br /><br />pipe(Init, pipe(Init2, a(_))) where you can't know if a(_)
refers to <br />Init or Init2 at a glance without knowing precise evaluation rules.<br /><br />Generally I haven't felt I missed this feature too much in Erlang. In <br />the cases where it could really be nice, I resorted to using:<br /><br /> pipe(Init, Funs) -><br /> lists:foldl(fun(F, State) -> F(State) end, Init, Funs).<br /><br /> pipe(Init,<br /> [fun(S) -> set(S, 230) end,<br /> fun(S) -> update(S) end,<br /> fun(S) -> output(S), S end]).<br /><br />Obviously, one could easily come and swoop in with a macro:<br /><br /> pipe(Init, $$, % $$ is replaced by 'Init'<br /> set($$, 230),<br /> update($$),<br /> fun() -> output($$), $$ end)<br /><br />The problem is that composition is not obvious:<br /><br /> pipe(Init, $$,<br /> pipe($$, $_,<br /> set($_, 230),<br /> update($_),<br /> fun() -> output($$), $_ end))<br /><br />In that
case, the last 'output($$)' would try to print the literal '$$' <br />value instead of the substituted one given underneath it all, it's <br />equivalent to:<br /><br /> pipe(Init, [fun(S) -> pipe(S, [...]) end]).<br /><br />Woops! But what's cool? Add in a maybe pipe!<br /><br /> maybe_pipe(Init, Funs) -><br /> %% use throws and catches if you wanna go faster<br /> lists:foldl(fun(F, {ok, State}) -> F(State)<br /> ; (F, {error, Err}) -> {error, Err} end,<br /> Init,<br /> Funs).<br /><br />And with the same set of parse transforms you can change:<br /><br /> f(X0) -><br /> case g(X0) of<br /> {ok, X1} -><br /> case h(X1) of<br /> {ok, X2} -> {ok, X2};<br /> Err = {error, _} -> Err<br /> end;<br /> Err = {error, _} -><br /> Err<br /> end.<br /><br />Into:<br
/><br /> f(X0) -><br /> maybe_pipe(X0, $$, g($$), h($$)).<br /><br />Which translates to:<br /><br /> f(X0) -><br /> maybe_pipe(X0,<br /> [fun(X) -> g(X) end,<br /> fun(X) -> h(X) end]).<br /><br />And all of this is doable today in library code for or from anyone, <br />doesn't fundamentally change the shape of Erlang, although it will <br />definitely be more confusing for newcomers or people not familiar with <br />the concept.<br /><br />All it needs is someone angry enough to do it. I don't believe (from <br />doing experiments like Hubble[1]) that it's particularly hard.<br /><br />Regards,<br />Fred.<br /><br />[1]: <a href="https://github.com/ferd/hubble">https://github.com/ferd/hubble</a><br /><br /><hr /><br />erlang-questions mailing list<br />erlang-questions@erlang.org<br /><a href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a><br
/></pre></blockquote></div></body></html>