Timeline for How does Mathematica wrap code for front-end needs? Why does this wrapping affect the evaluation?
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 9, 2015 at 9:12 | vote | accept | Piotr Semenov | ||
| Nov 26, 2012 at 10:43 | comment | added | jVincent |
@PiotrSemenov Furthermore, had they at least just wrapped your code in a single front-end formatting call, eg. FrontendFormat[exp], it would be trivial to cercumvent in this kind of upvalue definitions, but instead we are given a innocently looking If, meaning that you have to tailor your code around the assumed behavior of the front-end in a most in-elegant way.
|
|
| Nov 26, 2012 at 10:41 | comment | added | jVincent | @PiotrSemenov I think this is a case where the guys at Mathematica made a design error. It makes sense to do programmatical formating of your output to shorten long output, and if you are going to do this, then of cause it makes sense to do it using Mathematica's own programming language. However it doesn't makes sense that the code that's used is exposed to users under some upvalue definitions. I think someone just didn't think through that this was possible. | |
| Nov 26, 2012 at 8:25 | comment | added | Piotr Semenov | @jVincent Your insight into my code is great so I have caught it. The reason was simple :) So it is not a bug as it can be thought. Many thanks! | |
| Nov 26, 2012 at 8:15 | comment | added | Piotr Semenov | @jVincent Thank you very much! Your answer makes the subject more clearer. But I do not understand up to this day why pattern matching (Mathematica core, back-end) is going after wrapping by front-end code. All architecture patterns like MVC (link) say that visualization and core should be independet from each other as possible. | |
| Nov 25, 2012 at 22:45 | history | answered | jVincent | CC BY-SA 3.0 |