[erlang-questions] Elixir Protocols in Erlang & a Strange Warning
Kaveh Shahbazian
kaveh.shahbazian@REDACTED
Fri Dec 13 19:19:29 CET 2013
"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 <bob@REDACTED> 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 <
> kaveh.shahbazian@REDACTED> 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 <mononcqc@REDACTED> 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
>>> > <dmkolesnikov@REDACTED>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 <
>>> kaveh.shahbazian@REDACTED>
>>> > > 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
>>> > > erlang-questions@REDACTED
>>> > > http://erlang.org/mailman/listinfo/erlang-questions
>>> > >
>>> > >
>>> > >
>>>
>>> > _______________________________________________
>>> > erlang-questions mailing list
>>> > erlang-questions@REDACTED
>>> > http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20131213/f11e180b/attachment.htm>
More information about the erlang-questions
mailing list