problems in compiler

[Don Cohen]

--text follows this line--

The version of ap5 from 2009 supposedly was able to build in the abcl
of that time.  I'm now trying to make a more recent ap5 (but not
very much changed) build in current abcl.  I've put the current source
at http://ap5.com/ under ap5-2019.zip so that others who are willing to
help can reproduce the problem.  Unfortunately I don't have a small 
example, only a large one.

If you retrieve and unzip the source, you'll find a file abcl-build.lsp
which I'm trying to get to build ap5.  In order to use it you have to
change this line:
(defvar *top* "/tmp1/ap5-2017/")
to be the directory where you've put the ap5 source subdirectory.
That is, the file /whatever/source/abcl-build.lsp should contain
(defvar *top* "/whatever/")

I then do the following:
java -jar abcl-bin-1.5.0/abcl.jar
then load that file - in my case
(load "/tmp1/ap5-2017/source/abcl-build.lisp")

This ends with the following error:

Error loading /home/tmp1/ap5-2017/bin-abcl1.5.0-MT/relation.fas at line 210 (offset 12978)
#<THREAD "interpreter" {5E5D5718}>: Debugger invoked on condition of type TYPE-ERROR
  The value #(#:A63056 #:G63088 #:A63337 #:A63338 #:A63324 #:A63325 #:G63450 #:G63451 #:A63559 #:A63560 #:A63546 #:A63547 #:G63674 #:G63675 #:A63797 #:A63798 #:G63898 #:G63899 #:A64007 #:A64008 #:G64039 #:G64040 #:A64134 #:G64160 #:G64256 #:G64356 #:G64357 #:G64454 #:A64602 #:G64628 #:WHOLE-65572 #:ENVIRONMENT-65573) is not of type LIST.
Restarts:
  0: TOP-LEVEL Return to top level.
[1] AP5(2): :bt

  0: (SYSTEM:BACKTRACE)
  1: (INVOKE-DEBUGGER #<TYPE-ERROR {16575712}>)
  2: org.armedbear.lisp.Lisp.error(Lisp.java:382)
  3: org.armedbear.lisp.Lisp.type_error(Lisp.java:435)
  4: org.armedbear.lisp.LispObject.car(LispObject.java:161)
  5: org.armedbear.lisp.assql.execute(assql.java:51)
  6: org.armedbear.lisp.Symbol.execute(Symbol.java:814)
  7: org.armedbear.lisp.LispThread.execute(LispThread.java:832)
[1] AP5(3): 


It's difficult for me to figure out what's causing the error since I don't
know much about interpreting java compiler output.
However I hope a little background and some experimental evidence will help.
First, the build process loads certain files before it compiles them and
then later attempts to load the compiled versions.
The error is coming from trying to load the compiled version of the first
of these, relations.lsp.  The build process actually loads and compiles
several files before it tries to load the compiled versions, but in order
to reproduce the error it's enough to load relations.lsp, compile it,
then try to load the compiled version.
In order to figure out which form in the file was causing the problem
I tried a number of initial subsets of the relations.lsp file and found
that if I stop at line 836, after :
(++ reldeleter (relationp 'relation) '(lambda (&rest ignore)
                                        (declare (ignore ignore)) 'deleterel))
I can 
 - load relations.lsp
   (I do this in order to return to a state that does not depend
    on the part of the compiled file that was loaded)
 - compile the initial segment
 - load the compiled version of the initial segment
without error.
However if I add the next form,
(defun deleterel (ignore rel)
  (declare (ignore ignore))
  (loop for a s.t. (relationarity rel a) do (-- relationarity rel a))
  (insist "supposed to delete it" not (relation rel)))

the load of the compiled file generates an error similar to above:
Error loading /tmp/test1.abcl at line 198 (offset 11994)
#<THREAD "interpreter" {2040734F}>: Debugger invoked on condition of type TYPE-ERROR
  The value #(#:G292048) is not of type LIST.

On the other hand, if I put the defun deleterel into a separate file,
I can
 - load relations.lsp
 - compile the initial segment ending with ++ reldeleter
 - load the compiled version of the initial segment
 - compile the file containing defun deleterel
 - load that file
without error.

The fact that the error from this test contains what appears to be a vector
of only one object whereas the original contains a longer vector suggests to
me that the compiler is combining multiple forms into a vector, and the
defun deleterel is just the first one.  Of course that doesn't explain
why some other code expects a list instead of a vector.
I'm hoping that someone will know immediately what causes the error
I'm seeing and what I can do to avoid it.


This reminded me of something -- you might notice in the file relations.lsp
and other files the following incantation:
(buffer-break)
which is defined in sys-depe.lsp:

; The purpose of buffer-break is to prevent compile-file from
; putting two forms together when the first one has to be evaluated
; before the second can successfully read, e.g., if the first defines
; relation R and the second contains something like #,(relationp R).

#+(or lispworks (and lucid sparc))
(defmacro buffer-break ()
  '(eval-when (:load-toplevel :execute) nil))

#-(or lispworks (and lucid sparc))
(defmacro buffer-break () nil)

If I change the first of those forms to 
#+(or abcl lispworks (and lucid sparc))
I still get the same error at the same place, but I wonder whether the
underlying problem is similar to the one that caused buffer-break to be
invented.