[erlang-questions] Matthew Sackman's "cut" proposal

[Tim Watson]

On 11 July 2011 06:34, Richard O'Keefe <ok@REDACTED> wrote:
>
> Why did Pop-2 need partial application?
> Because it used dynamic scope for variables, so that returning a lambda
> would not have worked.
> Why does Eiffel have agents?
> Because it didn't have lambdas.
>
> Erlang _does_ have working funs so we can do manual Currying on the rare
> occasions when it's needed.
>

For me, the compelling reason to have *something* like this is that
function composition and partial application are the bread and butter
of my programming style, and in Erlang they both prove to be rather,
what shall we say, wordy? For example, consider this function (a
hamcrest matcher) which isn't too bad at all, but is indicative of the
amount of noise we have to deal with:

-spec(ends_with/1 :: (string()) -> fun((string()) -> boolean())).
ends_with(X) ->
    fun(Y) -> string:equal(string:right(Y, length(X)), X) end.

Not personally, I would much sooner have the compiler deal with the
anonymous function machinery for me:

-spec(ends_with/1 :: (string()) -> fun((string()) -> boolean())).
ends_with(X) ->
    string:equal(string:right(?, length(X)), X) end.


Note that I've substituted '_' for ? in order to get away from
discussing the syntax - I could happily go with any marker-character
because to be perfectly honest I don't care that much.It would be even
better if I could express things in point free style, a la Haskell. In
this simple example, typing in the 'fun(...) ->' part isn't too
onerous, but there are plenty of times when it's annoying.

The other point about Mathew's work, is that it provides a means to
eliminate trillions (ahem) of intermediate (state) variables in a
section of code such as:

doodle(X) ->
    Result1 = do_thing(X),
    Result2 = calculate_next_thing(Result1),
    Result3 = get_bored_of_typing_result_x(Result2),
    Result4 = start_getting_annoyed(Result3),
    %% etc, etc, etc
    {ok, Result23}.

Yes I know that "explaining variables" are better than silly and
meaningless naming conventions such as Result_N, but the point is that
I'd like to *inline* this code, but can't easily do so without
readability suffering. Being able to chain/pipeline function calls
would be *really* nice, so I could rewrite this in a neater style:

Fun = quite_happy/1 + not_so_bored/1 + calculate_next_thing/1 + do_thing/1, ...

I can't understand why the parser requires me to type "fun M:F/A" when
the "/" character clearly indicates that I'm referencing a function in
a special way. And if the compiler can recognise a reference to a
function (local or otherwise), then why not have it recognise "+" as
an operator for chaining function calls?

Anyways - I think this work is interesting and hope that it sparks a
good conversation about how we can potentially improve support for
function composition and (potentially) partial application in Erlang.