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.

IDE

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.

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.

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.

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:

Quaternions

CliffordAlgebra

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.

Better Support for Working with Finite Structures.

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.

Computer Algebra Systems

This page is a wish-list for Fricas, it is part of a set of pages devoted to my experiments with open source computer algebra programs in this case FriCAS. These page start here where I have put some information about computer algebra systems.and the FriCAS pages start here.

SPAD Language

Although the Axiom/FriCAS computer algebra system is written in Lisp, users of the program don't need to know Lisp. The SPAD (a contraction of Scratchpad) language is used when we want to implement custom algebras and mathematical structures.

Other Options - Idris

Since Axiom / FriCAS is not ideal I am also looking at other languages such as Idris. When it was written SPAD was far ahead of its time but modern languages are finally now catching up and implementing these things in a more consistent way, Some of the issues with SPAD are:

SPAD does not conform to modern expectations and so has a steep learning curve.

Pattern matching is unpredictable for users.

Problems with type system, for example difficult to implement higher order types (kinds), so cant implement category theoretic structures such as monads.

Uses a non-standard parser, this means that error message are not very helpful.

Low level code is written in Lisp, this causes a number of problems, for example it is not possible to write parallel code.

Proofs are not implemented and messy code would make that difficult.

I am therefore experimenting with Idris (see this page), it looks very promising however I am finding some problems in implementing some thing in Idris, although Idris has the kind of structure that I want there are problems when it comes to the user interface (input/output). I think it is really important that mathematical structures are represented using a notation that mathematicians can recognise (both in REPL and compiler). Some of these issues are:

Hard to notate variables, expressions and equations.

Assignment uses '=' instead of ':=' which means that '=' cant be used for equations.