Date: Jun 3, 2013 11:12 PM
Author: lshifr@gmail.com
Subject: Re: Warsaw Univ. course, was Re: Work on Basic


On Tue, Jun 4, 2013 at 12:45 AM, Richard Fateman
<fateman@eecs.berkeley.edu>wrote:

> On 6/3/2013 9:25 AM, Leonid Shifrin wrote:
>
> <long message>
>
> Thanks for what I consider a most agreeable contribution.
> I was not aware of your material on stackexchange, which seems
> to be rather nice.
>


Thanks, I do appreciate your opinion.


>
>
> You are right that my example regarding mutable Lists in Mathematica
> was incorrect. Actually on two grounds. The syntax was not right and
> I did not mean to say that Lists in Mathematica are not mutable, since
> they certainly are.
>
> Just that Lists have the uncomfortable property that if you access one
> element,
> all the others are re-evaluated. Here is an example, which I think is free
> of
> mis-used syntax...
>
> ( q=Table[f[i],{i,1,3}];
> f[n_]:=(Print[n];g[n]))
>
> q[[2]]
>
> evaluates to display
> 1
> 2
> 3
> g[2]
>
> Changing q by, for example, q[[2]]=hello
> does not re-evaluate the elements.
> However, referring to in again as q[[2]] does this:
> 1
> 3
> hello
>



Yes, this is indeed what happens. Arguably this is a correct behavior
(for Mathematica), because Mathematica can not tell in advance that
q will not evaluate to something else. For example, we could have q
assigned to some other symbol, and that symbol to hold the list.

In general, this is because Part does not hold its arguments. Given that
Part works on general expressions, I don't find this inconsistent.
If you don't want this behavior, one way out is to not store the values in
a list, but rather store them in some head which holds their elements,
such as Hold:

In[5]:= q1 = Map[f, Hold @@ Range[3]]

Out[5]= Hold[f[1], f[2], f[3]]

In this case, we get


In[6]:= q1[[2]]

During evaluation of In[6]:= 2

Out[6]= g[2]

Which seems to be the behavior you expected. One could
use HoldComplete in place of Hold, which would arguably
be even better since that would have prevented any non-trivial
evaluation of q1 whasoever (including e.g. search for UpValues,
not prevented by Hold).


Regards,
Leonid




>
> Thanks for pointing out the original error.
> RJF
>
>
>