Re: Re: What does FullForm[ ] actually do?
- To: mathgroup at smc.vnet.net
- Subject: [mg90560] Re: [mg90546] Re: What does FullForm[ ] actually do?
- From: DrMajorBob <drmajorbob at att.net>
- Date: Sun, 13 Jul 2008 15:47:08 -0400 (EDT)
- References: <email@example.com> <firstname.lastname@example.org>
- Reply-to: drmajorbob at longhorns.com
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?
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
Prev by Date:
Next by Date:
Re: How to use package without manually evaluating?
Previous by thread:
Re: Re: What does FullForm[ ] actually do?
Next by thread:
Re: What does FullForm[ ] actually do?