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

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

    Return-Path: <RAM@C.CS.CMU.EDU>
    Received: from C.CS.CMU.EDU by SPAR-20.ARPA with TCP; Thu 3 Sep 87 11:18:03-PDT
    Received: ID <RAM@C.CS.CMU.EDU>; Thu 3 Sep 87 14:18:04-EDT
    Date: Thu, 3 Sep 1987  14:17 EDT
    Message-ID: <RAM.12331715786.BABYL@>
    Sender: RAM@λλ
    From: Ram@C.CS.CMU.EDU
    To:   Dan Carnese <CARNESE@SPAR-20.ARPA>
    Cc:   cl-cleanup@SAIL.STANFORD.EDU
    Subject: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
    In-reply-to: Msg of 2 Sep 1987  22:25-EDT from Dan Carnese <CARNESE at SPAR-20.ARPA>


    Actually, having the defining form export the symbol from its home
    package is more problematic than exporting from the current package.
    Consider a code fragment like:
        (in-package 'a :use '(lisp b))
        ...
        (defun-exported b::foo ...)
        foo

    What package is the following "foo" in?  Obviously the DEFUN-EXPORTED
    and the "foo" could be in the same form, so under some circumstances,
    that "foo" couldn't possibly refer to B:FOO, yet if the compiler
    happened to process the DEFUN-EXPORTED before the "foo" was read, then
    it would be B:FOO. 

    To say that these things are "just problems in the current language
    definition" doesn't avoid the problem.  Adding new langauge features
    is language design, and a language designer must consider how each
    language feature will affect his ability to properly define the
    language.  I am suggesting that this feature would significantly
    complicate the language definition for what seems to me to be little
    gain.

      Rob

Sorry, but I'm still not clear on how this extension makes the situation
any more complicated.  What I understand you to be saying is that the
semantics of your example would not be well-defined in the case where these
are not top-level forms.  Of course, you're right.  But since any code
involving the new constructs can be expanded into existing constructs
(e.g., by replacing the defun-exported with a defun followed by an export),
the proposal doesn't introduce any new kinds of problematic situations.
Thus, it is difficult to argue that the language definition would be made
more complicated by having such expansions predefined.

With regard to the naming issue that Scott raised, the use of "-exported"
as a suffix seems quite reasonable.  I'm happy to accede to a change that
increases readability.
-------