[erlang-questions] Some functions must return values other may do so...

[Vlad Dumitrescu]

On Sun, Aug 16, 2015 at 12:18 PM, Loïc Hoguin <essen@REDACTED> wrote:

> On 08/16/2015 12:06 PM, Vlad Dumitrescu wrote:
>
>>
>> On Sun, Aug 16, 2015 at 12:43 AM, Loïc Hoguin <essen@REDACTED
>> <mailto:essen@REDACTED>> wrote:
>>
>>     On 08/15/2015 04:56 PM, Joe Armstrong wrote:
>>
>>         For a while now I've adopted a convention for naming functions
>>         which I find rather useful, so I thought I'd discuss it here,
>>         (it's a kind of RFC-2119 lite notation :-)
>>
>>         Rule1: Functions which return {ok,X} | {error,W} are called
>>         may_<name>
>>
>>         Rule2: Functions which return a value or raise an exception are
>>         called
>>         must_<name>
>>
>>
>>     The concept is interesting, the implementation is too verbose for
>>     most people to follow it. That, and having a whole API fit under the
>>     letter M is not the best idea for documentation.
>>
>>     Some languages have function names like open_file! or open_file? and
>>     so on, with special meanings attached to them (sometimes just a
>>     convention). We can't do that in Erlang, but something like
>>     'open_file' for Rule1 and 'open_file!' for Rule2 would be pretty
>>     explicit. They would be the equivalent of "Please open the file
>>     thank you very much oh you failed? too bad" and "Open this file! Now!"
>>
>>     The only thing in that spirit that we can do in Erlang today is
>>     something like open_file_ (meh) and open_file@ (not as bad imo).
>>
>>     So using something like open_file@ could be interesting. But
>>     contrary to what I was saying in my email so far, I would suggest
>>     having open_file be the crash-only version (because I believe it
>>     fits Erlang programming best) and open_file@ be the one that returns
>>     errors.
>>
>>     If you follow that, you not only know which function may return
>>     errors, but also you are explicitly requesting errors to be returned
>>     to your code which means a great deal for clarity, without
>>     sacrificing the spirit of "let it crash".
>>
>>
>> Hi!
>>
>> Having a distinction between functions that throw exceptions (hereby
>> named xfuns) and those that return error values (hereby named efuns)
>> makes visible some interesting aspects (I hope I got these right) that
>> make it easier to spot some coding errors:
>>    - efuns must call xfuns wrapped in try/catch
>>    - efuns must call efuns in 'case' or as a return value
>>    - xfuns should call efuns only in 'case'
>>
>
> Not exactly.
>
> The way I see it, what you call "efuns" may still crash. Just it wouldn't
> crash on expected failure (ie a file can't be opened). A valid crash would
> be badarg, for example. Returning {error, badarg} when you pass an integer
> instead of a string is not very useful.
>
> Similarly, "xfuns" can call "efuns" with a plain match, expecting them to
> work and crashing otherwise without having to throw manually.
>
> The only difference between the two is that "xfuns" succeed or crash,
> while "efuns" succeed, return an error for expected failures and crash
> otherwise .
>

Ah, I see, but Joe mentioned using this for dict:fetch and dict:find, so I
assumed it was more general.

In any case, there is more meta-data about functions that would be useful
to have, by declaring it or by inferring it or both: is a function pure?
does it interact with the environment (files, network, user input)? does it
use callbacks (making other meta-data dependent on arbitrary third-party
code)? This meta-data has also two "levels": local and global, where the
global one is the recursive closure over all callees. All this would be
useful, but it gets complicated fast.

best regards,
Vlad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150816/00ff8f21/attachment.htm>