Re: [Gcl-devel] Recent ansi fixes

[Paul F. Dietz]

Camm Maguire wrote:
> 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?

I'll run them tonight and see what happens (on the new build.)

> 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.

The macro defstruct-with-tests uses the uninterned symbol #:struct-test-31;
it doesn't copy it.  Remember, macro expansion in lisp works on lisp
data, not text, so the #:struct-test-31 that occurs throughout the expanded
form will be the same.  This can be seen by doing macroexpand and printing
with *print-circle* bound to true:

CL-TEST>(let ((*print-circle* t))
    (print (macroexpand '(defstruct-with-tests #:struct-test-31 a31 b31)))
    nil)

(EVAL-WHEN (:LOAD-TOPLEVEL :COMPILE-TOPLEVEL :EXECUTE)
  (REPORT-AND-IGNORE-ERRORS
    (EVAL '(DEFSTRUCT #0=#:STRUCT-TEST-31 A31 B31))
    (PUSHNEW '#0# *DEFSTRUCT-WITH-TESTS-NAMES*)
    NIL)
  (DEFTEST STRUCT-TEST-31/1
           (AND (FBOUNDP 'MAKE-STRUCT-TEST-31)
                (FUNCTIONP #'MAKE-STRUCT-TEST-31)
                (SYMBOL-FUNCTION 'MAKE-STRUCT-TEST-31)
                (TYPEP (MAKE-STRUCT-TEST-31) '#0#) T)
           T)
  (DEFTEST STRUCT-TEST-31/2
           (LET ((S (MAKE-STRUCT-TEST-31)))
             (AND (FBOUNDP 'STRUCT-TEST-31-P)
                  (FUNCTIONP #'STRUCT-TEST-31-P)
                  (SYMBOL-FUNCTION 'STRUCT-TEST-31-P)
                  (NOTNOT (FUNCALL #'STRUCT-TEST-31-P S))
                  (NOTNOT-MV (STRUCT-TEST-31-P S))))
           T)
...

The error is likely due to the implicit assumption in the implementation
that the name is in a package.  This passes in cmucl (cvs HEAD).

> 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)

Strings are not elements of (vector t).  (vector t) is the type of vectors
that are allowed to hold anything.  Strings are specialized vectors that
can only hold characters (or some subtype of character).

Remember the difference between (vector *) and (vector t).


> 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?

No.  The lambda lists are congruent (one variable).  The method combination
specifier is not part of the lambda list.

This test passes in cmucl (cvs HEAD).



> 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? 


gcl apparently has to print things when compiling, which means it
inappropriately rejects unprintable objects in literal constants.

What you need to do, I think, is print some object that is a pointer
back to the address of the unprintable object in the lisp's memory.
When the reader reads this, it should be converted back to a reference
to that object.  LOAD-TIME-VALUE might be useful here?

This mechanism can also be used to solve the COMPILE bugs where structure
sharing is being broken.


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


Hey, I think it's worthwhile!  Thanks!

        Paul