Related to this question,

Why does this InterpretationBox construct work when x, y are numbers but not undefined symbols or more complex expressions?

foo /: MakeBoxes[c : foo[x_, y_], form : (StandardForm | TraditionalForm)] := With[{boxes = SubscriptBox[x, y]}, InterpretationBox[boxes, c]]


Originally intended to state the full problem but then simplified it. kglr's answer does not work as intended, so here is the complication:

Would like foo[r,m] to display in subscript form, but when provided with a SubValue, it should evaluate to the rhs:

foo[r_,m_][h_]:= m h + r




Subscript[2, 3]

Plugging in x inserts $CellContext:

foo[2, x]

Subscript[2, $CellContext`x]

or fails with List:

foo[{1, 2}, 3]

An unknown box name (List) was sent as the BoxForm for the expression. Check the format rules for the expression.

  • $\begingroup$ I recommend a talk on typesetting by Jason Harris, that is definitely broader but it won't be a waste of time. Your problem is addressed somewhere for sure. $\endgroup$ – Kuba Aug 21 '19 at 7:08
  • $\begingroup$ You need to provide more details. Adding a format for foo should have no effect on the evaluation of foo. You probably have a lingering definition of foo that is causing issues. $\endgroup$ – Carl Woll Aug 21 '19 at 19:12
  • $\begingroup$ @CarlWoll, just tried on a fresh kernel with same results. Using foo[r_,m_][h_]:= m h + r and kglr's MakeBoxes def, foo[2,3][4] displays the subscript form but does not evaluate foo to rhs. $\endgroup$ – alancalvitti Aug 21 '19 at 19:25
  • $\begingroup$ Did you include @kglr's ClearAll[foo] command as well? $\endgroup$ – Carl Woll Aug 21 '19 at 19:50

Answering the title question, when creating boxes, everything should be a *Box object or a string (or possibly a list). Inside of a box object, excluding options, again, everything should be a *Box object or a string (or list). There is one exception to this rule. It is ok to use integers instead of the corresponding strings. I'm not sure why this exception is made, as it results in the confusion that you face when using x instead of 1 breaks things.

As for the actual format code, another possibility is:

foo /: MakeBoxes[foo[x_, y_], form_] := MakeBoxes[Subscript[x, y], form]

Finally, I think your edited issue is that you included ClearAll[foo] after defining the subvalue definition.

| improve this answer | |

Replace boxes = SubscriptBox[x, y] with SubscriptBox[ToBoxes@x, ToBoxes@y]:

foo /: MakeBoxes[c : foo[x_, y_], form : (StandardForm | TraditionalForm)] := 
 With[{boxes = SubscriptBox[ToBoxes @ x, ToBoxes @ y]}, InterpretationBox[boxes, c]]


foo[2, 3]

Subscript[2, 3]

foo[2, 3]

Subscript[2, x]

foo[{a, b}, {1, 2, 3}]

Subscript[{a,b}, {1,2,3}]

As suggested by @Kuba in comments, use

boxes = SubscriptBox[MakeBoxes @ x, MakeBoxes @ y]

to avoid evaluation leaks in cases like Hold @ foo[f[1 + 2], x + y].

| improve this answer | |
  • 1
    $\begingroup$ MakeBoxes should be used to avoid evaluation leaks when things like Hold @ foo[1+1, 2] are being (?)typeset. $\endgroup$ – Kuba Aug 21 '19 at 7:07
  • $\begingroup$ Thank you @Kuba; excellent point. I will update with your suggestion if you do not intend to post it as an answer. $\endgroup$ – kglr Aug 21 '19 at 7:12
  • $\begingroup$ Sure, a separate answer is not needed. $\endgroup$ – Kuba Aug 21 '19 at 7:18
  • $\begingroup$ @kglr Thanks, however, this doesn't work with my intended application, which is to have SubValues for foo. I originally intended to add this bit but in the end decided to simplify it. Will edit Q. $\endgroup$ – alancalvitti Aug 21 '19 at 18:17
  • $\begingroup$ @Kuba, please see edit - do I need to ask as a separate Q? $\endgroup$ – alancalvitti Aug 21 '19 at 18:25

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.