[erlang-questions] Parameterized module idioms

[Richard O'Keefe]

On Apr 21, 2010, at 7:04 AM, Vlad Dumitrescu wrote:

> On Tue, Apr 20, 2010 at 17:15, Mazen Harake
> <mazen.harake@REDACTED> wrote:
>> If you create a new "instance" of a module with a parameter, then  
>> you need
>> to have that "instance variable" around to call it right? So you  
>> need to
>> keep it somewhere... as a state.
>>
>> So in any case you need to keep a state, in other words you haven't  
>> achieved
>> anything (except perhaps making your code more obfuscated).
>>
>> So _why_ is it ["of course"] "easier to use module parameters  
>> instead of
>> passing closures or state around"?
>
> Hi,
>
> If you send state around the functional way, it has to be a parameter
> to all the functions that use some part of that state. If the state
> data changes, it may be needed to update all these places (if the
> state representation wasn't flexible enough).
>
> If the state is globally accessible, you just use the appropriate
> variable where it is needed.

The "it has to be a parameter ..." part is true of Erlang right
now, not a truth about "the functional way" in general.

"if the state representation wasn't flexible enough" applies with
equal, if not greater, force to module parameters:  if we used to
have a parameter Foo and now find that it needs to be split into
Foo proper and Fooly, we still should _review_ each occurrence of
Foo to see what to do about it.

Actually, what we're discussing here is not STATE (which changes)
but CONTEXT (which doesn't).  Module parameters do not support state.
Other functional languages usually handle this with nested functions,
not with module parameters.