[erlang-questions] Process scope variable

[Richard A. O'Keefe]

On 20/02/2015, at 2:04 am, Imants Cekusins <imantc@REDACTED> wrote:

>> So much time spent for removing one State variable from a few function calls.
> 
> much more time will be saved when refactoring from now on.
> 
> imagine:
> most funs will now have signature:
> 
> -spec a(pid()) -> ok.
> 
> and most function bodies will look like:
> check(Pid),
> update(Pid),
> return(Pid).
> 
> it will be a breeze now.

Why?  What I'm seeing here looks like strongly imperative code.
There are presumably dependencies here (e.g., "you must call
check/1 before you call update/1") that are not stated and
cannot be checked.  If you have

-spec check(pid())      -> checked().
-spec update(checked()) -> updated().
-spec return(updated()) -> result().

then there is only one way to hook these steps together that
makes sense, and the Dialyzer can check that
    return(update(check(Pid)))
makes sense and that
    return(check(update(Pid)))
does not.  (Note that the Pid can be part of checked() and updated() types.)

The way I understand it, the thing about doing refactoring at speed
is having tool support, whether it's static verification, good unit
testing, or both, that lets you rapidly check each small step that
it hasn't broken anything.

Having most of your functions with one uninformative specificagtion
seems to me like a recipe for making refactoring error-prone.