Hello,
as you may know, Maxima is a computer algebra system written in
Common Lisp, and ABCL is a CL implementation written in Java.
I was thinking that recompiling Maxima with ABCL could open some
new possibilities (e.g. Maxima on handheld devices which run Java)
so I gave it a try.
In summary I was pleasantly surprised by how well it worked.
Unfortunately it doesn't work well enough to say that Maxima
has been ported to ABCL. It is a pretty new implementation so
as it matures it would be reasonable to try again.
Some sketchy notes:
compiling problems: ABCL compile-file doesn't seem to like setq with
multiple arguments. I worked around that by changing (setq a b c d)
to (setq a b) (setq c d). Also ABCL didn't recognize #\vt (vertical
tab).
I don't know if #\vt is a non-CL thing. Those were the only compiling
problems iirc.
I couldn't get mk-defsystem 3.4 to work with ABCL so I just used
(mk:files-in-system "maxima") (in Clisp) to get a list of the files in
load order, and then executed compile-file and load (more or less)
on each one.
run time problems: It seems like the Maxima function ev (explicit
evaluation) is messed up. That's less of a problem than you might
think, because ev is actually not called very often.
Also Maxima on ABCL is pretty slow; slower than Clisp,
and much slower than GCL. That may be not much of an
issue if the question is to have Maxima or not have it at all.
stuff that does work: Console i/o (including the ascii art pretty
printer) and file input seems to mostly work OK.
Maxima functions seem to mostly work OK although
errors are reported in the test suite (several errors in each
of the 3 or 4 test scripts I tried).
Anyway it was an interesting experience and I hope that
this inspires someone to iron out the bugs.
It might be worth considering to reorganize Maxima so that
it is possible to pick and choose the bits of functionality
(e.g. repl stuff + arithmetic + polynomials & omit the rest).
Robert Dodier
Robert Dodier <·············@gmail.com> wrote:
+---------------
| compiling problems: ABCL compile-file doesn't seem to like setq with
| multiple arguments. I worked around that by changing (setq a b c d)
| to (setq a b) (setq c d).
+---------------
You should file an ANSI-non-compliance bug with the maintainers.
+---------------
| Also ABCL didn't recognize #\vt (vertical tab).
| I don't know if #\vt is a non-CL thing.
+---------------
It's an extension to ANSI, but most CLs do recognize it (CLISP,
CMUCL, etc.). CLHS 13.1.7 "Character Names" says that the only
*required* named characters are #\Newline" and #\Space, with
#\Rubout, #\Page, #\Tab, #\Backspace, #\Return, & #\Linefeed
being:
...semi-standard; if an implementation supports them,
they should be used for the described characters and
no others.
And CLHS 22.1.3.2 "Printing Characters":
If a non-graphic character has a standardized name[5], that name
is preferred over non-standard names for printing in #\ notation.
For the graphic standard characters, the character itself is
always used for printing in #\ notation---even if the character
also has a name[5].
Finally, CLHS "Glossary: N: name[5]" says:
... (All non-graphic characters are required to have names unless they
have some implementation-defined attribute which is not null. Whether
or not other characters have names is implementation-dependent.)
But except for the standardized and semi-standard names above, those
names might be different in different implementations. For example,
in (an old version of) CLISP:
> (loop for i to 32 collect (code-char i))
(#\Null #\Soh #\Stx #\Etx #\Eot #\Enq #\Ack #\Bell #\Backspace
#\Tab #\Newline #\Vt #\Page #\Return #\So #\Si #\Dle #\Dc1
#\Dc2 #\Dc3 #\Dc4 #\Nak #\Syn #\Etb #\Can #\Em #\Sub #\Escape
#\Fs #\Gs #\Rs #\Us #\Space)
>
Whereas in CMUCL:
> (loop for i to 32 collect (code-char i))
(#\Null #\^A #\^B #\^C #\^D #\^E #\^F #\Bell #\Backspace #\Tab
#\Newline #\Vt #\Page #\Return #\^N #\^O #\^P #\^Q #\^R #\^S #\^T
#\^U #\^V #\^W #\^X #\^Y #\^Z #\Escape #\Fs #\Gs #\Rs #\Us #\ )
>
[Hmmm... Since (graphic-char-p #\space) ==> T in both, by 22.1.3.2
it would seem that CMUCL is more correct in printing space as "#\ "
instead of "#\Space". Oh, well...]
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) writes:
> Robert Dodier <·············@gmail.com> wrote:
> +---------------
> | compiling problems: ABCL compile-file doesn't seem to like setq with
> | multiple arguments. I worked around that by changing (setq a b c d)
> | to (setq a b) (setq c d).
> +---------------
>
> You should file an ANSI-non-compliance bug with the maintainers.
>
> +---------------
> | Also ABCL didn't recognize #\vt (vertical tab).
> | I don't know if #\vt is a non-CL thing.
> +---------------
>
> It's an extension to ANSI, but most CLs do recognize it (CLISP,
> CMUCL, etc.). CLHS 13.1.7 "Character Names" says that the only
> *required* named characters are #\Newline" and #\Space, with
> #\Rubout, #\Page, #\Tab, #\Backspace, #\Return, & #\Linefeed
> being:
>
> ...semi-standard; if an implementation supports them,
> they should be used for the described characters and
> no others.
There's always this distinction people don't like to do (I don't know
why) between characters and codes.
I don't consider VT to be a character.
VT is the name given in ASCII to the ASCII code 11, which may be
interpreted by some device, or in some protocol, in some specific way.
For example, in ECMA-048 (ISO-6429), VT (code 11) is interpreted as
"LINE TABULATION":
VT causes the active presentation position to be moved in the
presentation component to the corresponding character position on the
line at which the following line tabulation stop is set.
Does this look like a character?
Therefore, I've got an ECMA-048 package that defines a function named
VT to output a _byte_ sequence causing the active presentation
position to be moved in the presentation component to the
corresponding character position on the line at which the following
line tabulation stop is set, but no such "VT" character.
Anything else, like (code-char 11), is just a hack.
--
__Pascal Bourguignon__ http://www.informatimago.com/
The mighty hunter
Returns with gifts of plump birds,
Your foot just squashed one.
"Robert Dodier" <·············@gmail.com> writes:
> Hello,
>
> as you may know, Maxima is a computer algebra system written in
> Common Lisp, and ABCL is a CL implementation written in Java.
> I was thinking that recompiling Maxima with ABCL could open some
> new possibilities (e.g. Maxima on handheld devices which run Java)
> so I gave it a try.
>
> In summary I was pleasantly surprised by how well it worked.
> Unfortunately it doesn't work well enough to say that Maxima
> has been ported to ABCL. It is a pretty new implementation so
> as it matures it would be reasonable to try again.
Congratulations! Perhaps you could get your half-done port into the
Maxima sources, so that the next time someone decides to give it a
try, he won't have to start from scratch.
>
> Some sketchy notes:
>
> compiling problems: ABCL compile-file doesn't seem to like setq with
> multiple arguments. I worked around that by changing (setq a b c d)
> to (setq a b) (setq c d). Also ABCL didn't recognize #\vt (vertical
> tab).
Are you using the cvs version of abcl?
[·····@localhost ~]$ cat /tmp/setq.lisp
(in-package :cl-user)
(defun foo ()
(let ((b 1)
(d 2)
a c)
(setq a b c d)
(format t "~&a=~d, c=~d~%" a c)))
(foo)
[·····@localhost ~]$ abcl
Armed Bear Common Lisp 0.0.9.1+ (built Fri Jun 9 2006 11:14:09 --100)
Java 1.5.0_05 Sun Microsystems Inc.
Java HotSpot(TM) Client VM
Control-C handler installed.
Low-level initialization completed in 5.792 seconds.
Startup completed in 19.553 seconds.
Type ":help" for a list of available commands.
CL-USER(1): :cl /tmp/setq.lisp
; Compiling /tmp/setq.lisp ...
; (IN-PACKAGE :CL-USER)
; (DEFUN FOO ...)
; Wrote /tmp/setq.abcl (0.787 seconds)
a=1, c=2
CL-USER(2):
This doesn't prove anything, but still...
Anyway, a bug report to the armedbear-j-devel list never hurts.
Andras