[erlang-questions] A modest proposal to eliminate tuples
nx
<>
Wed Aug 27 22:43:10 CEST 2014
01110101011100110110010100100000011000100110100101101110011000010111001001111001
On Wed, Aug 27, 2014 at 4:39 PM, Fred Hebert <> 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
>
> http://erlang.org/mailman/listinfo/erlang-questions
More information about the erlang-questions
mailing list