MathGroup Archive 2008

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: What does FullForm[ ] actually do?

  • To: mathgroup at smc.vnet.net
  • Subject: [mg90546] Re: What does FullForm[ ] actually do?
  • From: AES <siegman at stanford.edu>
  • Date: Sat, 12 Jul 2008 05:33:50 -0400 (EDT)
  • Organization: Stanford University
  • References: <g54oj0$eu9$1@smc.vnet.net> <g56t9n$3qv$1@smc.vnet.net>

In article <g56t9n$3qv$1 at smc.vnet.net>,
 Jean-Marc Gulliet <jeanmarc.gulliet at gmail.com> wrote:

> The documentation for FullForm reads, "FullForm acts as a 'wrapper', 
> which affects display, but *not* evaluation." [1]
> 
> The key point is, "[...] affects display, but *not* evaluation."
> 
> In other words, the standard evaluation process *occurs* as usual -- as 
> if FullForm was not there -- since FullForm has no specific attributes 
> that tell it not to do so (HoldFirst, HoldRest, etc.). (Note that you 
> can see the attributes attached to a symbol thanks to Attributes[].)


Thank you -- agreed --  that's what I've now learned from you and others 
is how FF operates:  To say this (I think) more precisely: 

   "FullForm[expr] **first evaluates the expression expr** 
    and then displays **the internal form of the _result_ 
    produced by this evaluation of the expression**.
 
But what I suggest ought to be of considerable concern to WRI, and to M 
users, is the number of occasions where the documentation has the 
opportunity to make this point in clear and unambiguous terms and, as in 
so many other places in M's documentation, totally fails to do so.

The quote in your first sentence up above is, for me anyway, far from 
precise or definite on this point; as phrased, it can be read in 
multiple ways.

The opening definition in that same function definition for FullForm[] 
misses the same opportunity to be clear and unambiguous.

Further down on the same page the discussion does indeed apply FF first 
to an expr and then to the evaluated result of expr, and finds that they 
are the same.  But is that because FF *always* evaluates? -- or is this 
more to demonstrate how FF can in fact be applied either before or after 
evaluation, if you want or need to do that -- and in this particular 
case they turn out to be the same.

I also count four places in the discussion of FullForm on p. 234 of the 
M5 Book where the phrasing could have included the terms "evaluate" or 
"evaluated", but never does.

In fact it twice uses the concept "internal form" instead, which tends 
to, as the lawyers say, lead the reader away from any idea of evaluated 
expression, and leave at least some implication that the expression is 
stored in some internal form **even before evaluation**.

Look at pp. 279 and 424 in the M5 book:  the focus is very much on the 
*representation*, not *evaluation*.

Is there *anywhere* in the M documentation where they give a example 
such as, just for example, FullForm[4+5]-->9 with maybe an added comment 
that "FullForm[] evaluates its argument and displays the result"?

Any argument that FullForm[expr] must evaluate expr because most (or at 
least some) other symbols having an argument [expr] do evaluate that 
argument is a very weak one.  

First of all, not all symbols of the form Symbol[expr] in fact evaluate 
expr, at least not immediately.  And in addition, the presumed purpose 
of FullForm[expr] is not to do some evaluation or calculation using 
expr; it's to give the user useful information about expr -- which the 
user may well want to get _without_ evaluating expr.  It would not be 
surprising -- it might even be expected -- if FullForm[expr] did *not* 
evaluate expression.

More broadly, when one sees the term expr in M documentation, does that 
always and only mean the **evaluated result** of evaluating expr?  Or 
does it sometimes mean the expr itself, in some external or internal 
form, *before* evaluation.  If the term expr always means the 
*evaluated* form of expr, what term is there to use for the form of an 
expression *before* evaluation?

I believe that M documentation's lack of clarity on these points is 
typical of many other cases where it uses terms like this, and that this 
is a primary cause of most of the difficulties and frustrations 
encountered by M users.  It's also the more surprising and unfortunate 
because of the truly superb quality that M seems to display in all its 
immense graphic, numerical, and symbolic mathematical capabilities.


  • Prev by Date: RE: Question about diference between Animate and Manipulate
  • Next by Date: Re: Multiple Executions of .nb file part2
  • Previous by thread: Re: What does FullForm[ ] actually do?
  • Next by thread: Re: Re: What does FullForm[ ] actually do?