Re: Failure to convert certain symbols to InputForm when using when using AutoGeneratedPackage->True
- To: mathgroup at smc.vnet.net
- Subject: [mg79965] Re: Failure to convert certain symbols to InputForm when using when using AutoGeneratedPackage->True
- From: John Fultz <jfultz at wolfram.com>
- Date: Thu, 9 Aug 2007 06:26:11 -0400 (EDT)
- Reply-to: jfultz at wolfram.com
On Thu, 9 Aug 2007 14:56:42 +1000, Andrew Moylan wrote:
> Create a new notebook and type the following into a Code (Alt+8) cell:
>
> Integrate[x, {x, 0, 1}]
> Sum[x, {x, 0, 1}]
>
> Now select the cell and convert it to StandardForm (Ctrl+Shift+N). The
> special integral and summation symbols, together with two-dimensional
> under-
> and overscripts, and super- and subscripts, appear.
>
> (As an alternative to the above, you could simply type the StandardForm
> directly using two-dimensional input.)
>
> Now save the notebook somewhere. When prompted to create an auto-save
> package, choose to create one. Examine the resulting .m file. It contains
> these lines:
>
> \!\(
> \*SubsuperscriptBox[\(\[Integral]\), \(0\), \(1\)]\(x
> \[DifferentialD]x\)\)
> \!\(
> \*UnderoverscriptBox[\(\[Sum]\), \(x = 0\), \(1\)]x\)
>
> They have not been converted to InputForm (which is normally the case for
> auto-generated package files as of version 6); they have been left as
> boxes!
> Here is what I expected to see in the automatically generated .m file:
>
> Integrate[x, {x,0,1}]
> Sum[x, {x,0,1}]
>
> Why is it that StandardForm integrals and sums are left as uninterpreted
> boxes instead of being converted to InputForm?
The "Convert to..." items in the menus use the kernel. This explains the
strengths and weaknesses of these items. The strengths are that "Convert to..."
is guaranteed to work using precisely the typesetting rules which exist in the
kernel. It will even work if you create your own form or extend one of the
existing ones. However, the conversion goes through the kernel's parser, and
thus throws away information the parser doesn't care about, such as the
placement of whitespace and the existence of comments.
So, saving to package, in fact, does *not* do what Cell->Convert To->InputForm
does. If it did, it would reformat your code and throw away your comments, not
to mention that it would invoke the kernel for every package-saving operation
(and who knows what state the kernel will be in when you want to save?). So,
package-saving is implemented in the front end. This has a few implications.
First, if we're not going to query the kernel about typesetting rules, then we
can really only convert those cases which are fairly unambiguous. This pretty
much amounts to FractionBox, InterpretationBox, and certain subsets of
SuperscriptBox and SubscriptBox usage in version 6. There are some more rules
we could add which remain fairly unambiguous...the integral, sum, product, and
limit rules fit that description, I believe. But we had to ship version 6 at
*some* point, and the complexity of implementing these rules without invoking
the kernel was enough to...well, cause me to answer quite a number fewer
MathGroup questions, at the very least.
I should note, incidentally, that there's one exception to the
no-kernel-invocation rule for package-saving. The conversion of a typeset
Manipulate[] to InputForm is so incredibly useful and so unlikely to suffer any
of the ill effects of going through the kernel parser that package-saving (as
well as copy/paste) will call the kernel to get the Manipulate's InputForm.
Sincerely,
John Fultz
jfultz at wolfram.com
User Interface Group
Wolfram Research, Inc.