gcl-devel
[Top][All Lists]
Advanced

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

Re: [Gcl-devel] Ansi compliance issues


From: Camm Maguire
Subject: Re: [Gcl-devel] Ansi compliance issues
Date: 09 Aug 2002 02:02:52 -0400

Greetings!

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

> I'm running some tests on gcl configured with --enable-ansi.
> I've found some compliance issues (I imagine there are many).
> 

Thank you for running these tests, and providing these detailed and
useful reports!

> (1) EVAL-WHEN doesn't take :EXECUTE, :COMPILE-TOPLEVEL or
>   :LOAD-TOPLEVEL as situations.
> 
> (2) GENSYM is broken: it doesn't use the *GENSYM-COUNTER*
>   special variable (and that symbol is not exported from
>   COMMON-LISP).  Calling GENSYM with a string argument permanently
>   replaces the prefix with that string (the standard says it
>   replaces it for this call only.)  Calling GENSYM with an integer
>   resets the global counter, which is incorrect.
> 
> (3) There are too many symbols exported from COMMON-LISP (994 instead
>   of the mandated 978 symbols.)
> 
> (4) MAKE-HASH-TABLE doesn't take EQUALP as the test function.
> 
> (5) ROW-MAJOR-AREF is not defined.
> 
> (6) ELT should (in safe code) produce a TYPE-ERROR when the index is
>   out of range.  It produces an INTERNAL-SIMPLE-ERROR instead.
> 

All of these appear at first sight to be straightforward, in slightly
varying degrees.  Before launching into fixes, though, I think we need
to address three issues:

1) What is our policy going to be if we break backward compatibility?
   Protect the new code with #defines indicating an ansi build?
   Ensure that a few key large projects are not broken (e.g. maxima)
   and then go ahead?

2) What is our policy going to be regarding lisp and c
   implementations?  My preference is to keep the c core as small as
   possible, and therefore to implement as much in lisp as we can.
   Can some knowledgeable lisp person comment on which of these
   missing features can be implemented at the lisp level, even if they
   are currently in C?  4 & 5 for example seem to be necessarily C.

3) Where do we put this work on the priority list leading to 2.5.0?

In general, in addition to the wonderfully detailed reports as
exampled above, I'd like bug reports like this to also indicate
whether the feature can be implemented in lisp, and whether
implementing the feature will necessarily break backward
compatibility.



Take care,  


> I'll send in more issues as they come up.
> 
>       Paul
> 
> _______________________________________________
> 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]