Re: [Axiom-developer] depsys and SBCL

[Gabriel Dos Reis]

Gregory Vanuxem <address@hidden> writes:

| Le mardi 27 mars 2007 à 11:05 -0500, Gabriel Dos Reis a écrit : 
| > Hello,
| > 
| >   In my local tree, I was able to eventually twist Axiom to get it
| > compilable by SBCL.  During that process, I unconvered various dubious
| > practices in the current system (mainly between vmlisp.lisp and
| > macro.lisp).  SBCL will accept to compile depsys only if I tell it to
| > ignore many redefinitions of Common Lisp symbols (I'll discuss that in
| > a separate message).
| > 
| >   CLISP almost compiles SBCL -- it errors out on def.lisp saying
| > that there is an illegal character #\Stx in the source file -- I have
| > no idea of what that means.  If I omit def.lisp, the depsys
| > compiles fine -- 
| 
| Hmm... I forgot to add this issue to my TODO list. I temporary followed
| how GCL behaves i.e omit it. I was/am pretty sure this is incorrect but
| as far as I know this part of code is not used. I just commented out
| this function. ^L is also used at several places.


Hi Greg,

   Thanks for sharing your thoughts on this.

| >I have not tried the resulting translator however.
| 
| Did you modify the "funcalled symbols" FUNCALL('FOO) -> FUNCALL(function
| (foo)) as done by Juergen Weiss ? I based my work on his work and this
| version does not contain all the src/interp file that we can find in
| Gold. Adding a new file is always difficult because of this issue (that
| must be done carefully).

I did not get into that issue -- and where can I find Juergen Weiss' work?

| > This is just a head up.  If you know anything about the illegal
| > character \#Stx, please let me know.
| 
| No idea.

OK.

| > Ah, one more thing: Currently, there is this dubious definition in
| > foam_l.lisp: 
| > 
| >    #+:AKCL
| >    (deftype |DFlo| () t)
| >    #-:AKCL
| >    (deftype |DFlo| () 'long-float)
| > 
| > followed by
| > 
| >    (defconstant |DFloInit| (the |DFlo| 0.0d0))
| > 
| > which is an error because 0.0d0 is not long-float -- rather a double-float.
| > 
| > Looking more at this, I think the |DFlo| should not be conditional.
| 
| I don't know why the Aldor implementers used the t type to define DFlo
| on AKCL and since we do not have access to the Aldor source code it's
| difficult to know why. There are other issues in this file, for example
| it _seems_ that the SInt type has to be a 32 bits integer (on a 32bit
| arch) but they defined it to be a fixnum. This is clearly wrong on CMUCL
| and Clisp (and probably other), their fixnums are 29 bits integers if I
| remember correctly (and if log2 MOST-POSITIVE-FIXNUM really represents
| that). For other issues you can look at the tarball that I uploaded [1].

Please, could you point me (again!) to your tarball?  My memory is
volatile and I cannot find a record in my mailbox.  Sorry about that.

| A quick note here, the last (beta) version of Aldor comes without an
| indispensable file, runtime.lsp [2]. I hope they will continue to
| support the lisp backend though I rarely use it.

I have not installed Aldor on my machine.

| > Furthermore, I think we should use double-float instead of long-float
| > -- it fits more in most modern FPU and its underyling representation
| > is more widely uniform.
| > This is a change for people connecting Axiom to Aldor through FOAM.
| 
| I totally agree, this should be done everywhere (in the algebra too:
| DFLOAT.spad). From what I know the Lisp double-float type is generally a
| hardware float (see for example
| http://www.cs.berkeley.edu/~mhoemmen/matlisp/floating-point.html). But
| this is not the case for long-float on Clisp (arbitrary precision). We
| might add a new type that represent hardware float.

OK.  Thanks for your feedback.

-- Gaby