sympy.parsing.sympy_parser
?
sympy.parsing.sympy_parser
. So in a
sense Sympy supports this Cadabraesque mode of working, even
though the tutorials and examples do not emphasise it.
The reason why Cadabra nevertheless uses its own parser, and its
own tree representation of expressions, is simply that an enormous
amount of work would have to be done to rewrite the lot so that it
fits into the Sympy framework. Moreover, little would be gained by
doing this: almost all functionality which is in Sympy and which
would make sense when applied to tensors (think of taking
derivatives, or pattern matching) would require a lot of extra
Sympy code to extend it beyond scalars.
The way things are now the separation is clean, localised, and
relatively easy to maintain. If you would ever rewrite
Cadabra+Sympy from scratch you might take a different approach,
but that's not going to happen soon.
There are a number of reasons for this. For starters, Cadabra's notebook interface predates IPython (that is, a publically available version of it) by quite a few years. That by itself is of course not a very good reason to keep developing the Cadabra notebook interface, but it does play a certain role.
A more important reason has to do with the fact that there are, despite what one might think at first inspection, quite a few differences between IPython/Jupyter and the Cadabra interface. The most obvious one is that Cadabra is a native application, which does not rely on a web browser to display its results. I still think that native applications have their place, as they tend to look and feel much better than web apps.
IPython/Jupyter tend to be focussed a lot on data-centric problems, and less so on being a nice front-end for symbolic mathematics. These two do differ.
Another reason to keep developing the Cadabra notebook interface is that it allows me much more flexibility in trying new features and ideas. As a consequence, Cadabra for instance has a way to open multiple views on the same notebook.