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.