4 Answers
4

I don't think one can avoid the need for nested With altogether - I find it a very common case to need declared variables use previously declared variables.

Since I once wrote the function (actually macro) that automates nesting With, and generates nested With at run-time, this is a good opportunity to (re)post it as an answer to an exact question that it actually addresses. I will partly borrow the discussion from this answer.

What it does is to first expand into a nested With, and only then allow the expanded construct to evaluate. It also has a special behavior when used on the r.h.s. of function definitions performed with SetDelayed.

I find this macro interesting for many reasons, in particular because it uses a number of interesting techniques together to achieve its goals (UpValues, Block trick, recursion, Hold-attributes and other tools of evaluation control, some interesting pattern-matching constructs).

Definition-time expansion in function's definitions

When LetL is used to define a function (global rule) via SetDelayed, it expands not at run-time, but at definition-time, having overloaded SetDelayed via UpValues. This is essential to be able to have conditional global rules with variables shared between the body and the condition semantics. For a more detailed discussion of this issue see the linked above answer, here I will just provide an example:

Now, here is why it was important to expand at definition time: had LetL always expanded at run time, and the above two definitions would be considered the same by the system during definition time (variable-binding time), because the conditional form of With (also that of Module and Block) is hard-wired into the system; inside any other head, Condition has no special meaning to the system. The above-mentioned answer shows what happens with a version of Let that expands at run time: the second definition simply replaces the first.

Remarks

I believe that LetL fully implements the semantics of nested With, including conditional rules using With. This is so simply because it always fully expands before execution, as if we wrote those nested With constructs by hand. In this sense, it is closer to true macros, as they are present in e.g. Lisp.

I have used LetL in a lot of my own applications and it never let me down. From my answers on SE, its most notable presence is in this answer, where it is used a lot and those uses illustrate its utility well.

Out of curiosity, why did you call it "LetL" ?
–
QuantumDotJul 26 '14 at 21:14

@QuantumDot The Let part comes from an analogy with Lisp, where there is a similar function. The L stands for Leonid, because originally there was a mathgroup thread with different implementations, and I had to somehow differentiate mine from the others.
–
Leonid ShifrinJul 27 '14 at 10:08

This reminds me of a Q&A I've been meaning to post for years but I never get around to. The basic code behind Where is one of the methods I was using. Maybe I'll finally get around to that soon. (+1 of course.)
–
Mr.Wizard♦Jul 15 '14 at 6:33

With works by performing a substitution operation prior to executing its body, and likely it is only a single pass. So, inter-referencing the variables is not possible. Since With accepts the use of SetDelayed (:=), you might think that that could be used, instead. For example,

With[{v1 = #, v2 := f[v1]}, g[v1, v2]]& @ p
(* g[p, f[v1]] *)

which reveals the other use of With: localization. The v1 in f[v1] is not the same as the v1 used by With, so that method is out, also. The same problem exists for Module as it uses a similar form of localization.

However, Block works

Block[{v1 = #, v2 = f[v1]}, g[v1, v2]]& @ p
(* g[p, f[p]] *)

even though the syntax highlighting makes it appear that the v1 inside f is not localized. But, Block has the attribute HoldAll, so v2 = f[v1] is not executed until v1 has taken on its local definition, and, unlike in With and Module, it is not internally treated with Unique[v1].

With the potential effects of these different attributes on the program unknown, I think I'd better just use Module[{v1, v2}, v2=f[v1]; g[v1, v2]]. Thanks!
–
qazwsxSep 11 '12 at 4:39

4

+1 for some good points. However, my comment here is that Block solves an entirely different problem. With is unique in that it creates referentially-transparent code (no assignments to its "variables" in the body of With is possible), while Block allows the body to arbitrarily modify the variables it localizes. Another big difference: (nested) With can inject into held expressions, something Block or Module can not. So, I don't really view a replacement of (nested) With with Block or Module as a generally valid solution to the posed problem.
–
Leonid ShifrinSep 11 '12 at 12:19

@LeonidShifrin absolutely. With because of its method of operation does things Block cannot do, and vice versa. But, the self-referential part, I thought, was essential to the problem. As long as the other parts of the operation of With are not needed, then Block should be a viable alternative. However, it is not a direct replacement.
–
rcollyerSep 11 '12 at 12:43

@rcollyer Well, as long as the solution removes some defining properties of With, I would not consider it a general solution for With specifically. I would agree with you more (in that self-referential part is the main issue) if this was a question of nested Block or Module.
–
Leonid ShifrinSep 11 '12 at 12:54

@LeonidShifrin except that it is well known that you can do Scope[{x,y}, x = f[y]] with either Module or Block, so I don't think that question would come up. Personally, I think the mutability of the variables in Block is the biggest issue with using as a replacement for With. The ability to use With to inject code into held expressions is less well known. But, for the OPs problem, it was the perfect fit, provided of course the representative example doesn't stray to far from the actual code. :)
–
rcollyerSep 11 '12 at 13:09

Mathematica is a registered trademark of Wolfram Research, Inc. While the mark is used herein with the limited permission of Wolfram Research, Stack Exchange and this site disclaim all affiliation therewith.