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

[Tim Watson]

>> 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.
>

Yes you're right, they both read perfectly well to me. I guess I have
become (oddly) accustomed to Erlang not going things this way, which
is deeply ironic given my desire for the feature to appear.

>> 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.
>

I'm going to have to take your word for it. Without type signatures, I
can see why the compiler can't figure out *what* the variable 'Y'
ought to represent, but that it appears in the function body, during
function application (at the call site) seems a bit of a hint. I
suspect the problem here is that you can't tell the difference between
this "toy example" and a typo and other class of programmer error.

>>
>> 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.

Well I'd be supportive of this move, and would be quite willing to get
involved in testing etc.

>
>>
>>> 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.
>

I see what you're saying. True for Haskell/OCaml - I'm thinking of the
lift_n variants and so on, so I guess this is fine. But it will be
rather important that this library of code supporting the functional
bent, makes it's way relatively quickly into the stdlib so that it's
consistently applied and properly supported.

>>> 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.
>

Indeed. Dialyzer and PropEr/QuickCheck are tools I wouldn't want to do without.

>> The compiler knows full well that (<module>)<name>/<arity> evaluates
>> to a fun!?
>
> Only if preceded by 'fun'.
>

Yes that's annoyingly true.