Re: What does FullForm[ ] actually do?
- To: mathgroup at smc.vnet.net
- Subject: [mg90664] Re: What does FullForm[ ] actually do?
- From: magma <maderri2 at gmail.com>
- Date: Fri, 18 Jul 2008 04:02:28 -0400 (EDT)
- References: <g54oj0$eu9$1@smc.vnet.net> <g56t9n$3qv$1@smc.vnet.net>
On Jul 12, 11:35 am, AES <sieg... at stanford.edu> wrote:
> In article <g56t9n$3q... at smc.vnet.net>,
> Jean-Marc Gulliet <jeanmarc.gull... 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.
AES you certainly have a lot of time to split hair and write about
it :-) Good for you.
As it has been said, FullForm is no exception to other functions
without Hold attributes.
I do agree with you that, intuitively, it would have been better if it
had a Hold attribute, so that one could see the full form of the
argument and not the full form of the result of the argument.
Perhaps there were good design reasons for not doing so or perhaps it
was just like deciding on which side of the road cars should drive (at
the beginning of the 20th century).
Anyway...you can easily modify FullForm function and put it in the
init file.
Attributes[FullForm] = {HoldFirst, Protected}
Now if you type
4 + 5 // FullForm
you get
Plus[4,5]
and
FullForm[y = {a + b}]
gives you
Set[y,....]
as you wished