<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: times new roman,new york,times,serif; font-size: 12pt; color: #000000'><br><br><hr id="zwchr"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"José Valim" <jose.valim@plataformatec.com.br><br><br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I can understand 1), but what's the point of 2)? Wouldn't it be better for that to be in the erlang/otp repository instead so that everything can benefit from it?</blockquote>
<div><br></div><div>Loic, whenever it makes sense, I contribute patches back to OTP. :)</div><div><br></div><div id="DWT3999">I would, for example, contribute our dict implementation, but I don't believe OTP is looking for another dict implementation (I am going to write a blog post with details and benchmarks soon for those interested).</div></div></blockquote><br>If you have a better/faster implementation of dict with the same API then you should definitely contribute it. The original idea behind having multiple dict (and sets) libraries was to allow the user to choose the one that was best for their application. The internals of dict were deliberately unspecified to allow the implementation to change in the future. By having other versions of dict with different properties but the same API then users could choose. NO, I don't like having an option to new() to say which one you want as then you automatically limit the options, having different modules makes it easy to add new ones and to write your own! So hand it in and may the fastest win.<br><br><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div class="gmail_quote"><div></div>
<div><br></div><div id="DWT4000">Some of the stuff in our stdlib, like providing zero-index based access everywhere is hard to "backport" to Erlang. And other stuff like the Enum module, which is a bunch of functions meant to work on any enumerable data structure, like lists, dicts, etc, requires protocols.</div></div></blockquote><br>What is it with zero-based indexes that make people so morbidly fascinated by them. If you are talking *offsets* then I agree that zero-based is fine, it's saying how far away something is from a some point. But here we are talking *indexes*, you know like first, second, third, etc. No indexes start at one! And don' go on about how C does it because C doesn't have arrays and indexes it has pointers and offsets, foo[3] is just syntactic sugar for *foo+3. And don't go on about how much easier it is to count from zero, I don't buy that, we can all add and subtract one without problems. Or at least I hope so.<br><br>I think the OTP group made a bad decision *indexing* binaries from zero instead of one like the rest of erlang. It is both wrong and makes the system inconsistent.<br><br>So to go on about this but there are some sensible things you can criticize Erlang for and indexing from one is not one of them. (And not really the syntax either, and this comes from the creator of LFE)<br><br>Robert<br><br></div></body></html>