Re: namespaces, goops, etc.

[thi]

   From: Jost Boekemeier <address@hidden>
   Date: 03 Nov 2000 20:19:35 +0100

   Hmm, if I remember correctly an interface is only a special kind of
   module.  A module (or modules) may or may not conform to a given
   interface.

   With define-public on the other hand you initially specify what and
   what not should be visible by others.

   I just think that these are two different things.

as pointed out by Michael Livshin, i think we are talking about
different definitions of "interface".

(pedantic rambling follows.)

as a user i've been bitten twice (shows how fast i learn, ugh) by
relying on ambiguous behavior and so now i wish to caution others about
such sloppiness.  the first case also related to internal defines:

  (define (some-proc)
    (define (internal-proc) ...)                ; definition
    (let ((val (internal-proc))) ...)           ; usage
    (define (another-internal-proc) ...)        ; definition
    (let ((val (another-internal-proc))) ...))  ; usage

this code is bad (all defines should be at the beginning of a block, w/o
intermediate "usage" code) but it worked in guile for a long time (until
mid 1998, i believe).  the second case, more recent, was the loss of
string/symbol interoperability for some subrs.

so my point is that people relying on internal `define-public' to be
equivalent to `export' are walking on thin ice, from both elegance point
of view and maintenance point of view...

my guess is that from the developer's point of view, there are basically
two approaches to stabilizing this situation:
  - restrict usage of `define-public' as outlined in ML's post, and/or
  - deprecate `define-public'.
i favor the latter because `export' is what i use exclusively now
anyway, so i won't miss `define-public'.  (please don't tell me `export'
is going away! :-)

thi