[Axiom-math] Re: [Axiom-developer] APL, J, and Axiom documentation

[root]

>> J/APL has advantage of forcing you to think about the solution to
>> a problem in a completely orthogonal way to the usual programming
>> paradigms. In my experience the "re-expression" of an idea in a
>> second, very different form dramatically highlights the design
>> decisions made in the first form. Since the original authors are
>> no longer available we need to tease out the design decisions.
>> 
>> Unfortunately I'm unaware of any category or strongly typed work in J
>> so I don't think the idea carries much weight beyond the numerics. I
>> added a piecewise Gamma function to Axiom in February and have been
>> looking at the special functions since then. J seems to be a good fit
>> in this area, hence the original remark.
>
>Well ... at one time I claimed there were only three "original" 
>programming languages -- Lisp, APL and Forth. So if we call Axiom a 
>"dialect of Lisp", recoding pieces of it in an APL dialect would give us 
>two thirds of the spectrum. Perhaps someone would pick up the third??
>
>But I really think the YAGNI principle needs to be observed here. You 
>Ain't Gonna Need It! :)

Essentially I've been spending a fair amount of time thinking about
Axiom's documentation mechanisms, Axiom's crystal work, and other
design issues. I've read a couple books from the design literature
(and now have joined the dangerously undereducated).

I've been spending time looking at the special functions since
January. One of the insights was that while making the equations
into procedures I was essentially "thinking in APL" (way back in
college I used APL on IBM selectric typeball terminals).

The connection of these two streams led me to look at the idea of
using APL for documentation purposes. Further investigation led me
to J, the ascii version of APL.

While I see the intellectual value of re-thinking by re-coding I'm
not sure J is a worthwhile idea, especially since the J language does
not support Axiom types well. Plus, as Scott points out, it is rather
a "write-only" language so its not clear that it helps anyone but the
person writing the original document.




If we were to re-think by re-coding it would make a lot more sense
to rewrite the algebra into Aldor. We might have the chance to
actually replace some of the existing algebra with the "documented in
Aldor" version. However, this idea comes up once a month and it isn't
going to happen anytime soon. The only possible path I see is the
effort by Gaby to define the "axiom virtual machine". This would 
give us a clean API under the algebra which could then be implemented
in Aldor, providing a new portable base.

Unfortunately my guess is that the axiom virtual machine, if it was
reimplemented in Aldor, would likely invoke Greenspun's Tenth Rule:
"Any sufficiently complicated C or Fortran program contains an ad hoc,
informally-specified, bug-ridden, slow implementation of half of
common lisp." However, if were implemented by cleaning up and
documenting the current version it would not involve that much rework.

One possible idea is to define an API domain which encapsulates the
lisp calls into one domain that exports spad/aldor functionality.
This collects all the lisp interface issues into one domain. I'm
not sure if this is technically possible though since I don't know
what the function signatures would look like. They may have to be
very special purpose signatures.





In any case, documentation ideas are front-and-center in my attention.

The new firefox browser front end is giving us access to a lot of new
tools. The latest task is to try to use JIT, the javascript information
visualization toolkit (see
http://blog.thejit.org/javascript-information-visualization-toolkit-jit)
We can put the algebra hierarchy into these kind of graphs.
Each graph node would be linked to the documentation and sources for
the underlying implementation. 

A recoding of this kind of visualization can give the underlying
skeletal machinery to the facets of the crystal. Each node in the
hyperbolic tree is shown onscreen as a crystal facet. Some details of
interest to work out include the ability to "in place edit" in the
browser facet window (nearly possible now) and have the result
recompile into place (somewhat more complex since this would require
restarting Axiom under the crystal).

If we wrap a crystal around each of the Axiom books 
(http://axiom.axiom-developer.org/axiom-website/documentation.html), 
and put the whole pile into a git-based repository, then each
user could have a complete, personal clone of Axiom. Completed
work could be git-pushed or git-pulled thru a browser "drag-and-drop"
interface.

Architecturally this isn't that far from the possible, which just 
leaves the minor issue of coding :-)

Tim