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

[Hugo Mills]

On Sun, Aug 16, 2015 at 09:35:17AM -0400, Fred Hebert wrote:
> 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.

   It is -- but probably not the Hungarian notation you're thinking
of. :)

> 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.

   This is "Systems Hungarian" (the better known and justly reviled
approach), where the fundamental storage types are encoded in the
variable name -- something that automated tooling can deal with much
better than people.

> And then you add:
> 
> must_zip : returns the result or fails
> may_zip:  returns {ok, Result} or {error, Reason}

   This is much closer to "Apps Hungarian", where additional
semantics, beyond the type system, of the return type or function
behaviour are encoded in the name. In this case, the error handling
behaviour is being encoded.

   My favourite example of the "good" Apps Hungarian form is to encode
which variables are unsafe, having come from user input, and which are
safe, having been appropriately sanitised, escaped or validated from
unsafe variables. This isn't something that could be tracked by the
compiler in most languages, but it is vital to the semantics and
correct operation of the software. What's being done here, to my mind,
falls much more into that category.

   You could also look at it as similar to the "throw" annotation in
C++, or the "throws" annotation in Java.

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

   I see it as being useful, but not because the language doesn't
provide the type checking. This is more than basic type checking --
it's additional annotation about the exceptions that could be raised
by a function. You could envisage a -raises() annotation, similar to
-spec(), which gives enough information for an analysis tool to
determine which exceptions might rise to the top of a process and
cause it to terminate. (Actually, I suspect that there's already
enough information in the compiled code to work it out without the
annotations, but I don't have anywhere near the expertise in erlang to
make that claim directly).

   Hugo.

> 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.
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

-- 
Hugo Mills             | Is it true that "last known good" on Windows XP
hugo@REDACTED carfax.org.uk | boots into CP/M?
http://carfax.org.uk/  |
PGP: E2AB1DE4          |                                       Adrian Bridgett
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150816/bd35f49a/attachment.bin>