Re: Re: exchanging 2 elements in a list (problem with Block)
- To: mathgroup at smc.vnet.net
- Subject: [mg27783] Re: [mg27631] Re: exchanging 2 elements in a list (problem with Block)
- From: Richard Fateman <fateman at cs.berkeley.edu>
- Date: Fri, 16 Mar 2001 04:37:37 -0500 (EST)
- Organization: computer science division, UC Berkeley
- References: <933FF20B19D8D411A3AB0006295069B0286951@dassne02.darmstadt.dsh.de>
- Sender: owner-wri-mathgroup at wolfram.com
"Wolf, Hartmut" wrote:
>
> Dear Allan,
>
> you'r right, a general problem with, not of, Block. Block indeed does exacly
> what it is supposed to do.
To declare a bug to be a feature is not to eliminate it. Most people
who use Block, do so at the risk of exactly the problem pointed out.
Module was created (also in a hackish way that can be broken if
you use variables like x$$4, I think), to provide a better but
still broken version of programming language scope in Mathematica.
>
> This kind of problems is shared e.g. by all early Lisp dialects having been
> discussed extensively, and being the reason for generally converting to
> lexical scoping.
Early lisps had dynamic scope by default in interpreted code. Dynamic
scope is not, in my view, a bug. In fact, the ANSI standard common
lisp provides facilities for having dynamic scope (defvar, special
variable declarations). This is
not the same as the Mathematica Block bug, which so far as I can tell
has
no use and should be eliminated from the language. If there is a
legitimate
example in which the semantics of Block (rather than the semantics of
Module) make sense, I would be interested in learning it.
> That it is present at all in Mathematica presumably has
> historical reasons.
Um, it was there before Module, certainly. That it is STILL there
I don't know.
> However it also has certain advantages, and I'm happy to
> have it at my disposal.
Can you name one? I can defend it only indirectly, in that Module
is ALSO done wrong, and you have a choice of the bugs/inefficiency in
Module
or the gross bug in Block. If Module were done as in lambda-binding,
in Lisp then I can't think of a reason.
> We have to be wary however, and routinely better use
> Module. So a first thought when seeing a Block might be: "will it work with
> Module?"
Yep. I agree 100%
>
> A method to make Block work with Swap1 (not seriously meant for this case)
> is to restrict evaluation to where it is needed:
>
>
> In[18]:= Clear[s]
> In[19]:= lazySwap[m_,i_,j_] :=
> Evaluate /@ Block[{s = Unevaluated /@ m},
> s[[{i, j}]] = s[[{j, i}]];
> s]
>
> In[20]:= lazySwap[{a, s},1,2]
> Out[20]= {s,a}
>
> Finally a note I would like to add to Richard's problem (after all has been
> said by you and Jens-Peer Kuska, to mention). His pitfall is common to all
> having been absent from Mathematica for a while, and extensively programming
> in C or a similiar language, then misconstruing a definition in Mathemtica
> for a "function procedure". A definition is a term rewrite rule, and there
> is no such thing as a "formal parameter" (with the meaning of a storage
> location behind).
> Pure lambda calculus wouldn't rise the idea, and Mathematica comes closer to
> that than to C.
Unfortunately, the Mathematica book assists in this "thought crime" of
viewing
rules as function definitions.
>
> How to approach call by reference semantics has been shown by Jens-Peer and
> David B. Wagner in his Book "Power Programming with Mathematica, the Kernel"
>
> http://www.amazon.com/exec/obidos/ASIN/007912237X
> devotes all of §4.4 "Parameter-Passing Semantics" (of chapter 4 "Procedural
> Programming") to the theme.
Thanks for the reference.
RJF
>
> With kind regards, yours
> Hartmut
>