using a private symbol to store the state inside DisplayForm. #617
Conversation
| previous_df, evaluation.in_display_form = evaluation.in_display_form, True | ||
|
|
||
| old_value_in_display_form = SYMBOL_FORMATBOXES.evaluate(evaluation) | ||
| evaluation.definitions.set_ownvalue(SYMBOL_FORMATBOXES.name, SymbolTrue) |
There was a problem hiding this comment.
Notice that here we can not use the higher level way
Expression(SymbolSet, SYMBOL_NO_FORMATBOXES, SymbolTrue).evaluate(evaluation)
because the attributes.
There was a problem hiding this comment.
The drawbacks of this approach are that the access to the attribute is slower, and the code to set the context is larger and weirder than just setting an attribute.
mmatera
changed the title
| class PrivateSymbolThatControlsTheStateOfDisplayForm(Builtin): | ||
| """ | ||
| <dl> | ||
| <dt>'PrivateSymbolThatControlsTheStateOfDisplayForm' |
There was a problem hiding this comment.
Small thing - please indent nested <dt>.
There was a problem hiding this comment.
@rocky, the question is, do you think that this is a better approach?
There was a problem hiding this comment.
@mmatera good question. I have to think about it. What I'd be looking for is clues in the WMA code.
Think of this like the way a physicist would. We have two hypotheses for how this might have been coded in WMA. Is there a test that distinguishes these? Suppose we hypothesize that WMA follows the WMA way to do this, what test could we come up with that would distinguish the implementations? (Likewise for the other way to code)
There was a problem hiding this comment.
Ja, it is a curious request! Because it is exactly as this physicist is trying to distinguish what is the implementation in WMA :)
Look at this, for example,
If I believe in this output, I have to assume that there is not a private hidden symbol but an internal variable inside the kernel.
There was a problem hiding this comment.
Ok - I trust your conclusion, but I don't follow it. The output above doesn't indicate anything to me one way or another. Please break it down for a novice.
If it were implemented as a private hidden symbol what then would you expect to see?
There was a problem hiding this comment.
We should probably implement TracePrint so that we can check correspondence easier.
There was a problem hiding this comment.
I would expect an evaluation for the corresponding hidden symbol. This is an example in which internal variables are used:
(I just cut the first lines)
Notice the use of symbols in hidden contexts (BoxFormls, IntegrateDumpTestLimits, BoxFormopt). Tracing MakeBoxes[DisplayForm[...]]` I do not see such kind of symbols in hidden contexts.
| @@ -396,7 +403,7 @@ def apply_general(self, expr, f, evaluation): | |||
| if isinstance(expr, BoxElementMixin): | |||
| # If we are inside a DisplayForm block, | |||
There was a problem hiding this comment.
Is this really just DisplayForm that could do this? There are no other forms that are like this. Or this isn't something Form creator might want to do?
There was a problem hiding this comment.
By now, this is the only case. This could also be a way to implement InputForm/OutputForm and the other non-standard print forms but setting a different control symbol. In any case, I am not sure that this way is better than the one I proposed before.
There was a problem hiding this comment.
and the other non-standard print forms
What makes a print form "non-standard"?
There was a problem hiding this comment.
MakeBoxes accepts StandardForm|TraditionalForm as the second parameter. In some way, when you evaluate
MakeBoxes[OutputForm[expr], StandardForm]
Makeboxes first applies the format rules associated with OutputForm to expr and its subexpressions. Then, the reference to OutputForm are lost in the expression, but in some way, MakeBoxes knows that has to apply the OutputForm makeboxes rules to the inner expressions. One way to simulate this behavior would be to set a state variable that remembers that we are using OutputForm rules. This is not the way in which I think we should implement this, but it is a possibility.
There was a problem hiding this comment.
but in some way, MakeBoxes knows that has to apply the OutputForm makeboxes rules to the inner expressions.
https://reference.wolfram.com/language/ref/TraditionalForm.html says:
TraditionalForm inserts invisible TagBox and InterpretationBox constructs into the box form of output it generates, to allow unique interpretation.tionalForm
Does this provide a mechanism for how to do this? If so, possibly the same is could done for StandardForm (and is done but just not mentioned). Sometimes it happens that only in implementing the second thing of a kind the general mechanism, and the first is done in a more hacky way is not retrofitted.
This is the alternative version. This makes the control variable "hackable" from inside the mathics session (we can read it) but avoids that the user overwrite the value (because it is protected and locked).