I agree too, that would be really nice to get something like that in Erlang.<br><br><div class="gmail_quote">On Tue, Jun 26, 2012 at 10:26 AM, Tim Watson <span dir="ltr"><<a href="mailto:watson.timothy@gmail.com" target="_blank">watson.timothy@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I agree that something like functors would be a really nice abstraction for erlang.<br>
<div class="HOEnZb"><div class="h5"><br>
On 26 Jun 2012, at 17:18, Anthony Ramine <<a href="mailto:n.oxyde@gmail.com">n.oxyde@gmail.com</a>> wrote:<br>
<br>
> Le 26 juin 2012 à 16:56, Joe Armstrong a écrit :<br>
><br>
>> I like this mechanism.  This way of hiding additional data is very flexible.<br>
>><br>
>> I've used this in several programs, and the resulting code is easy to<br>
>> understand. This nice thing is that using this you can make very nice<br>
>> client APIs. For example, for string processing you might say<br>
>><br>
>>            Str = {ansi_string, "abc"},         or<br>
>>            Str = {utf8_string, "u+1234"}<br>
>><br>
>> And then when you call<br>
>><br>
>>            Str:substr(1,4)<br>
>><br>
>> Get the correct behaviour depending upon the underlying string type ie<br>
>> either ansi_string:substr(1,4,{ansi_string,"abc"}) or<br>
>> utf8_sting:substr(1,4,{utf8_string, "u+1234"} ) will be called<br>
>><br>
>> If you write a program where strings might be in latin1, or utf8 or<br>
>> something else you'd still<br>
>> have to tag the string (as in say {latin1, "abc"}) so you knew what<br>
>> the encoding was and still<br>
>> have to call different modules depending upon the tag. This is what<br>
>> the above mechanism does<br>
>> so it's very nice for hiding the mess in polymorphic interfaces.<br>
>><br>
>> /Joe<br>
><br>
> I think it is quite ugly to have terms as module parameters; a more beautiful way in my opinion would be to have something like Caml functors, which are mappings from structures (modules in Erlang) to structures.<br>


><br>
> You would have a string functor which takes as a parameter a string implementation module, either ansi_string or utf8_string. You could then abstract the common stuff from ansi_ and utf8_ in string.<br>
><br>
> Regards,<br>
><br>
> --<br>
> Anthony Ramine<br>
> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br>