11
$\begingroup$

Bug introduced in 10.4 or earlier and persisting through 11.3

[...] I checked and reproduced your issue, and have passed along a report to our developers on the same [...]

CASE:3972929


TextString@HoldForm[1/0]
TextString@Hold[1/0]

enter image description here

Is this behavior expected? I failed to explain this with documentation, the more that it says:

In other cases, expressions are formatted using InputForm

but:

ToString[Hold[1/0], InputForm]
ToString[HoldForm[1/0], InputForm]

enter image description here

The problem is the more important that TextString is a default InsertingFunction for a StringTemplate.

$\endgroup$
  • $\begingroup$ I am not sure, but could it be posible that $1/0$ is interpreted by MMA as a symbol DirectedInfinity and not as an operation? $\endgroup$ – José Antonio Díaz Navas Nov 14 '17 at 18:02
  • $\begingroup$ @JoséAntonioDíazNavas it could be but it is not the case because the message is issued. $\endgroup$ – Kuba Nov 15 '17 at 8:38
8
$\begingroup$

The case of HoldForm appears to by design, although the motivation for that design is unclear. HoldForm should thus be listed as one of the special heads listed in the TextString documentation. The case of Hold appears to be an evaluation leak, but maybe it is intentional for symmetry with HoldForm.

HoldForm Variant

A trace of the HoldForm variant suggests that the behaviour is by design. Here are selected evaluations from the trace:

selective trace of <code>HoldForm</code> variant

The internal ostr helper function has definitions that explicitly strip HoldForm:

Needs["GeneralUtilities`"]
GeneralUtilities`TextString`PackagePrivate`ostr //
    DownValues // Select[Not@*FreeQ[HoldForm]] // PrettyForm

ostr definitions

The documentation for TextString lists a number of heads that are treated specially -- apparently HoldForm should be added to that list.

Hold Variant

The case of the Hold variant is not so clear. Here is a selective trace:

selective trace of the <code>Hold</code> variant

There are no definitions under any of the internal helper functions that explicitly deal with Hold. A close inspection of the trace yields use of Unevaluated, which suggests that some attempt was made to prevent evaluation. But this measure is defeated by later steps.

My guess is that there is an evaluation leak here, but perhaps it is just a happy(?) accident that results in a treatment for Hold that matches that of HoldForm.

Motivation?

Why would HoldForm be stripped when converting an expression to a string? I have no idea. It would seem that the ability to convert unevaluated expressions to strings would be valuable. If it weren't for the explicit definitions on ostr, I would have called this a bug. Now I guess I have to call it an inscrutable design decision.

(This analysis is current as of Mathematica 11.2.0.)

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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