[Gcl-devel] Recent ansi fixes

[Camm Maguire]

Greetings!  Just made a large commit to CVS head bringing the ansi
test failure rate to 3.5% (508).  A few questions:

1) Paul, what's the status on the random compiler tests?

2) struct-test-31 uses an uninterned symbol as the name for the
   structure -- unless one keeps a binding to this value, subsequent
   references to #:struct-test-31 will not refer to the same symbol
   with a plist loaded with the structure info.  Shouldn't this test
   do a (let ((sym '#:struct-test-31)) ...?  CMU fails here too.

3) In GCL, 'the triggers an error when the object cannot be coerced to
   the appropriate type, which is allowed but not mandated by the
   spec.  Several struct tests are bailing when the struct predicate
   is doing a (the (vector t) ...) on a string (in *universe*).  This
   should be ok, no? (STRUCT-TEST-41/3, STRUCT-TEST-43/3)

4) Certain defgeneric-method-combination errors persist, identically
   with CMUCL:

(PROGN
        (EVAL '(DEFGENERIC DG-MC.+.11 (X)
                 (:METHOD-COMBINATION +)
                 (:METHOD NONSENSE ((X T)) 0)))
        (HANDLER-CASE (DG-MC.+.11 0) (ERROR NIL :ERROR)))

   defgeneric spec says:

...

   The lambda list of each method specified by a method-description
must be congruent with the lambda list specified by the gf-lambda-list
option, or an error of type error is signaled.

   If a defgeneric form is evaluated and some methods for that generic
function have lambda lists that are not congruent with that given in
the defgeneric form, an error of type error is signaled.

...

   Shouldn't this mean that the eval triggers an error and the test
   fails?

5) the.12 ...  cl-test::*mini-universe* looks like this:

(0 #\Space "" (A B)
 #<ARITHMETIC-ERROR.0> #<"COMMON-LISP" package>
 #(NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL) #<hash-table 089fb5b0>
 #p"foo" #<input stream "universe.lsp"> #<readtable 084d9f78>
 #S(FOO-STRUCTURE X 1 Y A Z NIL) #<compiled-function CONS>
 #$-1565181898 NIL 1.2S0 1.3 1.5 1.8 3/5 10000000000000000000000)

   sharp less than spec says:

...

   #< is not valid reader syntax.  The Lisp reader will signal an error

   of type reader-error

   on encountering #<.  This syntax is typically used in the printed
representation of objects that cannot be read back in.

...

   the.12 et.al tries to run an (eqlt ... (the ... ...)) on this, but
   the #< symbols cannot pass through the reader and trigger an
   error.  Oddly enough, this seems to pass when interpreted, but has
   exposed a compiler bug in that the compiler fails to report this as
   a reader error and generated bad results instead.  Enlightenment
   please? 

6) Someone please tell me that this work will make their lieves better
   -- I'm in need of a little motivation!

Take care,

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah