[Date Index]
[Thread Index]
[Author Index]
Re: Re: What does FullForm[ ] actually do?
*To*: mathgroup at smc.vnet.net
*Subject*: [mg90563] Re: [mg90546] Re: What does FullForm[ ] actually do?
*From*: Andrzej Kozlowski <akoz at mimuw.edu.pl>
*Date*: Sun, 13 Jul 2008 15:47:42 -0400 (EDT)
*References*: <g54oj0$eu9$1@smc.vnet.net> <g56t9n$3qv$1@smc.vnet.net> <200807120933.FAA25375@smc.vnet.net>
Since I am already on record stating that I do not think the
Mathematica documentation (both in paper and online form) is a very
good way to learn the Mathematica programming language I am not going
to contradict myself this time (however much I am tempted). The onus
is, I think, on the people who wrote to disagree with my view of that.
However, I would like to point out once again that there is a whole
sizable library of books out there that do an excellent job of
teaching Mathematica programming to an absolute beginner. Isn't it
strange that someone who has written so much about the lack of books
by outside authors on features specific to version 6 has actually not
tried reading even a single one of the existing ones?
Andrzej Kozlowski
On 12 Jul 2008, at 18:33, AES 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." [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: How to use package without manually evaluating?**
Next by Date:
**Re: What does FullForm[ ] actually do?**
Previous by thread:
**Re: What does FullForm[ ] actually do?**
Next by thread:
**Re: Re: What does FullForm[ ] actually do?**
| |