[Date Index] [Thread Index] [Author Index]
Re: Re: What does FullForm[ ] actually do?
Precisely the same situation applies to ANY function f (in place of FullForm) unless f has attribute HoldFirst or HoldAll. Arguments are evaluated before f takes action. Documentation can't be expected to mention this prominently for EVERY such function, so why should it for FullForm in particular? Bobby On Sat, 12 Jul 2008 04:33:50 -0500, AES <siegman at stanford.edu> wrote: > 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."  >> >> 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. > > -- DrMajorBob at longhorns.com