[erlang-questions] Elixir Protocols in Erlang & a Strange Warning

Bob Ippolito <>
Fri Dec 13 19:47:30 CET 2013


What you have implemented *is not protocols*, so the details of your
implementation of "non-extensible protocols" are irrelevant. I certainly
have not said that it is not possible in Erlang, because it *obviously* is
possible to have protocols given that Elixir does it with the same runtime.
What I have said is that it's not idiomatic to do such things, so you
should probably try and solve your problems in a different way, with more
concrete implementations (such as explicit passing of funs or {Module,
State} tuples).

As Fred said, there's a simple mechanical transformation from tuple funs
(what you have called "stateful modules") to standard Erlang code. Fred's
translation is slightly off though, for some reason the module name is
included in the argument tuple.

%% Using tuple calls (*strongly* discouraged)
f(M, Arg) -> M:call(Arg).

%% Without tuple calls
f({M, State}, Arg) -> M:call(Arg, {M, State}).

I am suggesting that what you have proposed is bad practice. There are
other ways to implement exactly what you have shown with only a little bit
more syntax.

See http://www.erlang.org/doc/efficiency_guide/functions.html for official
documentation on tuple funs. In summary: they exist and are supported by
the runtime for compatibility reasons, but their implementation is slow and
their use is strongly discouraged.

-bob



On Fri, Dec 13, 2013 at 10:19 AM, Kaveh Shahbazian <
> wrote:

> "The trouble with implementing this in Erlang is that in order to do it
> you need to have some mutable data structure in the runtime that changes
> based on which modules are loaded";
>
> From this I assume you say this is not possible in Erlang but *this thing
> already works in Erlang* and does not mutate anything. So it is already
> implemented in Erlang.
>
> Now are you suggesting this is a bad practice? And should be avoided?
>
> Kaveh Shahbazian
> “Walking on water and developing software from a specification are easy if
> both are frozen.”
> ― Edward Berard
> <http://goo.gl/ZZ2TMu>
>  <http://stackoverflow.com/users/54467/kaveh-shahbazian>
>
>
> On Fri, Dec 13, 2013 at 9:36 PM, Bob Ippolito <> wrote:
>
>> I think you're a bit confused here, because your implementation of
>> ?protocolX(…) doesn't work like Elixir protocols. The trouble with
>> implementing this in Erlang is that in order to do it you need to have some
>> mutable data structure in the runtime that changes based on which modules
>> are loaded, since any module can define an implementation for some
>> protocol. Elixir's defprotocol just creates a new module for the given
>> protocol (e.g. 'Elixir.Enum'), and defimpl creates a separate module for
>> each implementation of a protocol (e.g. 'Elixir.Enum.List').
>>
>> Erlang simply does not have any built-in support for the kind of dispatch
>> you're looking for. Parameterized modules were similar to what you are
>> proposing (but not like Elixir's protocols!), but they have been
>> deprecated. If you really feel the need to write very generic code, maybe
>> Erlang is not the language for you. Erlang works best when you can do
>> everything with concrete implementations. Elixir would likely fit more
>> abstract use cases better, but note that there is some runtime performance
>> cost for this indirection.
>>
>> Haskell's type classes are also quite interesting too, as the import of a
>> type class instance doesn't propagate beyond the compilation unit so you
>> don't have as much of a namespace issue. The compiler can also get rid of
>> the indirection in most cases so there's not necessarily any cost for using
>> abstractions in that universe.
>>
>> In any case, I can't think of a way to reasonably implement this in
>> Erlang using idioms that mesh well with the rest of Erlang. There is no OTP
>> standard for this kind of thing, and there isn't likely to be a good way to
>> do it any time soon. If there was an OTP "interface" standard, surely we'd
>> have a hook to customize what "~p" means to io_lib for our own types! But
>> alas, we can't really even define our own abstract data types in Erlang,
>> just type aliases over the built-in concrete types.
>>
>> -bob
>>
>>
>>
>> On Fri, Dec 13, 2013 at 8:56 AM, Kaveh Shahbazian <
>> > wrote:
>>
>>> First "stringer" was a sample for (turned out it was a bad one)
>>> simulating protocols. So one could write (it can be more complicated, but
>>> whatever):
>>>
>>> test(V) ->
>>>     X = ?protocolX(V),
>>>     X:act1(),
>>>     X:act2(),
>>>     % ...
>>>     X:actN(SomeArguments),
>>>     OtherThings().
>>>
>>> And act1 .. actN are members of 'protocolX'. This way it's clear that
>>> 'V' is behaving as a 'X' (much like interfaces in C#; am I too corrupted?).
>>>
>>> BTW since I am no Erlang guru, I will follow the rules (for
>>> a foreseeable future) as you say here.
>>>
>>> Kaveh Shahbazian
>>>  “Walking on water and developing software from a specification are easy
>>> if both are frozen.”
>>> ― Edward Berard
>>> <http://goo.gl/ZZ2TMu>
>>>  <http://stackoverflow.com/users/54467/kaveh-shahbazian>
>>>
>>>
>>> On Fri, Dec 13, 2013 at 5:32 PM, Fred Hebert <> wrote:
>>>
>>>> Hi.
>>>>
>>>> Despite what Joe says in his book, the history of the feature is that
>>>> tuple calls, the form you're using, were kept to allow the deprecation
>>>> of parametrized modules.
>>>>
>>>> In my humble opinion, the 'stateful module' things you're trying to
>>>> accomplish for you stringification is non-intuitive and not erlangish (I
>>>> would be confused by reading that in a code base). May I suggest the
>>>> simpler form, without changing your module:
>>>>
>>>>     stringer:to_string(MyValue)
>>>>
>>>> instead? You will notice it even saves two characters when being called
>>>> over:
>>>>
>>>>     ?stringer(MyValue):to_string().
>>>>
>>>> Without including the macro definition work required, and is more
>>>> idiomatic overall. To use it as a function, simply use
>>>>
>>>>     F = fun stringer:to_string/1,
>>>>     F(MyValue).
>>>>
>>>> Regards,
>>>> Fred.
>>>>
>>>> On 12/13, Kaveh Shahbazian wrote:
>>>> > I do not thing so. Parametrized modules are different than stateful
>>>> > modules. Parametrized modules are deprecated and they were always
>>>> > provisional.
>>>> >
>>>> > Joe Armstrong in Programming Erlang (2nd Edition, Page 418) talked
>>>> about
>>>> > them and in this same book he was promoting "coming soon" features of
>>>> R17
>>>> > and It's highly unlikely for them to be deprecated.
>>>> >
>>>> > Kaveh Shahbazian
>>>> > “Walking on water and developing software from a specification are
>>>> easy if
>>>> > both are frozen.”
>>>> > ― Edward Berard
>>>> > <http://goo.gl/ZZ2TMu>
>>>> > <http://stackoverflow.com/users/54467/kaveh-shahbazian>
>>>> >
>>>> >
>>>> > On Fri, Dec 13, 2013 at 11:40 AM, Dmitry Kolesnikov
>>>> > <>wrote:
>>>> >
>>>> > > Hello,
>>>> > >
>>>> > > Essentially you are trying to use parametrized modules, which get
>>>> > > deprecated in R14/15 and dropped from R16.
>>>> > > See for details:
>>>> > >  * http://www.erlang.org/news/35
>>>> > >  * http://www.erlang.se/workshop/2003/paper/p29-carlsson.pdf
>>>> > >
>>>> > > This type of problems are solvable either via pattern match or
>>>> currying:
>>>> > >
>>>> > > -module(stringer).
>>>> > > -export([stringer/1,sample/0]).
>>>> > >
>>>> > > stringer(V) when is_list(V) ->
>>>> > >     fun() -> to_string(V, nop) end;
>>>> > > stringer(V) when is_atom(V) ->
>>>> > >     fun() -> to_string(V, nop) end;
>>>> > > stringer(_V) ->
>>>> > >     fun() -> not_implemented end.
>>>> > >
>>>> > > to_string(V, _Nop) ->
>>>> > >     Buffer = io_lib:format("~p",[V]),
>>>> > >     lists:flatten(Buffer).
>>>> > >
>>>> > > sample() ->
>>>> > >     io:format("~p~n", [(stringer([1,2]))()]),
>>>> > >     io:format("~p~n", [(stringer(cute_atom))()]),
>>>> > >     io:format("~p~n", [(stringer(13))()]).
>>>> > >
>>>> > >
>>>> > > Best Regards,
>>>> > > Dmitry
>>>> > >
>>>> > > On Dec 13, 2013, at 8:31 AM, Kaveh Shahbazian <
>>>> >
>>>> > > wrote:
>>>> > >
>>>> > > I wanted to write something like ((IStringer)object).ToString() (in
>>>> C#)
>>>> > > in Erlang. After some studying I've learnt that Elixir has
>>>> something called
>>>> > > Protocols that pretty much resembles the same thing of C# (in an
>>>> inside-out
>>>> > > manner). Then I came up with this idea/code in Erlang - which is
>>>> nice
>>>> > > enough to me like:
>>>> > >
>>>> > > ?stringer(my_val):to_string().
>>>> > >
>>>> > > And it either returns the expected value or not_implemented atom!
>>>> > >
>>>> > > But 2 questions:
>>>> > >
>>>> > > 1 - Why nobody use this or promote things based on stateful modules
>>>> in
>>>> > > Erlang? (OTP aside and from talking to some Erlangers they did not
>>>> know
>>>> > > that actually OTP is built around this! So really there is a need
>>>> to change
>>>> > > how Erlang is being taught and promoted. It's possible that I am
>>>> confused.).
>>>> > >
>>>> > > 2 - Why I get this warning? That call actually never fails.
>>>> > >
>>>> > > The warning:
>>>> > >
>>>> > > stringer.erl:18: Warning: invalid module and/or function name; this
>>>> call will always fail
>>>> > > stringer.erl:19: Warning: invalid module and/or function name; this
>>>> call will always fail
>>>> > > stringer.erl:20: Warning: invalid module and/or function name; this
>>>> call will always fail
>>>> > >
>>>> > > The code:
>>>> > >
>>>> > > -module(stringer).
>>>> > > -export([to_string/1,sample/0]).
>>>> > >
>>>> > > -define(stringer(V), {stringer, V}).
>>>> > >
>>>> > > to_string({stringer, V}) when is_list(V) ->
>>>> > >     to_string(V, nop);
>>>> > > to_string({stringer, V}) when is_atom(V) ->
>>>> > >     to_string(V, nop);
>>>> > > to_string({stringer, _V}) ->
>>>> > >     not_implemented.
>>>> > >
>>>> > > to_string(V, _Nop) ->
>>>> > >     Buffer = io_lib:format("~p",[V]),
>>>> > >     lists:flatten(Buffer).
>>>> > >
>>>> > > sample() ->
>>>> > >     io:format("~p~n", [?stringer([1,2]):to_string()]),
>>>> > >     io:format("~p~n", [?stringer(cute_atom):to_string()]),
>>>> > >     io:format("~p~n", [?stringer(13):to_string()]).
>>>> > >
>>>> > > And the output is:
>>>> > >
>>>> > > "[1,2]"
>>>> > > "cute_atom"
>>>> > > not_implemented
>>>> > >
>>>> > >  _______________________________________________
>>>> > > erlang-questions mailing list
>>>> > > 
>>>> > > http://erlang.org/mailman/listinfo/erlang-questions
>>>> > >
>>>> > >
>>>> > >
>>>>
>>>> > _______________________________________________
>>>> > erlang-questions mailing list
>>>> > 
>>>> > http://erlang.org/mailman/listinfo/erlang-questions
>>>>
>>>>
>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> 
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20131213/aa46d6fa/attachment.html>


More information about the erlang-questions mailing list