<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">There seems to be a lot of confusion going on here between *interface* (API) and *dispatch* (redirecting the API calls to the actual implementation depending on the data structure). I have only suggested a unified API; not a generic dispatch mechanism.</div>

</div></blockquote><div><br></div><div>If the main purpose is an unified API, agreed. Thanks for clearing it up.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


"Tuple modules" (please call them Parameterized modules or Abstract modules - the implementation-as-tuples is a temporary hack, and you should treat them as opaque objects just like funs).<br></blockquote><div>

<br></div><div>I thought it was the opposite. Parameterized modules were the temporary hack and the implementation-as-tuples/"tuple modules" were here to stay.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


That said, I think Clojure's protocols (which are a way of dynamically getting the same effect that you get with Haskell's type classes) are a neat idea that would probably work well with Erlang. But that's a different story.</blockquote>

<div><br></div><div>Agreed as well. Regardless, protocols should be possible to implement in Erlang via parse transforms. I have implemented it for a language of top of the Erlang VM I am working on, but it is not officially released yet. Hoping to talk more about it on Erlang Factory Lite in Kraków this march.</div>

</div>