[erlang-questions] A modest proposal to eliminate tuples

[nx]

01110101011100110110010100100000011000100110100101101110011000010111001001111001

On Wed, Aug 27, 2014 at 4:39 PM, Fred Hebert <mononcqc@REDACTED> wrote:
> On 08/27, Chris Pacejo wrote:
>> Tuples are clearly unnecessary and a wart in Erlang's design.
>> Consider all the operations tuples provide:
>>
>> Construction: X = {A,B,C}
>> Destruction: {A,B,C} = X
>> Pattern matching: case X of {foo,B,C} -> ... end
>>
>> Note now that these operations are provided equally by lists:
>>
>> Construction: X = [A,B,C]
>> Destruction: [A,B,C] = X
>> Pattern matching: case X of [foo,B,C] -> ... end
>>
>
> This proposal lacks foresight. Lists can, for example, be implemented
> using anonymous functions:
>
>   -module(mod).
>   -compile(export_all).
>
>   cons(H, T) -> fun(F) -> F(H, T) end.
>   hd(L) -> L(fun(H,_) -> H end).
>   tl(L) -> L(fun(_,T) -> T end).
>
> Which runs as:
>
>   1> L = mod:cons(3, mod:cons(2, mod:cons(1, []))). %% equiv to [3|[2|[1|[]]]]
>   #Fun<mod.0.125116012>
>   2> mod:hd(L).
>   3
>   3> mod:hd(mod:tl(L)).
>   2
>
> Clearly other operations on lists are only sugar, and should be reduced.
>
> We can also use church numerals for our purposes:
>
>   zero() -> fun(_F) -> fun(X) -> X end end.
>   succ(N) -> fun(F) -> fun(Z) -> F((N(F))(Z)) end end.
>   one() -> succ(zero()).
>   two() -> succ(one()).
>   %% This one is a cheat to help our feeble minds
>   to_int(F) -> (F(fun(X) -> X+1 end))(0).
>
> Which runs as:
>
>   4> mod:to_int(mod:two()).
>   2
>   5> mod:to_int(mod:one()).
>   1
>   6> mod:to_int(mod:succ(mod:succ(mod:two()))).
>   4
>
> Now lambda calculus and other similar works tell us how we can implement
> entire systems that way. All we need are processes. But wait, systems
> like Pi Calculus can be made somewhat equivalent to Erlang, and that one
> is also turing equivalent, isn't it?
>
> Without digressing, I'm sure this mailing list will be able to
> appreciate how having only one data type -- functions -- makes for a
> good base. You now only need to optimize one data type and *the entire
> system* should be faster. It's tempting isn't it?
>
> Hrm.
>
> Regards,
> Fred.
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions