Existing CAS commands --> Prime discussion

[jtm]

Here's a useful CAS "command" (syntax, really) that’s already implemented, but not documented or sensibly presented in CAS history:
    m1:=hilbert(99):;
where the emphasized bit suppresses the value returned by the assignment statement, and instead displays
    nodisp(m1:=hilbert(99))                             "Done"

in place of the special syntax. Trouble is, nodisp is not defined, so click-copying and evaluating the history entry
    nodisp(m1:=hilbert(99))
yields
    nodisp(m1:=hilbert(99))
                ⎛⎡  1    1/2    1/3    1/4    1/5    1/6    1/7    1/8    1/9    1/10
                ⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯
    nodisp⎜ ⎢1/50 1/51  1/52  1/53  1/54  1/55  1/56  1/57  1/58  1/59
                ⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯
                ⎝⎣1/99 1/100 1/101 1/102 1/103 1/104 1/105 1/106 1/107 1/108

except with nicer formatting, ninety-six additional rows in place of the ellipses, and preceded by a twenty-second or so delay while the 9,801-element matrix of fractions is formatted for display.

While defining
    nodisp(x) := when(type(x) == 0, "Done", "Done")
apparently fixes the re-evaluation problem, I don’t know enough about either Xcas or the Prime to be certain that this works in the general case*, and it's probably not a reasonable candidate for the “one, and preferably only one” way to do such a simple, fundamental thing as suppressing output of a function called only for its side effects.

Including the original ":;" syntax in both history and copy/paste seems like a reasonable solution (assuming, of course, that I haven’t overlooked an existing non-hack alternative!).

P.S.: The when expression in my definition shows up in textbook-format history (more or less) as written, but algebraically displays and click-copies as an (undocumented) C-style “p?q:r” conditional operator.

P.P.S.: How difficult would it be to provide, at least as an option, an actual history of verbatim, unevaluated input in the history, instead of a pretty-printed representation of the syntax tree after it has been accepted by the evaluator? Because the latter, current behavior has serious downsides that wouldn’t go away if it worked “correctly” in every case.

Most important example of why: valid input may nevertheless be mistaken, and it’s much harder to correct mistakes once original “nearly correct” input has been discarded in favor of considerably different “input”, whether or not the latter happens to be semantically equivalent to the original mistaken input.

It’s as if a psychotic teacher, instead of marking a student’s incorrect homework and returning it, redid all the work for the wrong answers from scratch in an entirely different way, shredded the original homework, then justified this behavior on the grounds that the “reimagined” errors were logically equivalent to the student’s original mistakes…

Less important example: if I’m using the CAS or Home screen to interactively prototype things that will ultimately be pasted into code, the current behavior forces me to either adopt to the history window’s (not necessarily stable between releases, and potentially subject to the whims of very machine-like implementation details) “coding style”, or else waste time either reformatting history or diligently copying everything I may want to save for reuse into the clipboard before evaluating it “just in case”, largely defeating the purpose input history exists to serve.

* In particular, I'm assuming without proof that the type function

1. has no constraints on the type of its argument.
2. never leaves its argument unevaluated.
3. always returns values type-compatible with an equality test against zero**.
   

** While my nodisp definition seems to work as well without the equality test as with, I can’t find any documentation (HP or Xcas) suggesting that the automatic Boolean conversion of what appears to be any (exact or inexact, real or complex, rational or irrational) number is anything more than an implementation detail, so I include the equality test.