I'd also like to know why there are "hidden" features of Erlang in the first place.  I don't understand why they cannot be documented and accepted in the community and if not, just get rid of them.  No one wants to use something that might possibly be removed in the future or unsupported.  Just put it in the language or get rid of it.<div>

<br></div><div>--Andrew<br><br><div class="gmail_quote">On Tue, Jun 26, 2012 at 10:31 AM, Andrew Berman <span dir="ltr"><<a href="mailto:rexxe98@gmail.com" target="_blank">rexxe98@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 too, that would be really nice to get something like that in Erlang.<div class="HOEnZb"><div class="h5"><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><div><br>
On 26 Jun 2012, at 17:18, Anthony Ramine <<a href="mailto:n.oxyde@gmail.com" target="_blank">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" target="_blank">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" target="_blank">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>
</div></div></blockquote></div><br></div>