[Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]

[Masinter.pa@Xerox.COM]

I've given the name "EXPORT-COORDINATION" to this issue. I think this is
an interesting proposal. Comments? (Before Dan writes up a more formal
proposal?)



     ----- Begin Forwarded Messages -----

Return-Path:
<@SPAR-20.ARPA,@KATYDID.SPAR.CAS.SLB.COM:Carnese@SPAR-20.ARPA>
Received: from SPAR-20.ARPA by Xerox.COM ; 25 AUG 87 13:01:17 PDT
Received: from KATYDID.SPAR.CAS.SLB.COM (KATYDID.#Internet) by
SPAR-20.ARPA with TCP; Tue 25 Aug 87 12:59:13-PDT
Date: Tue, 25 Aug 87 12:59 PDT
 From: Dan Carnese <Carnese@SPAR-20.ARPA>
Subject: proposal
To: masinter.pa
Message-ID: <870825125906.2.CARNESE@KATYDID.SPAR.CAS.SLB.COM>

Thanks for the information.  I didn't realize that proposals were
required
to be in such a detailed format but of course that makes sense.

I think the problem can be "symbolized" as
multiple-forms-for-exported-defined-symbols.  Its definition could be:

        Exporting a defined symbol currently requires two seperate
forms:
        one to give a value to the symbol and another to cause the
symbol
        to be on a package export list.  These two forms must be kept in
        sync as the program evolves.

The benefit would be:

        Explicit export lists could be eliminated in many cases.

The thrust of the discussion would be:

        This is an extremely straightforward addition, one which could
be
        implemented by macros that would simply expand to an export and
an
        existing definition form.  Only DEFSTRUCT* would involve actual
        programming, to process the additional defstruct and slot
options.

        The proposal does not completely eliminate the need for explicit
        calls to EXPORT for two reasons.   First, it is sometimes useful
to
        export symbols for which no definition forms are applicable,
e.g.,
        to be used as arguments to functions.  Second, explicit exports
of
        defined symbols are still needed in the following case.  Suppose
A
        and B are packages, A defines an external symbol F, and B uses
A.
        Suppose further that F appears in a form being read into package
B,
        and that this form is to be read before the definition of F is
        loaded.  In this case, an explicit export of F must occur, to
avoid
        F being inappropriately interned in B.

Does this sound reasonable?

-- Dan


     ----- End Forwarded Messages -----