[erlang-questions] Reassigning variables

[Matthew Dempsky]

On Thu, Mar 19, 2009 at 8:33 PM, Richard O'Keefe <ok@REDACTED> wrote:
> So far we have one concrete example where reassignment would
> be useful, plus several allegations that this is not unusual.

In a previous email I listed several concrete examples of code from
different OTP applications where I thought reassignment could be
useful.

>      But there is a heavy cost:  if this is mixed with
>      much other code and you want to see where "St" came
>      from you cannot easily find "it", because "it" is
>      really "them".

In Emacs, if I want to see where a variable is bound, I do a reverse
search for the variable name.  Generally, I go back to the first place
where it's used in a pattern.  With reassignment, I just have to
short-circuit this search when I find a pattern that reassigned it.
It doesn't seem that much more difficult to me to cope with variable
reassignment.

>      It takes _more_ keyboard activity to type (2) than (1).
>      StX...StY becomes St...r(St) for an extra character per update.

Yes, but it still takes far less typing than most of the other
convoluted ideas that have been suggested in this thread.

(David Reid, inspired by the suggestions of BASIC-style numbering,
humorously suggested another solution: instead of trying to maintain
any notion of ordering in the numbers, just use a UUID for each
variable instance.  E.g.,
{Head,St_64D2F1A2_AE6B_425B_BD2F_A466350CF548} =
new_var(St_50C531DB_E503_4ACC_83BB_A2CABF531399).)

>      It also hurts that something that looks like a function call
>      isn't one.  A different syntax, maybe "*St", could fix both of
>      those issues.

"+St" or "-St" would be possible right now using a parse transform
since + and - are unary operators that are illegal within a pattern.
(I can see a disadvantage to using these, however, that someone might
first expect "-X = 3" to bind X to -3.)

However, I don't feel like r() is an overly cumbersome syntax for
this.  I'm inclined to stay away from adding too many weird special
operators, and I chose r() based on the shell's existing forget syntax
f().

>      However, (2) and (1) both share the same fundamental problem,
>      so that I have to regard (2) as not really being usefully
>      different.  The state threading is still explicit.  And just
>      as it is possible to mistakenly re-use a numbered version of
>      a state variable, {...,St5} = p(...,St5), so it is possible
>      to mistakenly omit the "reassign" marker {...,St} = p(...,St)
>      when {...,r(St)} or {...,*St} or whatever syntax was meant.

I agree that being able to automatically thread St would be preferable
over having to remember to reassign St, but in lieu of a *usable* way
to do that, I still think variable reassignment is better than
manually numbered variables.

> (3)  -changer(core, [f/..,g/..,h/..,u/..]).
>
>      f(....) ->
>         ... = g(....),
>         ... = h(....),
>         ... = u(....),
>         ...
>
>     For each -changer(T) declaration a function is subject to,
>     it gets an extra argument, and if there is at least one,
>     the changer results are tupled with the original result.
>     The threading is now the responsibility of the translator,
>     not of the programmer.  It is now *impossible* for the
>     programmer to get the threading wrong.

I can somewhat imagine how this would work, but if you're able to
write a basic example and the equivalent Erlang code to compare with,
it would help.

> So (2) eliminated the *numbers* but left everything else there,
> (3) eliminated the *appearence* of the state but it still existed,
> while (4) is to eliminate the state *entirely* from the main
> functions by putting "variable-binding" operations in the data
> structure that's being built.

I'm going to avoid commenting on (4) for now.  (2) was satisfactorily
achievable using a parse transform written in about half an hour.  I
can appreciate that (3) might be an improvement, and it still feels
feasible with a parse transform of reasonable complexity.  However,
(4) feels far more intrusive and beyond the scope of just solving a
(minor) annoyance that has been bugging me for a while, and I don't
have the time to really consider it right now.