[erlang-questions] case expression scope
Richard A. O'Keefe
Thu Mar 6 02:02:25 CET 2014
> Le 5 mars 2014 à 21:48, Szoboszlay Dániel <dszoboszlay@REDACTED> a écrit :
>> And once we are there, there are some other nice tricks we could do with scopes. Consider this real life example: https://github.com/rebar/rebar/blob/master/src/rebar_core.erl#L182-L263 - this function performs a lot of sequential tasks and generates a series of Config variables in the meantime (Config1, Config2, ...).
I don't have a problem with multipage functions that have
lots of clauses. I have a serious problem with clauses
that I can't see all at once. These days I have a lovely
big screen so I can get 60 lines on screen at once, which
is also about what I can see on a sheet of paper.
This function is one 82-line clause.
There are a number of little bits that bug me about it.
%% Make sure the CWD is reset properly; processing the dirs may have
%% caused it to change
ok = file:set_cwd(Dir),
occurs twice. That tells me that the code is in the wrong place:
if "processing the dirs may" cause an *unwanted* change to the
current directly, then it *shouldn't*. It would be interesting
to change the design, but the comments don't tell me *where* the
current directory might be changed.
Oddly enough, an issue about changing the current working
directory came up recently in the SWI Prolog mailing list.
The answer was "These days, SWI Prolog is multithreaded,
so after your program starts up, DON'T change the current
The file server's notion of the current working directory
counts as *shared mutable state*, the kind of thing Erlang
is supposed to help us avoid.
Just looking at this function, it is far from obvious that
Dir ever _was_ the current directory. Let us suppose that
it was. Then there is a snag. The pattern
let saved_cwd = getcwd() in $(
can fail. That's why modern UNIX systems have
fd = open(".", O_RONLY);
If I were doing anything in Erlang where I needed to change
"the" current working directory, I'd put the information in
the process dictionary
Now let's return to the issue of variable names and
possible collisions between them. I see a lot of
Config variables, and I haven't a clue what they are,
and I especially haven't a clue how the
execute_* functions are supposed to be updating them.
The documentation for execute/5, for example, says
nothing about the result. What a 'Config' *is* and
how it's processed are core concepts in this file,
but nothing in the file documents them.
When it comes to trying to read the code, _this_ is
a far more serious issue than 'case'; it's even
more serious than the length of the function.
More information about the erlang-questions