>> 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 _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
