10
$\begingroup$

In Mathematica versions up to 10.1 we could get string representation of given boxes by passing them to ToString with InputForm:

$Version
(* "10.1.0  for Linux x86 (64-bit) (March 24, 2015)" *)
ToString[SuperscriptBox["x", "2"], InputForm]
(* "\\(x\\^2\\)" *)

This is first example from linked tutorial, which is also used as last example in "Examples > Scope" section of ToString documentation.

It no longer works in v10.2:

$Version
(* "10.2.0 for Linux x86 (64-bit) (July 6, 2015)" *)
ToString[SuperscriptBox["x", "2"], InputForm]
(* "SuperscriptBox[\"x\", \"2\"]" *)

How can we get string representation of boxes, known from previous versions, in v10.2?


This issue has been brought to my attention by baryonicnonsense in a bug report.

It was reported to WRI as [CASE:3419732].

$\endgroup$
4
  • 4
    $\begingroup$ As far as I know, this was an intentional change. The InputForm of a box expression will no longer use linear syntax, it will be the expression itself. The linear syntax can still be read for backward compatibility, but is not generated any more. Unfortunately, the documentation did not get updated, and that is a bug. $\endgroup$
    – ilian
    Commented Sep 10, 2015 at 1:18
  • 2
    $\begingroup$ @ilian Does it mean that we should expect fundamental changes in how for example ::usage messages should be defined in the next release (actually defining ::usage messages currently is still huge headache)? $\endgroup$ Commented Sep 10, 2015 at 1:39
  • $\begingroup$ You could consider adding some of your packages at PackageData[]. $\endgroup$
    – Szabolcs
    Commented Sep 12, 2015 at 13:29
  • $\begingroup$ @Szabolcs I added two of them already. Problem is that, the more I learn Mathematica, the sillier my old packages seem to me. I feel some of them need serious refactoring before I do something that will attract more attention to them. $\endgroup$
    – jkuczm
    Commented Sep 12, 2015 at 19:17

1 Answer 1

15
$\begingroup$

This was an intentional change. It is no longer possible to get "short form linear syntax", as we call it, from the kernel. Instead, the kernel now emits only "long form linear syntax" for StandardForm/TraditionalForm, and the boxes themselves do not do anything special for InputForm.

This is the first step in what will be a multistep process to replace linear syntax by something both easier for humans to parse/write and easier to implement and maintain. While I can't share any additional details on what the final solution will be, I can assure you that we are keenly aware of potential compatability issues. We will ensure that all existing package files and notebooks continue to work. The only possible breakage is if you code depends very preciesly on the specific forms of two-dimensional strings, but that is both unavoidable and pretty rare. I don't think I encountered any such issues in our internal code base. On the other hand, making this change allowed me to fix/resolve a large number of bugs which had languished for years, so on the whole I think it is quite positive.

As for the specific question about usage messages: while you won't have to change how you write usage messages, the end goal is to make it as easy to write typeset strings as it is to write box expressions. So I think on the whole you find the final state quite an improvment over the current sitation.

PS: I apologize for not updating the documentaiton. I'll go do that right now...

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.