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

[Fred Hebert]

On 08/16, Jesper Louis Andersen wrote:
>On Sat, Aug 15, 2015 at 4:56 PM, Joe Armstrong <erlang@REDACTED> wrote:
>
>> 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>
>>
>
>val zip : 'a t * 'b t -> ('a * 'b) t option
>val zip_exn : 'a t * 'b t -> ('a * 'b) t
>
>I think it is a good idea. Knowing off-hand if a function has effects 
>is
>always a good thing. And the caller knows immediately when reading the code
>that this may fail in unexpected ways if the invariants are broken.
>

The thing that weirds me out about that approach is that it reminds me a 
lot of hungarian notation.

Whereas scheme or ruby would follow functions with ? (for booleans) or !  
(for destructive updates), Hungarian notation would have you encode the 
return types in other fun ways:

- arru8NumberList : variable is an array of unsigned 8-bit integers 
  ("arru8");
- strName : Variable represents a string ("str") containing the name, 
  but does not specify how that string is implemented.

And then you add:

must_zip : returns the result or fails
may_zip:  returns {ok, Result} or {error, Reason}

both of these look suspiciously like encoding your types in the names 
because the language does not offer enough support (without Dialyzer).

I can't also imagine it a fun time to reimplement everything twice to 
offer changing semantics to please any given user.

- raise exceptions for unforeseen errors that must be the caller or the 
  developer's fault
- return {ok, _} and {error, _} for expected errors that naturally flow 
  from usage and that the user could reasonably be expected to handle.
- encode these in the type system (-spec f() -> {ok, _} | {error, _} | 
  no_return(). , where no_return() points to manually raised exceptions.

That's my take on it anyway.