gcl-devel
[Top][All Lists]
Advanced

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

Re: [Gcl-devel] Recent ansi fixes


From: Camm Maguire
Subject: Re: [Gcl-devel] Recent ansi fixes
Date: 23 Oct 2003 23:15:18 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings, and thanks as always!

"Paul F. Dietz" <address@hidden> writes:

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

OK, wll investigate.  Good to see that we're actually approaching
cmucl cvs head in some respects :-).

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

Right, strings are not (vector t), so the 'the can trigger an error
legitimately, right?  This is causing the struct-test-41/3 and
struct-test-43/3 failures.  CMUCL appears to get around this by having
'the never trigger an error, which is also permissible, but seemingly
less desirable, at least IMHO.

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

OK, thanks for clarifying the terms...

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

Does this mean I can make up my own pseudo syntax, maybe using
#something-not-in-use, and instruct the reader to parse this
appropriately? Which compile bugs are you referring to below? 

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

And thank you!

Take care,

>       Paul
> 
> 
> 
> 

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




reply via email to

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