Edit detail for FriCASIssues revision 1 of 2

changed:
-
I have a number of issues that are somewhere between bug reports, new feature requests, problem workarounds and so on. Perhaps if I start to write them down some structure will appear. The issues on this page are my (Martin Baker) thoughts and priorities so far, it might be better if this page was made more general with other peoples input?

<h2>Operator Precedence</h2>

<p>Infix operators such as /\ and \/ may be used in many domains however the precedence of a given operator symbol is fixed.</p>

<p>This means that while the precedence of /\ may be correct when used in the LOGIC and SingleInteger domain it is not correct in the CliffordAlgebra domain.</p>

<p>In fact precedence of /\ and \/ in CliffordAlgebra is highly confusing and almost certain to lead to errors for people who understand the maths but not the inner workings of FriCAS. When using /\ and \/ in CliffordAlgebra always use brackets or use then in the infix form.</p>

<p>This issue applies to both compiler and interpreter.</p>

<p>I seem to remember that there are other issues with infix operators although I can't quite recall the details. As far as I remember only certain character sequences can be used as infix operators. At some stage in the future, when there is unicode support (see below), it would be useful to be able to make a unicode character into an operator and be able to set its precedence from within the domain specification.</p>

<h2>Support For Unicode</h2>

<p>See UnicodeIssues page for much more detailed information about this issue.</p>

Mathematics makes a lot of use of special symbols and characters from different alphabets such as:
<p>Greek alphabet:α β Γ γ Δ δ ε ζ η Θ θ ι κ Λ λ μ ν Ξ ο Π π ρ Σ σ Τ τ Υ υ Φ φ Ψ ψ Ω ω</p>
<p>Special symbols:× ÷ ± • ° √ ð Ð ƒ µ Ø ø Þ þ † ∫ ∂ ◊ ≤ ≥ ≠ ≈ ∞ ∈ ∀ ∃</p>
<p>It seems very unfortunate that users of panAxiom CAS are limited to a small set of characters from ASCII character set. PanAxiom could be much more expressive, easy to read and useful if these unicode characters could be used in: program input/output, variable, function and operator names both in user programs and the axiom code itself.</p>
<p>Some of the issues that need to checked before you can use unicode characters are:</p>

<ul>
    <li>You must have the relevant fonts installed on your computer for the unicode characters that you wish to use.</li>
    <li>Your command line console needs to support unicode and be set to UTF-8.</li>
    <li>Your Lisp must support unicode (sbcl does)</li>
    <li>The version of Axiom/FriCAS/OpenAxiom that you are using needs to support unicode - They only have minimal support at the moment.</li>
  </ul>

<p>The best long term solution is for full support although the issues may take some time to sort out. A shorter term partial solution would be to use some escape sequence to encode unicode characters in strings, variable names and operator names, then use the various OutputForm to translate into the appropriate coding. Each OutputForm may need some lookup table, for instance to support the Greek alphabet in html based based formats we might need a table</p>

Waldek is against escape sequences for the reasons he has explained on UnicodeIssues page. This page explains his approach, I don't yet know what, if anything is planned for Axiom and OpenAxiom.

<h2>Graphics Framework</h2>

The new graphics framework: scene.spad.pamphlet, has a lot of advantages but it only outputs to file formats, 
it would be useful if it could render itself directly from panAxiom to an XWindow.
It would also be useful if its documentation were put into Hyperdoc.

OpenGL library code,

<h2>Use HTML for Hyperdoc</h2>
Personally I like the idea of HyperDoc pages as HTML as it might be able to be rendered by more 
standard library code and perhaps get rid of arcane C code.

<h2>Support for Object Oriented Programming</h2>

<p>Specifically subtype polymorphism with late binding.</p>

<p>In many cases it makes sense to adopt a (non-strictly) functional programming style such as making instances immutable, but in certain cases it really helps to use object oriented techniques.</p>

<p>I think that the graphics framework (scene.spad.pamphlet) is a good example of where that would really help. A design requirement is that the scenegaph needs to hold a large amount of information, A 3D scene might be made from thousands (perhaps millions?) of polygons. For the sake of efficiency we need to be able to modify it without copying the whole thing into a new object for each change.</p>

<p>The object oriented style of programming would seem to be ideal for a scenegraph. Each type of node in the scengraph could be a different object all inheriting from a common object. At the moment this is not easy to do this in SPAD because it does not support polymorphism.</p>

<h2>General Issues</h2>
<p>I think there are some general issues that belong on this page, where its harder to suggest a specific change, but where I perceive some sort of problem.</p>
<p>This involves things like:</p>
<ul>
    <li>The steep learning curve of SPAD and the difficulties involved in debugging code</li>
    <li>Error messages and warnings are usually about the underlying Lisp code and require the user to not only understand SPAD but also Lisp and the internal workings of the interpeter and compiler</li>
    <li>No alphabetical list of errors and warnings with explanation.</li>
    <li>There are differences between SPAD for the interpreter and the compiler.</li>
    <li>No modern IDE features such as code completion and syntax error underling.</li>
    <li>There are some debugging tools but I think it would help to have a better debugging tutorial.</li>
    <li>No external code libraries for things like, writing to XML and graphics files, everything must be written and maintained by the user or FriCAS developers.</li>
  </ul>

<h2>Abstract Algebra</h2>
<p>I seem to remember reading somewhere that pan Axiom is not really aimed at abstract discrete algebra (sets, groups, categories and so on) I don't know if this is true? I've also read somewhere that the best approach is to use GAP and to link it to FriCAS using Sage? I would like to avoid this approach because its difficult to switch between languages and when there are artificial boundaries then there will always be applications that need to cross those boundaries.</p>

<p>I know that FriCAS has some powerful code such as [Permutation] and that the category hierarchy goes down to sets and groups. However this hierarchy does not seem to be specially useful at this level, for instance, [Permutation] domain is not a member of Group category. (I hope I'm right I'm working from memory here!)</p>

<p>What I am looking for is:</p>
<ul>
    <li>Ability to experiment with basic concepts: sets, cosets, lattices, category theory, universal algebra and so on.</li>
    <li>Toolbox approach: that is not force users to use one particular coding of groups (for example) but to allow different domains for permutation groups, group presentation, group representation, Cayley graph, Cayley table, depending on what aspects of groups they want to investigate even though some codings may be less efficient and not scale well. Also be able to represent infinite groups such as braid groups</li>
  </ul>
I'm trying to think of an example where applications cross-over between abstract algebra and FriCAS main focus, I don't know if its feasible but the sort of thing I would like to do is:
<ul>
    <li>Generate an algebra (or a set of algebras and coalgebras) from a group whose elements are defined over another group. That is take a conventional group with a structure defined over a set and apply that structure to another group.</li>
    <li>Generate an algebra (or a set of algebras and co algebras) from a monad.</li>
  </ul>
<p>I see that the Saul Youssef implementation of category theory (see page CategoryTheoryAndAxiom) requires Aldor features such as:</p>
<ul>
    <li>parametric polymorphism</li>
    <li>dependant types</li>
    <li>curried functions</li>
  </ul>
<p>I don't know if these things are a requirement for the sort of thing that I want to do? Perhaps, rather than looking back to Aldor it would be interesting to establish requirement from first principles?</p>
<p>It seems to me that an interesting way to do some of these things is to have first class types (in this case first class domains and categories). That is domains that can generate another domain and instantiate it, call it, pass in function calls, use as a type, etc.</p>
From BillPage Tue Mar 8 09:16:18 -0800 2011
From: Bill Page
Date: Tue, 08 Mar 2011 09:16:18 -0800
Subject: polymorphism
Message-ID: <20110308091618-0800@axiom-wiki.newsynthesis.org>

Quote::

  this is not easy to do this in SPAD because it does not support polymorphism

Could you explain what you mean by this? As I understand it SPAD does indeed support operator polymorphism as part of its basic design. E.g. +, *, in fact any function name can be make to mean many different things even in the same domain provided that the types of the arguments and/or the type of the desired output is different. Could you please given an example of the difficulty?

From martinbaker Tue Mar 8 09:24:33 -0800 2011
From: martinbaker
Date: Tue, 08 Mar 2011 09:24:33 -0800
Subject: 
Message-ID: <20110308092433-0800@axiom-wiki.newsynthesis.org>

What I need it a 'virtual function' which can be called on an general class 
but will use the function appropriate to the specific class found at runtime, 
I'll simplify the graphics example to make the issues clear,

Imagine we have an abstract class  or an 'interface' (in SPAD terms a 
category) called 'shape' which has a function called 'draw'.

Now we want to define various concrete classes (in SPAD terms domains) called 
circle, rectangle and so on which each implement the function 'draw' in a way 
that is appropriate to the specific shape.

Now we have a List of shapes defined like:

mydata: List shapes

because when we are programming we do not know what specific shapes they are. 
At runtime this list gets filled with some combination circle of circle and 
rectangle. We then call draw on elements of the list:

draw(mydata.i)

This will try to call the draw function defined by shape (if it does not exist 
then the compiler will produce an error) but it will not call the draw 
function appropriate to the specific class (circle, rectangle).

From RalfHemmecke Tue Mar 8 14:09:17 -0800 2011
From: Ralf Hemmecke
Date: Tue, 08 Mar 2011 14:09:17 -0800
Subject: 
Message-ID: <20110308140917-0800@axiom-wiki.newsynthesis.org>
In-Reply-To: <20110308092433-0800@axiom-wiki.newsynthesis.org>

Look at http://www.aldor.org/docs/HTML/chap23.html#10
and
http://svn.origo.ethz.ch/wsvn/algebraist/trunk/aldor/lib/axllib/src/object.as .

Aldor and SPAD are not primarily object-oriented. The links above simulate object-oriented concepts. Since in Aldor and SPAD values themselves don't carry any runtime information about their types, one has to explicitly box the type with the value in order to create what is known as an object in other object-oriented languages. Then you have all the things you are looking for, except that you no longer actually think in native SPAD.


From martinbaker Wed Mar 9 01:23:46 -0800 2011
From: martinbaker
Date: Wed, 09 Mar 2011 01:23:46 -0800
Subject: 
Message-ID: <20110309012346-0800@axiom-wiki.newsynthesis.org>

<p>I still think there is a issue here (even if it is only my implementation of scene.spad.pamphlet).</p>

<p>I accept that I am more used to object oriented programming than SPAD and therefore may not have the right mindset but I still feel that, in certain circumstances, it would really help to have the option to work in a more object oriented way.</p>

<p>In scene.spad.pamphlet there is a domain called 'Scene' this represents a tree structure that is defined recursively as follows: </p>

<p>Rep := Record(type : NNI,children : List %,parameters: PARAMS)</p>

<p>Each of these nodes will be a certain type identified by a NNI as follows:</p>

<p>type = 1 then root node</p>
<p>type = 2 then group node</p>
<p>type = 3 then line node</p>
<p>type = 4 then material node</p>
<p>type = 5 then text node</p>
<p>type = 6 then transform node</p>
<p>type = 7 then clip node</p>
<p>type = 8 then Indexed Face Set node</p>
<p>type = 9 then arrows node</p>

<p>This type modifies a large number of the functions in the domain, so I find that nearly every function consists of a set of cases which are selected depending on the type.</p>

<p>I find this all horribly messy because:</p>

<p>* arbitrary integers have to be assigned to node types which are spread though the program and are very difficult to re-factor (it would be hard to change clip node from 7 to 3 for example).</p>

<p>* The domain is too big and messy.</p>

<p>I would like to split this domain into a root node domain, a group node domain and so on for each node type. Then each domain would only need the information relevant to itself. These domains would be much smaller and easier to understand and maintain than one big domain and issues would be concentrated together.</p>

<p>Is there a way to do this that does not involve some horrible hack?</p>

From BillPage Thu Mar 10 07:24:31 -0800 2011
From: Bill Page
Date: Thu, 10 Mar 2011 07:24:31 -0800
Subject: SPAD style
Message-ID: <20110310072431-0800@axiom-wiki.newsynthesis.org>

<p>What you implement now as:<pre>
  Rep:=Record(type : NNI,children : List %,parameters: PARAMS)
</pre></p><p>
would probably be much better represented as a Union something like this:<pre>
  Rep==Union(SceneRootNode ,SceneGroupNode, SceneLineNode, SceneMaterialNode, ...
</pre></p><p>
where SceneRootNode, SneneGroupNode, etc. are domains as you suggested. Some (most?) of these domains would recursively refer to the Scene domain.  Each domain would presumably also export it's own 'draw' function and others as needed.
</p><p>
As I understand it still, this does not have anything to do with "polymorphism" or "late binding".  Spad has two types of "object-oriented" inheritance. The first is via the 'add' construct in domains. E.g.::<pre>
   MyInteger():IntegralDomain == Integer add
     my stuff
</pre></p><p>
The second is via default implementations given in a category. So for example all of the Scene... domains above could be grouped into a category, say SceneCat that exports a default 'draw' function, etc.
</p><p>
An important design consideration in Spad is that Categories and Domains, as <em>types</em> are static. They must be fully resolved at compile time. This does <b>not</b> mean that it is impossible to construct recursive tree like data types. There are situations however where it might be better to take advantage of functions as first order data and carry them explicitly as part of the representation of a domain, i.e. as "data" instead of as "type".  Think this is the main message of the documentation to which Ralf referred above. From your description of your problem I am not convinced that this is needed in your case.
</p>
<p><small><em>BTW, don't you find entering pages in HTML rather a pain? Why did you choose this page format on the wiki?</em></small></p>

From page Thu Mar 10 21:08:14 -0800 2011
From: page
Date: Thu, 10 Mar 2011 21:08:14 -0800
Subject: working from memory not working
Message-ID: <20110310210814-0800@axiom-wiki.newsynthesis.org>

<p><b>Quote:</b></p><p>
<em>[Permutation] domain is not a member of [Group] category. (I hope I'm right I'm working from memory here!)</em>
</p><p>
No that's not right. In general I disagree that "FriCAS is not really aimed at abstract discrete algebra (sets, groups, categories and so on)", quite the contrary. I don't understand your use of the word "discrete". Do you mean "finite" or perhaps "combinatoric"? In any case I would claim that Axiom was in fact designed from the ground up to deal with sets [Set], cosets, lattices (see for example: [SymmetricGroupCombinatoricFunctions]), some aspects of category theory, and universal [algebra]. Perhaps you need to look around FriCAS a little more. I suggest starting by using [HyperDoc] and browse for "*group*".
</p><p>
You may not find everything that you are looking for already built-in to FriCAS but I believe that FriCAS provides excellent tools with which to develop what is missing.
</p><p>
On the other hand I also think that there is something to be said for the strategy of using a system like Sage (See: [AboutSage]) to integrate some specialized and/or efficient implementation of algorithms in other packages. From this point of view FriCAS is just another package. Sage, as a simple dynamically typed object-oriented language based on Python, and the Sage Notebook gui make this quite easy.  But of course you do have to learn both Sage and quite a lot about the packages you intend to use.
</p>

  Rep:=Record(type : NNI,children : List %,parameters: PARAMS)

  Rep==Union(SceneRootNode ,SceneGroupNode, SceneLineNode, SceneMaterialNode, ...

   MyInteger():IntegralDomain == Integer add
     my stuff