On Thu, Aug 12, 2010 at 3:16 AM, Martin Baker wrote: > > It would help if someone (hopefully someone with a better knowledge > of Lisp than me) were to port to a JVM language like this and then > the SPAD language were modified slightly so that native JVM > libraries could be called from SPAD. >
My personal opinion is that this is probably impractical. Of course in principal it might be possible to replace the current SPAD run-time environment with JVM but the current design of SPAD is decidedly not modular. Something that does Lisp to JVM would just add another layer of complexity to the stack without much gain. Calling native JVM libraries would require solving the problem of converting from and to AXIOM data types to Java data structures. Doing this in a efficient and sufficiently general way at the JVM level is likely to be rather difficult. I know that the Axiom sister project OpenAxiom has made some progress towards improving this situation but my understanding is that there is still a long way to go. Perhaps a better choice would be to depend on the foreign function interface (CFFI) that is available in many of the Lisps on which AXIOM can run. Through CFFI would could call JNI functions - still a lot of work though. > Let me give an example of where this would help: I have written an > alternative geometry/graphics framework based on a scenegraph written > in SPAD, this has all the same draw/plot features as the existing > framework but with much more powerful transforms and so on. In some > ways I'm quite pleased with it, it exports to SVG, X3D, VRML & OBJ. > However the point is that, if I had access to JVM libraries such as an > OpenGL canvas, ability to read XML, and things like this I could make > it much more powerful, the user could interact with the program. > Without these things I am stuck and I can't see a way to develop it > further. > There is an XML library for Aldor that could (again, in principle) be back ported to SPAD. There is an OpenGL binding for lisp that I know nothing more about: http://common-lisp.net/project/cl-opengl/ http://repo.or.cz/w/cl-glfw.git > The other issue with programming in SPAD is that I find it extremely > frustrating. I am not doubting its power, or the work that has gone > into it over the years but the lack of helpful error messages and so > on make it very hard to work with. Every time I hit a hard to find bug > in my SPAD code I vow to stop using this language but I come back > to it in the end. Moving the Lisp code to ABCL would not immediately > fix that (I guess it could even add some bugs of its own) but would > it give a path to an environment that is easier to program in? Can > you see how this could be done in simple steps without requiring > a massive programming effort? > The simple answer, I think, is "no". But of course there are things you can do to make you life easier ... For example, you can do most of your initial code development using Aldor which in general has much more helpful error messages and then back port it to SPAD if you are concerned about the Aldor license issue. The Sage and Sympy projects both argued that there is a great deal of merit in choosing a mainstream language in which to develop a computer algebra system. In spite of their relative success compared to Axiom I still think that choosing Python as this language is too much of a compromise. Perhaps Scala is a suitable middle ground. Still, translating a large and sufficiently interesting part of the Axiom library to Scala seems likely to be a major effort - probably much more effort than using CFFI. So at this stage I am most just curious about the suitability of the language Scala itself as an alternative to SPAD and Aldor. I want to understand how it's object-orientation differs from Axiom and it's facilities for generic programming and abstract data types compares to Axiom categories and domains. Regards, Bill Page. -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en.
