[erlang-questions] Reassigning variables

[Matthew Dempsky]

On Tue, Mar 17, 2009 at 7:02 PM, Richard O'Keefe <ok@REDACTED> wrote:
> Yeek.  Why pervert function call syntax?

Because application expressions are invalid in pattern contexts, so
it's something I could safely define using a parse transform without
having to change the scanner/parser/compiler.

> Why not just have assignments?
>        X = foo(),
>        X := whee(X),
>        X := bar(X),
>        X := xyzzy(X),
>        blah(X)

I'd be generally content with that too.  It just means more intrusive
changes, and the peanut gallery will complain just the same.

> The only real awkwardness in adding this to Erlang is the
> fact that Erlang allows already-bound variables in patterns
> as well as bound ones.

Right, which is one of the benefits of my approach.  Immediately after
posting the first copy of reassign_pt.erl, I generalized it to allow
expressions like "{r(X), Y} = foo(X)".

> As an aside: parse transforms would be more useful if you were
> able to add new operators (like :=).

Agreed.

> What I would really like are some numbers and some examples.
> How *often* is this a problem?
> How *many* times is "the same variable" updated, typically?
> How often are there multiple-updates that don't fall into a
> pattern?
> Is it possible that a different coding style would eliminate
> or greatly reduce the problem?

In our our ad server, this happens a lot in the code that handles the
different third-party ad providers that we integrate.  There's a
(relatively) lot of churn in this code as we add or drop providers,
and every third-party has a different, retarded interface that we have
to deal with.  The code is dumb and hacky, and I'm not especially
proud of it, but it'd be a waste of our time to try to improve it any
more because right now it's only about 80 lines of relatively straight
forward code.  The only trouble in maintaining it is the variable
renaming.

> Please, before writing any parse transforms, show us two or
> three real, complete, functions taken from code you really
> want to use, where this problem occurs.

Too late, I already wrote one. :)