11

This question follows on from the answer given by Michael Pilat in Preventing “Plus” from rearranging things. There he defined a custom + notation using

Format[myPlus[expr__]] := Row[Riffle[{expr}, "+"]]

The problem with this is you can't copy and paste the output (although % or Out[] still works). To get around this you should use the Interpretation type facility which allows an expression to be displayed as one thing, but interpreted as another when supplied as input. My modification of Michael's answer is

Format[myPlus[expr__]] := Interpretation[Row[{expr}, "+"], myPlus[expr]]

This can be copied and pasted successfully. The problem lies in modifying copied expressions. You can convert a copied expression back to InputForm using Ctrl-Shift-I then change anything you want and use the InputForm in any expression. But if you try to change it back to StandardForm using Ctrl-Shift-N then you enter an recursion where the second argument in the Interpretation repeatedly gets evaluated. This is despite Interpretation having the attribute HoldAll (which works properly during normal evaluation).

Normally, when defining simple notations I use the low-level MakeBoxes, eg

myPlus/:MakeBoxes[myPlus[expr__],fmt_]:=With[{r=Riffle[MakeBoxes/@{expr},"+"]},
   InterpretationBox[RowBox[r],myPlus[expr]]]

which works perfectly, so I have not encountered this recursion problem before.

So my question (finally) is: What went wrong with my Format type command and how can it by fixed? Or: How do you make a high-level equivalent of my MakeBoxes type command?

Community
  • 1
  • 1
Simon
  • 14,631
  • 4
  • 41
  • 101
  • BTW, since Interpretation works fine during normal evaluation, this might just be a bug with the "Convert To" type evaluations... – Simon Nov 06 '10 at 07:20
  • Unable to replicate on M'ma 7.0.1/Linux AMD64. Tested your Interpretation[] expression as "myPlus[a, b, c]". Converts back and forth without any difficulty. – Eric Towers Nov 10 '10 at 04:28
  • @Eric That's the same version and system I'm running. I've sent a bug report to WRI to see if they reproduce the behaviour. – Simon Nov 11 '10 at 00:16
  • @Eric: A support guy at WRI reproduced the behavior on multiple systems and has forwarded the bug onto the kernel team... – Simon Nov 27 '10 at 06:22
  • @Simon: Cool. So it's just me. :-) – Eric Towers Nov 30 '10 at 23:52
  • @Simon Half a year have passed. Have you got a solution for this problem? – Alexey Popkov Jun 04 '11 at 06:58
  • @Alexey: No. The WRI technical support guy said he forwarded the issue on to the developers, but I haven't heard anything more. If you want to bug them the incident number is [TS 39116]! Basically, for my work I'll continue to use `MakeBoxes`. (So maybe I should just accept @Michael's answer then...) – Simon Jun 04 '11 at 07:24
  • 1
    @Simon This issue can probably be explored by using the technique for probing the interaction between the FrontEnd and the Kernel presented by David Wagner in his 1996 year article ["Power Programming: *MathLink* Mode"](http://library.wolfram.com/infocenter/Articles/1184/). It is interesting but at this moment I am not familiar with it. May be later... – Alexey Popkov Jun 04 '11 at 07:46
  • @Alexey - Looks interesting (and promising). Remind me about it in about two months time when have some free time! BTW how goes your MathLink/kernel hacking? – Simon Jun 04 '11 at 08:02
  • 1
    @Simon The development of my [`krn5Eval` function](http://stackoverflow.com/questions/4983301/executing-code-in-v-5-2-kernel-from-within-v-7-01-session-through-mathlink) is finished (for Windows, fully featured for 32 bit systems). Now it is a quite reliable instrument for anyone who wish to transparently evaluate some code in older kernel without leaving the current (newer) version of *Mathematica* and having almost complete illusion that the newer FrontEnd works directly with this older kernel. Probably I will share this Notebook some time later if I will find an appropriate place for this. – Alexey Popkov Jun 04 '11 at 08:22
  • @Alexey - Sounds good (but I use 64 bit linux...). Maybe see if you can write an article for the Mathematica journal or just [submit it to library.wolfram](http://library.wolfram.com/contribute/) – Simon Jun 04 '11 at 12:05
  • @Simon Submission to library.wolfram.com is good idea. Do you know how long do they consider a request to publish? What are requirements for acceptable publication? – Alexey Popkov Jun 05 '11 at 02:27
  • @Alexey: Sorry, I've never actually submitted anything there, so I don't know. – Simon Jun 05 '11 at 03:18
  • @Simon In the comments above you asked me to remind you about David Wagner's 1996 year article ["Power Programming: *MathLink* Mode"](http://library.wolfram.com/infocenter/Articles/1184/). So now I have done this. – Alexey Popkov Aug 14 '11 at 08:38
  • @Alexey: Thanks! However, I still haven't finished my thesis so don't yet have that free time. I've added the article to my "to read" folder... so hopefully I'll get to it soonish. – Simon Aug 14 '11 at 08:52

1 Answers1

11

I consulted with a colleague about this, and his recommendation was essentially that putting up-value definitions on MakeBoxes as you demonstrate is better than using Format when you want things to be tightly integrated from output back to input. Format isn't really intended to produce output that can be re-used as input, but just to format output, hence the unexpected recursion with Interpretation when converting to StandardForm, etc.

You might find the function ToBoxes a useful complement to MakeBoxes.

Finally, here's a tutorial about box structures.

HTH!

Michael Pilat
  • 6,480
  • 27
  • 30
  • Thanks Michael. The strange thing is the construction works fine except when you "evaluate in place". A support guy at WRI has submitted a bug report for me. For now, I will keep using `MakeBoxes` (and `ToBoxes`). – Simon Nov 27 '10 at 06:24