[erlang-questions] Reassigning variables

[Richard O'Keefe]

On 18 Mar 2009, at 3:40 pm, Matthew Dempsky wrote:

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

"Safely" solely in the sense that one particular tool-set would
let you do it.  But not in the sense that the resulting syntax
would win any prizes for readability.
>
>
> I'd be generally content with that too.  It just means more intrusive
> changes, and the peanut gallery will complain just the same.

Fairly trivial ones.
>
>
>> 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)".

So use a macro:
	-define(let(Lhs,Exp,Body),
	    (fun (Lhs) -> Body end)(Exp)).

	X = foo(),
	?let(X, bar(X), (
	?let(X, ugh(X), (
	ack(X)))

This exploits what is otherwise a nuisance, namely that
the scope rules for 'fun' are inconsistent.  (An outer
variable that appears in the body of a fun is an old
variable, but an outer variable that appears in the head
is a new variable.)
>
>> 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.

Numbers?

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

This sounds like a textbook case for metaprogramming.

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

Can we see this?

Bending the language for the sake of "about 80 lines of relatively
straight forward code"?

This does really sound like a case for metaprogramming.