[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] Recent ansi fixes

From: Paul F. Dietz
Subject: Re: [Gcl-devel] Recent ansi fixes
Date: Thu, 23 Oct 2003 20:33:07 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624

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

    (EVAL '(DEFSTRUCT #0=#:STRUCT-TEST-31 A31 B31))
                (FUNCTIONP #'MAKE-STRUCT-TEST-31)
                (TYPEP (MAKE-STRUCT-TEST-31) '#0#) T)
           (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))))

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:

        (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

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

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!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]