Start to split off formatting routines..

[rocky]

@mmatera Please look over this approach as a way to better organize, modularize and test formatting primitives.

This was all the time I have on this today. There probably is a slicker way to do this using Python class inheritance, and do doubt there are ways to reduce tedium of adding methods to a dictionary.

However, this kind of a approach where a step in the right direction.

[mmatera]

My thoughts:

• I think that it is a good starting point to split graphics.py in something that brings "Expressions" into "Boxes", something that convert boxes into SVG and something else that convert boxes into asy.
• What I do not like so much is to hardlink this conversion. For me, the ideal way to implement the sequence of converting expressions into something showable (is this a word?) object, would be this one:
  • Define export functions (callable from WL) that take an expression and bring it to a string. These export functions then call the corresponding MakeBoxes to bring the expression to a Box form.
  • In ToString, depending on the Format parameter, call these functions.
  • In evaluation.evaluate, just evaluate ToString[result,format, encoding]
    The advantage of this approach is that it is easily extensible out from the code, both by using pymathics modules or by defining "filter" functions in WL, and that the interface between evaluation and frontend can be mostly implemented in WL.

[rocky]

By all means take this as a suggestion and rework or revise it as to make it better and have the characteristics you suggest!

One characteristic of this code that I like would like to see more along these lines, is that I can start to test the to_svg() routines outside having the huge Mathics machinery around.

I was particularly motivated to move in this direction after looking at #1373 where we go down the road of more formatting code with even more dependencies sprinkled about in builtins.

Two things to keep in mind: let's not make perfection an enemy of progress. What has happened too long, especially with respect getting formatting and graphics under control is that we keep talking about improving it, and then don't.

Worse, we are going in the wrong direction: larger modules with more dependencies and more complications.

Removing the hard coding is just another step and a pretty straightforward one. If you want to do this initially great, please do it, and let's see what we have.

However right now, note that not only we have code that is not only hard coded but spread all over the place. graphics.py is currently incomprehensible.

By bringing all of the SVG routines in into a single module, Asymptote in another I can start to understand what's going on with our non-documented (and non-existent) Graphics API. And when I start to compare SVG with Asymptote, I start to see the differences and now wonder why SVG needs an "offset" parameter while the Asymptote doesn't.

[rocky]

@mmatera In this comment I start to DRY to code. As with a number of other places where we DRY code, it does it by assuming some sort of convention. Conventions and abbreviations abound in Physics for example, and if you don't understand the convention, then things are more complex.

Therefore for experimental kinds of things I find it useful to start out with the long form and then figure out how to shorten it.

In proofs, some mathematicians and physicists are able to go immediately to the additional abbreviations and skip steps in proofs. I can't and find it helpful to start out with the long form and then compress from there.

There still are two routines that need to get moved out of the Builtin code. And I would like to start to work up a test for just the conversion routines.

One other thing I love about this is that I now see the possibility of being able to write a utility function which I can use to write SVG. With this I can use this to experiment with SVG's in a way that is in less heavy form than going through Mathics. And we can do that for Asymptote and the next thing and the next thing...

[mmatera]

If this is a temporary way to disentangle the code, I think it is OK. Also if at the end, we only expose to the core a function that convert an expression into an svg.

[rocky]

@mmatera this PR is starting to get large and it is complete as it is. (I noticed that an earlier version was merged into another branch).

Of note is how we can now start to test SVG formatting in a slightly more lighter-weight way and without a graphics interface.

As I go through the code, I am finding slop. For example, an _ArcBox to_svg() routine that is not used. Or that we format SVG circles as ellipses, but SVG points as circles. Do you know why we don't implement Circle using SVG circles?

Anyway, one point of this exercise is that when we can break the code down into smaller testable pieces that can be scrutinized, we we can find weaknesses and fix them more easily.

After this clears, I'll probably start doing the same thing for to_asy(). And there is to_json() for graphics3d. And then there is comparing them to ensure they all have the maximum features of the others. And maybe, just maybe, from this we can describe an API for what it would take to write other graphics formatting interfaces.

What do you think?

[mmatera]

@rocky, I am still not completely convinced about the formatting mechanism here, but I think that this is a step forward to where we want to go. So let's merge this, and do the same with asy. Eventually, we can think again about how these routines are called/encapsulated.

[rocky]

@rocky, I am still not completely convinced about the formatting mechanism here, but I think that this is a step forward to where we want to go.

I agree that there may be better ways to do this. I don't know enough though to know what it is. But I do know there are lots of good properties and benefits of this over what we have now.

When I look at the unit test, some of the ugliness that is in there is a result of awkwardness of the underlying code.

After converting asymptote, I am hopeful that we'll be in a better position to reassess things. At any point I am fine with ripping things out and redoing. (But I find it hard that we'd go back to what we have now.

So let's merge this, and do the same with asy.

Thanks!

Eventually, we can think again about how these routines are called/encapsulated.

Absolutely!