gcl-devel
[Top][All Lists]
Advanced

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

Re: [Gcl-devel] (ANSI) Added some string-related tests


From: Camm Maguire
Subject: Re: [Gcl-devel] (ANSI) Added some string-related tests
Date: 03 Oct 2002 01:22:38 -0400

Greetings, and thanks for the summary!

I'm committing some fixes.  Comments below.

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

> Comments on the tests:
> 
>  > MAP-STRING.31, MAP-STRING.32,
> 
> MAP where the type argument is of the form (simple-array character ???).
> 

Done to my knowledge.

> > STRUCTURE-1-13,
> 
> CLASS-OF is called on a structure object (this should be legal since
> every structure type is also a class.)
> 
>  > STRUCTURE-1-14,
> 
> Structures should be elements of the type STRUCTURE-OBJECT.
> 
> >    STRUCTURE-1-15
> 
> Structure types should be subtypes of STRUCTURE-OBJECT.
> 

These appear to require modifying the pcl code, and have not yet been addessed. 

> > BOOLEAN-TYPE-1, BOOLEAN-TYPE-2, BOOLEAN-TYPE-3
> 
> NIL and T should be in the type BOOLEAN, but they are not.
> 

Done to my knowledge.

> >    TYPES-3,
> 
> The spec specifiers a large number of subtypep relationships between
> builtin type symbols.  This test checks them, returning the number that
> aren't correct.  It should return 0, but there are 56 pairs that
> fail.
> 
> > TYPES-5
> 
> SIMPLE-BASE-STRING should be a subtype of SEQUENCE.  It's not.
> 
> > TYPES-6,
> 
> Checks that primitive type symbols in CL that are not SEQUENCE, CONS, LIST, 
> or T
> are subtypes of ATOM (ATOM, please recall, is everything that isn't a CONS.)
> 
> The spec says that SUBTYPEP must succeed if its two arguments are builtin type
> symbols, btw.  Allegro CL gets this very wrong; last I checked CMU CL did as
> well.
> 
> > TYPES-8,
> 
> Similar to TYPES-6.
> 
> > TYPES-9
> 
> Checks SUBTYPEP for transititivity on the builtin type symbols.
> 
> > TYPES-9A, 
> 
> Checks that TYPEP is consistent with SUBTYPEP on a large collection
> of builtin type symbols and a universe of various kinds of lisp values.
> 

These appear to require modifying the pcl code, and have not yet been addessed. 

I can and have made changes to gcl's native subtypep.  I've added
symbols for all the missing atoms in analogous fashion to the existing
ones.  And in the saved_gcl image, I can get these subtypes right, for
instance generic-function/function.  But in the saved_ansi_image, this
relationship is overwritten, and I don't yet understand how.  In
pcl/defs.lisp, there is a *subtypep defined which seems to be wresting
some control away.  As pcl is supposed to be standard and portable,
I'd feel more comfortable if I could get some advice from someone
experienced before proceeding. 

> >    READ-SYMBOL-8
> 
> is a bad test.  I will remove it.
> 

Thanks!

>  > READ-SYMBOL-10,
> 
> Lack of support for the :READABLY keyword in WRITE.
> 

Done to my knowledge.  Haven't yet tested the effects of :readably
though. 

> > CHAR.3, CHAR.4,
> 
> Tests were busted; fixed.
> 

Thanks!

> > CHAR.6, CHAR.7, 
> 
> MAKE-STRING should take an :ELEMENT-TYPE keyword argument; it doesn't.
> 

Fixed, but perhaps more work is needed here.  The way I read the spec,
one can define character == base-char == standard-char.  I don't think
we're at the point yet of supporting extended characters, so I'd like
to do this if possible, at least for now.   So my understanding is
that with this definition, the :element-type keyword can be ignored.
I mean other than checking that its some sort of character and
complaining otherwise (which I haven't done yet).  The internal C
representation of a string has no field (yet) to hold an element-type,
though this could be added if really necessary.


> >    CHAR.8
> 
> Test was busted; fixed but still fails.  This is a subtle point: CHAR must
> ignore the fill-pointer in an array that has one (see the spec page for CHAR).
> 

Fixed the char ignoring fill-pointer part, but test still fails due to
setf.  Perhaps should be rewritten?

> > CHAR.9, CHAR.10, SCHAR.4, SCHAR.5, SCHAR.6, SCHAR.7,
> 
> MAKE-STRING needs to take :ELEMENT-TYPE.
> 

Done as above.

> >    STRING.7, 
> 
> The function STRING must always either return a string *or* signal
> a type-error (at safe calls).
> 

Not done yet.

> > BASE-STRING.1,  BASE-STRING.2, BASE-STRING.3, BASE-STRING.4,
> 
> BASE-STRING should be a subtype of STRING, VECTOR, ARRAY, and SEQUENCE.
> 
> > SIMPLE-STRING.5
> 
> SIMPLE-STRING should be a subtype of SEQUENCE.
> 
>  > SIMPLE-BASE-STRING.1, SIMPLE-BASE-STRING.2, SIMPLE-BASE-STRING.3, 
> SIMPLE-BASE-STRING.4,
> >    SIMPLE-BASE-STRING.5, SIMPLE-BASE-STRING.6, SIMPLE-BASE-STRING.7,
> 
> SIMPLE-BASE-STRING should be a subtype of string, simple-string, base-string, 
> vector,
> simple-vector, simple-array, array, and sequence.
> 
> 
> >  SIMPLE-STRING-P.5, STRINGP.4
> 
> (MAKE-ARRAY 4 :ELEMENT-TYPE 'BASE-CHAR ...) is not being recognized as a 
> simple string
> or a string.
> 

These are pending my understanding of how to control *all* the types
as described above.

So now I get:

26 out of 2594 total tests failed: STRUCTURE-1-13, STRUCTURE-1-14, 
STRUCTURE-1-15, TYPES-3, TYPES-5, 
   TYPES-6, TYPES-8, TYPES-9, TYPES-9A, CHAR.8, STRING.7, 
   BASE-STRING.1, BASE-STRING.2, BASE-STRING.3, BASE-STRING.4, 
   SIMPLE-STRING.5, SIMPLE-BASE-STRING.1, SIMPLE-BASE-STRING.2, 
   SIMPLE-BASE-STRING.3, SIMPLE-BASE-STRING.4, SIMPLE-BASE-STRING.5, 
   SIMPLE-BASE-STRING.6, SIMPLE-BASE-STRING.7, SIMPLE-BASE-STRING.8, 
   SIMPLE-STRING-P.5, STRINGP.4.


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]