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

Tue Jul 12 05:57:08 CEST 2011

On 12/07/2011, at 1:15 PM, Tim Watson wrote:
> 
>> As an occasional Haskell and SML programmer, I am certainly not
>> against Curried functions.  What I *am* against is an approach which
>> is ugly, confusing, and almost never applicable.
>> 
> 
> Can't disagree with you there.
> 
>> If Erlang syntax were generalised to
>> 
>>        ends_with(X)(Y) -> string:equal(string:right(Y, length(X)), X).
>> 
>> we could eliminate those three tokens.
>> 
>> What's more, we could do that *WITHOUT* any weird restrictions on
>>  - whether pattern matching is allowed in the fun
>>  - the form of the fun body
>>  - where the arguments appear in the fun body
>>  - the order in which the arguments appear in the fun body.
>> and *WITHOUT*
>>  - any weird non-intention-revealing tokens, whether '_' or '?'
>> 
> 
> Yes but you have to admit, it does look a bit odd.

Yes, but that is precisely because it looks just like other languages
that do Curried functions.

	ends_with (x) (y) = rtake y (length x) == x

is perfectly good Haskell, assuming an rtake function, and

	fun ends_with (x) (y) =
	        List.drop (y, length y - length x) = x

is perfectly good SML, or would be if it didn't crash when y is
shorter than x.

> Why can't I just
> use the variable 'Y' and let the compiler figure out that the function
> signature needs to change?

Because it is only in toy examples that a compiler *could* figure out
*how* the function signature needs to change.

>> If you want to do Haskell-like things, it doesn't make sense not
>> to do it in a Haskell-like way, and that is to say that
>> 
>>        <name>(<args1>)(<args2>)...(<argsn>) -> <body>
>> 
>> is equivalent to
>> 
>>        <name>(<args1>) ->
>>            fun (<args2>) ->
>>                ...
>>                fun (<argsn>) ->
>>                    <body>
>>                end
>>                ...
>>            end
>> 
>> *NO* new tokens!
>> *NO* weird restrictions!
>> Good consistency with the way Clean and ML and Haskell do it.
>> *NO* changes elsewhere in the language.
>> 
> 
> Great - is it going to get through the eep process? Do we need to vote
> on it, contribute (e.g., test proposed patches, etc) or whatever?

I don't have time to write up an EEP today, but I'll see what I can do.
The nice thing about it is that it's entirely in the front end; the
rest of the compiler doesn't need to know anything about it.

> 
>> Let's see what we have to do now:
>> 
>> c(F1, F2) -> fun (X) -> F2(F1(X)) end.
>> c(F1, F2, F3) -> fun (X) -> F3(F2(F1(X))) end.
>> c(F1, F2, F3, F4) -> fun (X) -> F4(F3(F2(F1(X)))) end.
>> 
>> doodle(X) ->
>>    F = c(fun do_thing/1,
>>          fun calculate_next_thing/1,
>>          fun get_bored_of_typing_result_x,
>>          fun start_getting_annoyed_with_lazy_programmers/1),
>>    {ok, F(X)}.
>> 
>> Nope, not hard.  Trivial, in fact.
> 
> Boilerplate.

No, library code, done *ONCE*.
The only "boilerplate" would be the
-import(compose, [c/4]). % plus any others you want
line.

It would, in fact, have precisely the same status as function
composition in Haskell and SML.  Library code.

>> The question is, in a language without static types, how do you
>> tell the difference between an intentional foo/2 meaning a function
>> and an erroneous foo/2 that should have been Foo/2, with Foo a
>> variable bound to a number.
> 
> We're never going to get static types in Erlang, so I think the answer
> is that you'd end up with a failing unit or integration test case. Not
> sure how to do a "raised eyebrow" smiley.

We *have* optional static types in Erlang, but you're right that they
will probably never be mandatory.

Testing and static checking are complementary tools.
We need both.  Thank goodness we *have* both in Erlang.

> The compiler knows full well that (<module>)<name>/<arity> evaluates
> to a fun!?

Only if preceded by 'fun'.