global_name_server question.

Craig Dickson crd@REDACTED
Thu Jun 3 20:02:38 CEST 1999

Peter Olin wrote:

> The practice of *returning* {error,}-tuples and {ok,}-tuples instead of
> simply returning the relevant values, or EXITing also makes it impossible
> to have nested function calls.
> For instance: (code not compiled or executed)
> copy1(File1, File2) ->
>     file:write_file("dot_login", file:read_file(".login")).
> is impossible. Instead one has to write:
> copy2(File1, File2) ->
>    {ok, B} = file:read_file(".login"),
>     ok = file:write_file("dot_login", B).
> Not only is this awkward, but also, instead of simply handling the values
> we're interested in we need to match structures and explicitly force our
> code to crash where it would be natural to have that behaviour implicitly.

True. It isn't quite true, though, that nested function calls are
There is another way to write it than your copy2:

copy3(File1, File2) ->
                    begin {ok, B} = file:read_file(".login"), B end).

Whether this is better or worse than copy2 is probably a question of taste.

> "Backwards compatibility" has been the often mentioned reason for keeping
> lot of the inconsistencies in the OTP libraries, but I really don't think
> that's an argument.
> What's the "public opinion" on revising and rewriting interfaces so that
> functions have some consistent use of "types", return values, EXIT
> etc.? There are many ways of keeping the system backwards compatible,
> actively preventing improvements where there is a need for them. (New
> for revised modules, forwarding of calls, compiler warnings, etc)

Sounds good to me. I don't even much care if backward compatibility is
though it's probably a good idea.


More information about the erlang-questions mailing list