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: Vadim V. Zhytnikov
Subject: Re: [Gcl-devel] Ansi compliance issues
Date: Fri, 09 Aug 2002 18:57:52 +0300
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru-RU; rv:1.0.0) Gecko/20020526

Camm Maguire пишет:
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?


What about enabling incompatible with old GCL features if and only if
--enable-ansi is on?  In this case we can ensure smooth transition
for projects which relies on GCL. On the other hand some new functionality can be added to old style --disable-ansi GCL build
as long as this new features break nothing.  For example new
functions like ROW-MAJOR-AREF etc can be safely added to
both old and new GCL.  But if we are going to alter some
behavior (like pathname-directory which gives :root on old
GCL but must give :absolute and :relative according to ansi standard)
then this new behavior should be activated only by --enable-ansi
and corresponding #ifdef etc.

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

You are right.  We should avoid C programming as much as possible.
I'm not sure about (5) but (4) is certainly C and (6) is both C and
Lisp in many places.


3) Where do we put this work on the priority list leading to 2.5.0?
>
I think that reasonable level of ANSI compatibility is too distant
goal to make it very high priority.  I mean that new release 2.5.0
should not be delayed by ANSI compliance problems.


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







--
     Vadim V. Zhytnikov

      <address@hidden>
     <address@hidden>
     <address@hidden>
    <address@hidden>








reply via email to

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