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, 2019 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, 2019 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$ Aug 21, 2019 at 19:25
  • $\begingroup$ Did you include @kglr's ClearAll[foo] command as well? $\endgroup$
    – Carl Woll
    Aug 21, 2019 at 19:50

2 Answers 2


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.


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].

  • 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, 2019 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, 2019 at 7:12
  • $\begingroup$ Sure, a separate answer is not needed. $\endgroup$
    – Kuba
    Aug 21, 2019 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$ Aug 21, 2019 at 18:17
  • $\begingroup$ @Kuba, please see edit - do I need to ask as a separate Q? $\endgroup$ Aug 21, 2019 at 18:25

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.