Re: api differences between 1.4 and 1.6

[Neil Jerram]

>>>>> "Dirk" == Dirk Herrmann <address@hidden> writes:

    Dirk> On 8 Mar 2002, Neil Jerram wrote:
    >> How about using the SCM_API macro as a way of being more specific
    >> about what is in the API?  In practice, this would initially mean
    >> _removing_ SCM_API from a lot of stuff that has it but shouldn't.

    Dirk> There's a problem with this idea: You can't use SCM_API for
    Dirk> macros, even if they belong to the API.

Yes, good point.  This rather messes up my scm_tc16_keyword example,
as well: scm_tc16_keyword must be exported from the Guile library (or
DLL) even if we decide not to consider it as part of the API;
otherwise the SCM_KEYWORDP macro won't compile.

So we cannot use the same marker to mean both `this is part of the
API' and `export from library/DLL'.

    Dirk> The reason is, that SCM_API has been introduced only for the
    Dirk> sake of windows DLLs, and with respect to that the macro is
    Dirk> quite inaccurately named.  My opinion is, that this change
    Dirk> was a bad idea from the beginning: There are other
    Dirk> alternatives to document the information that is necessary
    Dirk> for windows DLLs, which don't have an influence on other
    Dirk> code.  See the mail to guile-devel titled "Re: proposal:
    Dirk> scm_string2str() and scm_symbol2str()" from Ken Raeburn,
    Dirk> sent on 30 Nov 2001.

I'll take a look when I'm next online.  SCM_API is only in 1.7.x, so
we have plenty of time to reconsider it.

    Dirk> However, for guile we have already defined a mechanism to
    Dirk> distinguish between definitions that belong to the API and
    Dirk> definitions that don't: The prefixes SCM_I_... and
    Dirk> scm_i_... indicate internal definitions in header files.

Sorry, I forgot that we had agreed this.

    Dirk> We have, up to now, not begun to change all the definitions
    Dirk> accordingly.  From time to time, some definitions are
    Dirk> renamed that way.  If we did it consequently (like, in a
    Dirk> cleanup session), we would even find that in many of the
    Dirk> cases it would be sufficient to remove the definitions from
    Dirk> the headers and use static definitions in the corresponsing
    Dirk> c files instead.  The biggest part of the work is to search
    Dirk> through all definitions in the header files and decide,
    Dirk> which of the definitions should be part of the API and which
    Dirk> shouldn't.

Right.  I agree that this is the way to go, and I think we could do
this cleanup even during 1.5/1.6, since the things that will change
are, by definition, internal.

Marius - can you OK this?

The patch below begins the process by getting rid of all the C names
in doc/guile-api.alist (stable branch) that begin with something other
than `coop_', `gdb_', `gh_' or `scm_'.  Is it OK to commit it?

        Neil

Index: doc/guile-api.alist
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/doc/guile-api.alist,v
retrieving revision 1.1.4.2
diff -u -r1.1.4.2 guile-api.alist
--- doc/guile-api.alist 1 Mar 2002 08:45:05 -0000       1.1.4.2
+++ doc/guile-api.alist 9 Mar 2002 16:32:37 -0000
@@ -1543,7 +1543,6 @@
 (zero? "#<primitive-procedure zero?>")
 ) ;; end of scheme
 (C
-(collisionp B)
 (coop_abort T)
 (coop_condition_variable_destroy T)
 (coop_condition_variable_init T)
@@ -1588,7 +1587,6 @@
 (gdb_print T)
 (gdb_read T)
 (gdb_result B)
-(gexceptfds B)
 (gh_append T)
 (gh_append2 T)
 (gh_append3 T)
@@ -1700,13 +1698,6 @@
 (gh_vector_ref T)
 (gh_vector_set_x T)
 (gh_write T)
-(gnfds B)
-(greadfds B)
-(gwritefds B)
-(issued_msgs B)
-(rexceptfds B)
-(rreadfds B)
-(rwritefds B)
 (scm_2ulong2big T)
 (scm_I_am_dead B)
 (scm_abs T)
@@ -3302,6 +3293,6 @@
 (scm_yield T)
 (scm_your_base D)
 (scm_zero_p T)
-(terminating B)
+(scm_i_terminating B)
 ) ;; end of C
 ) ;; eof

Index: libguile/deprecation.c
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/libguile/deprecation.c,v
retrieving revision 1.9
diff -u -r1.9 deprecation.c
--- libguile/deprecation.c      28 Jun 2001 01:11:58 -0000      1.9
+++ libguile/deprecation.c      9 Mar 2002 16:32:45 -0000
@@ -58,7 +58,7 @@
 /* This is either a boolean (when a summary should be printed) or a
    hashtab (when detailed warnings shouold be printed).
 */
-SCM issued_msgs;
+static SCM issued_msgs;
 
 void
 scm_c_issue_deprecation_warning (const char *msg)

Index: libguile/fports.c
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/libguile/fports.c,v
retrieving revision 1.100.2.2
diff -u -r1.100.2.2 fports.c
--- libguile/fports.c   26 Aug 2001 21:49:32 -0000      1.100.2.2
+++ libguile/fports.c   9 Mar 2002 16:32:53 -0000
@@ -717,7 +717,7 @@
 
 /* becomes 1 when process is exiting: normal exception handling won't
    work by this time.  */
-extern int terminating; 
+extern int scm_i_terminating; 
 
 static void
 fport_flush (SCM port)
@@ -749,7 +749,7 @@
                }
              pt->write_pos = pt->write_buf + remaining;
            }
-         if (terminating)
+         if (scm_i_terminating)
            {
              const char *msg = "Error: could not flush file-descriptor ";
              char buf[11];

Index: libguile/gc.c
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/libguile/gc.c,v
retrieving revision 1.208.2.6
diff -u -r1.208.2.6 gc.c
--- libguile/gc.c       1 Mar 2002 21:12:47 -0000       1.208.2.6
+++ libguile/gc.c       9 Mar 2002 16:33:18 -0000
@@ -2684,7 +2684,7 @@
     scm_gc_unregister_root (p);
 }
 
-int terminating;
+int scm_i_terminating;
 
 /* called on process termination.  */
 #ifdef HAVE_ATEXIT
@@ -2701,7 +2701,7 @@
 #endif
 #endif
 {
-  terminating = 1;
+  scm_i_terminating = 1;
   scm_flush_all_ports ();
 }
 
Index: libguile/iselect.c
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/libguile/iselect.c,v
retrieving revision 1.28
diff -u -r1.28 iselect.c
--- libguile/iselect.c  12 Apr 2001 01:40:20 -0000      1.28
+++ libguile/iselect.c  9 Mar 2002 16:33:25 -0000
@@ -100,21 +100,21 @@
 /* This flag indicates that several threads are waiting on the same
    file descriptor.  When this is the case, the common fd sets are
    updated in a more inefficient way.  */
-int collisionp;
+static int collisionp;
 
 /* These are the common fd sets.  When new select calls are made,
    those sets are merged into these.  */
-int gnfds;
-SELECT_TYPE greadfds;
-SELECT_TYPE gwritefds;
-SELECT_TYPE gexceptfds;
+static int gnfds;
+static SELECT_TYPE greadfds;
+static SELECT_TYPE gwritefds;
+static SELECT_TYPE gexceptfds;
 
 /* These are the result sets.  They are used when we call OS select.
    We couldn't use the common fd sets above, since that would destroy
    them.  */
-SELECT_TYPE rreadfds;
-SELECT_TYPE rwritefds;
-SELECT_TYPE rexceptfds;
+static SELECT_TYPE rreadfds;
+static SELECT_TYPE rwritefds;
+static SELECT_TYPE rexceptfds;
 
 /* Constant timeval struct representing a zero timeout which we use
    when polling.  */