Some of the changes I would like to Axiom/FriCAS are:
- Better error messages when working on SPAD code, also hide underlying Lisp nature of the program from users using interpreter and compiling SPAD.
- Ability to compile to other languages and to embed SPAD code in other programs.
- Support for 2 way graphics interface.
- Ability to specify operator precedence for a given domain.
- Better type system.
- Ability to specify identities and axioms for a given domain.
- Add ability to write equation solvers for per domain.
- Better support for working with finite structures.
- Remove overlapping documentation and make documentation writing easier.
This is just my own personal list, others may disagree.
I will go through these in more detail below. This may read like a list of complaints (and it is) so I should say that Axiom/FriCAS is a very good program, I just want to help to make it better.
Better Error Messages When Working on SPAD Code
I would like better error messages when using both interpreter and compiler. Also hide underlying Lisp nature of the program from users using interpreter and writing SPAD.
The error messages in the interpreter don't seem very helpful, for instance if I just type something in at random:
(1) -> a|b >> Error detected within library code: (1 . failed) cannot be coerced to mode (NonNegativeInteger)
- Why is this an error with the library code rather than user input?
- What has this got to do with a NonNegativeInteger?
Some error messages are even worse and expect user to understand the underlying Lisp nature of the program.
Error messages when writing code for SPAD are often different from the interpreter errors. These compiler errors can be even more difficult to find. Some errors, with the top level syntax, don't give any clue where the error might be in the whole code. Other errors display a whole chunk of lisp code.
It would be useful to have documentation with a list of all the possible errors and what might be done about them. I started to keep a list of the errors that I was getting, but soon gave up, see page here.
There are some replies to this request on the page here.
A lot of people these days (including me) want things like:
- Syntax Coloring
- Content Assist
- Validation and Quick Fixes
- Integrated error messages and Warnings
I made an attempt, for more information see: this page, to build such an IDE and I think this shows that: the concept, at least, is viable.
Ability to Compile to Other Languages and to Embed in Other Programs.
I would like to be able to compile to the source code of a more mainstream language so that I could then add graphics and other things better done in another language.
SPAD is a very powerful language but it is also quite specialised. It seems silly to try to do things in SPAD that are not mathematical and are more easily done in other languages.
The most important example for me is graphics. I would like to work with finite mathematical structures, however input/output is very messy using the command line (just look at graph theory here) the user has to type in and try to understand long complicated strings) it would be so much more user friendly with a two-way graphical interface.
Developer resources seem to be spread too thinly for, even the core mathematics. I would like to use other languages to do what they are good at, specifically graphics but also other areas where other languages have better libraries.
I don't really like the idea of external (pipe) interfaces to other programs. The problem is that:
- It could be a hassle for non-techies to set up and debug.
- If anything changes: FriCAS, Lisp or other program, then it could stop working.
I also don't like the idea of some mixed language setup if it requires two garbage collectors to be coordinated. It would be a lot better if FriCAS compiled to the source code of another language.
Support for 2 way Graphics Interface.
Although I would prefer to embed SPAD generated code into another language (see feature request #5) a second choice option would be to make it easier to have a 2-way interface to other programs.
One approach would be to make it easier for input and output formatters to communicate with external programs. It is difficult to do this at the moment and it requires a lot of specialised code, it involves a hack involving iohooks and requires a new build.
There are issues with output formatters as discussed on this page.
Output formatters use the intermediate structure 'OutputForm'. This is a very messy structure as also discussed on this page, this structure tends to be text based. It would be good if it had better support for non-textual structures such as graphics. Of course, graphics structures can be expressed in textual form, but it would be more efficient not to have to encode as text and then parse back to required structure.
I would like to see an easier way for FriCAS to communicate with pipes.
Ability to Specify Operator Precedence per Domain.
In FriCAS operators are very heavily overloaded. That is an operator, such as '/\', can be defined in many domains. However, although an operator can be used for many things, precedence for a given operator is globally set.
This is specifically a problem in Clifford algebra since the same operators are used for logic.
FriCAS allows me to type in an expression like A/\B*C/\D and it gets the result wrong:
- (A/\B)*(C/\D) -- is what I expected
- ((A/\B)*C)/\D -- is what I got
This is a serous problem for Clifford algebra which severely limits its usefulness.
I did ask about infix precedence here:
It would help, as a first step if this could be fixed in the output formatter then, if the user gets it wrong, at least they will know it from the FriCAS output.
In order to implement this I think the parser would need to be table driven (that is driven by a table of the precidence values for each operator). I am experimenting with implementing the interpreter in SPAD as decribed on the page here. In particular the parser is described here.
Better Type System.
Some of the limitations are:
Higher order types are called 'Type' and have no further information.
It does not seem possible to hold a type constructor (Like 'List') as a 'first class function' so that we could implement monads for example, for more information see page here.
I think it would also be useful to have type aliases. It seems to me that the most common use of macros is to replace a long complicated type with something shorter and easier to read. However, macros can cause unexpected problems, also type aliases could be available to compiler for error messages and so on.
I have been experimenting with implementing a domain in SPAD to hold types, this is decribed on the page here. I would like to use this to experiment with higher order types as discussed here.
Ability to Specify Identities and Axioms for a given Domain.
I have explained this more on the page here.
SPAD does already have a mechanism for specifying rewrite rules (described on the page here. Could this be extended to allow, for instance, identities to be specified as part of each category and domain and to be inherited in the same way that the function signatures are.
Add Ability to Write Equation Solvers for a given Domain.
FriCAS has quite good support for say, systems of polynomial equations in field or OrderedRing, see numsolve.spad.pamphlet for more details.
Would it be possible to generalise this so that other SPAD domains have their own equation solvers for their domain. With variables that represent elements of that domain.
Cases that I would specifically like are:
So, for example, we might want to write equations where the variables are quaternions. So we need to write a solver which can handle a non-commuting algebra.
- There are some useful replies to this request on the page here.
- I have put some information about the SPAD mechanism for equation solvers on the page here.
Better Support for Working with Finite Structures.
- Set Theory (ZF and NBG)
- Category Theory
- Type Theory
- Domain Theory
Remove Overlapping Documentation and Make Documentation Writing Easier.
At the moment documentation is spread between:
- Literate Programming (which is spread over about 400 pamphlet files and it is not always clear which one might hold the information that is being sought)
- HyperDoc - An old fashioned interface, in a small window on the screen, which I never use because it crashes too often.
- Axiom Book in either PDF or html form
- FriCAS Wiki, formally known as Axiom Wiki.
- fricas-devel mailing list
- Online Documentation spread over various places on the web.
Much of this is out of date and confusing. It is very incomplete, even if you manage to search through all of this, chances are you wont find what you want?
I don't find Literate Programming or hyperDoc encourages better documentation, in fact I think they make it more difficult. As experiments, judging by the results in FriCAS both literate programming and hyperDoc have failed.
I think that a lot of this documentation needs to be brought together in on place so that a person, looking for information on a given topic, knows where to find it.
I think that it needs to be easy to produce documentation using off-the-shelf tools and it should be easy to add diagrams. However interactive documentation is just not worth the developers time for the minimal benefit.
I think the documentation should be on a well structured website with lots of diagrams. I think it should be static (not wiki or hyperDoc).
This is all just my opinion, which is not important, the important thing is what would give a potential new user of FriCAS the impression that this is a high quality program that it is worth investing their time and commitment too. Also what is it practical to do with to developer resources available, its no use having a sentimental attachment to certain paradigms if there are not enough people to do it properly.