<div class="gmail_quote">2009/1/21 Bjorn Gustavsson <span dir="ltr"><<a href="mailto:bgustavsson@gmail.com">bgustavsson@gmail.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Wed, Jan 21, 2009 at 4:40 PM, mats cronqvist <<a href="mailto:masse@kreditor.se">masse@kreditor.se</a>> wrote:<br>
> Bjorn Gustavsson <<a href="mailto:bgustavsson@gmail.com">bgustavsson@gmail.com</a>> writes:<br>
><br>
</div><div class="Ih2E3d">>>>  seems i've written this function at least a thousand times;<br>
>>><br>
>>> keyfind(Key,N,List) -><br>
>>>  {value,{Key,Val} = lists:keysearch(Key,N,List),<br>
>>>  Val.<br>
>><br>
>> This version only works for tuples of size 2.<br>
><br>
>  it was meant as an example, not an implementation proposal. i didn't<br>
>  balance the braces either :<<br>
<br>
</div>Yes, but if the tuple has more than two elements, how do you know<br>
which field the caller is interested in? Do you assume that it always<br>
the element after the key? What is the caller is interested in several<br>
fields of the tuple?</blockquote><div><br>I am sorry, but I think that returning something "half-tagged" like ValueTuple | false (/not_found/error/...) is horrendous and should be avoided like the plague. I think the Right Way is to tag both return values as is done with keyserach, but I agree that using {value,Val} | false is bad. If we are going to "fix" it then I would suggest two functions like in dict, find/2 to find a value if it exists and one which assumes it exists and errors otherwise. I also agree that returning 'error' is not the best as it may very well not be an error, with 20/20 hindsight I would prefer a maybe(value) so:<br>
<br>keyfind(Key, N, List) -> {yes,Value} | no.<br>keyfetch(Key, N, List) -> Value (or exception)<br><br>If you want to be more consistent with existing modules like dict then use {ok,Value} | error instead.<br><br>Just because lisp has a convention of returning value or nil, this is not something we should really copy as they also have the convention that (car ()) => () and (cdr ()) => () which are used together with functions returning nil for not found. In erlang terms that would mean hd([]) => [], tl([]) => [] and [] matches [[]].<br>
<br>Now this would help make LFE more lisp-like but I don't advocate it.<br><br>If you are going to tag return values then you must tag them all, otherwise you will be bitten. And the extra cost *is* neglible.<br><br>
Robert<br><br></div></div>