Parameter passing "feature"
- To: mathgroup at yoda.ncsa.uiuc.edu
- Subject: Parameter passing "feature"
- From: macg at SLCS.SLB.COM (Bill Macgregor)
- Date: Mon, 15 Oct 90 11:18:57 CDT
[in reply to a previous message from David Jacobson. -smc]
David -
I don't think this problem is restricted to the case where
the function is HoldFirst or HoldAll--I think it's a general problem.
In fact, when I showed this problem around the office, the Lisp people
said "Mathematica has the funarg problem; tell them to get with the
times." This is a hoary problem for the Lisp community.
The problem, as I understand it, is that Block variables aren't
really new symbols; they're the dynamically enclosing variable with the
values push'd at block entry and pop'd at exit. This is an invitation
to disaster in cases like -
f[x_] := Block[{y}, y = 2 x]
where f[y] produces an infinite loop. In fact, to be completely safe,
you must insure that function block variables used as lhs's of Set are
distinct from all symbols in their corresponding rhs's, which may involve
the function arguments in arbitrary ways. At first glance this is a
major violation of information hiding--the function's callers must avoid
using the function's local variables in actual arguments!
The Mma book claims that this behavior is sometimes desirable (don't
think I believe it). It further states (correctly) that the problem is
made less severe when f is defined in a package, and is therefore defined
context different from the one in which it normally used.
For example, if f is defined in package FPackage, but called from
context Global on Global`y, the effect is
f[Global`y] -> Block[{FPackage`y}, FPackage`y = 2 Global`y]
and everything is OK because the two y's are really different symbols.
Name substitution still seems, to me at least, to be a serious design
mistake in this case. It's too dangerous. Lisp abandoned it. Forcing
all Block variables to be truly unique symbols would seem a much better
choice.
- Bill MacGregor