gcl-devel
[Top][All Lists]
Advanced

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

Re: [Gcl-devel] Feedback on ANSI bugfixes


From: Camm Maguire
Subject: Re: [Gcl-devel] Feedback on ANSI bugfixes
Date: 23 Aug 2002 00:44:57 -0400

Greetings!

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

> I *really* should put the partial test suite I'm using up for
> ftp, so you can run it yourself.  I'll do that in
> a day or so; the glue files need to be tweaked to work around
> ANSI CL lacks in gcl.  A comprehensive test suite will be utterly
> essential to upgrading gcl (for conformance or performance).
> 
> Anyway... here are some problems.
> 
> 
> (let* ((n "abcde") (x (list* 'a 'b 'c n))) (ldiff x (copy-seq n)))
>   ===> (A B C)
> Since (not (eql n (copy-seq n))), it should have returned
> (A B C . "abcde").
> 
> 

Should be fixed in pending commit.

> (TAILP 10203040506070 (LIST* 'CL-TEST::A 'CL-TEST::B
>                                   (1- 10203040506071)))
>   ==> NIL
> when it should be true (the arithmetic in this test prevents
> an aggressive readed from making the two numbers EQ.)
> 

I don't quite get this 'aggressive reader' bit.  Clearly the two items
aren't eq?  If not, what makes them so, and where does one draw the
line?  I.e. one could nest arbitrarily deeply, no?

> 
> (member-if #'listp 1)
>    ==> 1
> when it should signal a type error.
> 
> (member-if-not #'listp 1)
>    ==> 1
> when it should signal a type error.
> 
> 
> (maplist #'identity 'a)
>    ==> NIL
> when it should signal a type error.
> 

Fixed in pending commit.

> 
> (assoc-if #'evenp '((1 . a) nil (3 . b) (6 . c) (7 . d)))
>    ==> infinite loop
> (and also for similar cases for assoc-if-not, rassoc-if, and
>  rassoc-if-not).
> 
> (assoc-if #'null '((a . b) nil (c . d) (nil . e) (f . g)))
>    ==> infinite loop
> (ditto for the other three functions.)
> 

Fixed before.

> 
> This is the test case for the set-exclusive-or problem.
> I've had arguments with other Lisp implementors as to
> whether the standard really calls for this behavior.
> IIRC, CMUCL does not enforce this ordering constraint.
> 
> (let ((list1 '(a b c d))
>         (list2 '(e f g h)))
>       (block fail
>             (set-exclusive-or
>              list1 list2
>              :test #'(lambda (s1 s2)
>                        (when (or (member s1 list2)
>                                  (member s2 list1))
>                          (return-from fail 'failed))))))
>    ==> failed
> when it should return some permutation of (a b c d e f g h).
> 

OK, I'll try to investigate this.  Is this part of the standard tests?
If not, why do you need this?

Take care,

> 
>       Paul Dietz
>       address@hidden
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
> 
> 

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