[Dan L. Pierson <pierson@mist.ARPA>: Issue: LET-TOP-LEVEL (version 1)]

[Masinter.pa@Xerox.COM]

I have 34 messages on this topic in early march, and it petered out. 
This is the original proposal, to  jog to your memory.  


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

Return-Path: <CL-Cleanup-mailer@SAIL.Stanford.EDU>
Redistributed: xerox-cl-cleanupâ??.pa
Received: from SAIL.Stanford.EDU by Xerox.COM ; 01 MAR 88 13:04:32 PST
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 1 Mar 88  13:01:05 PST
Received:  by multimax.ARPA (5.51/25-eef)
	id AA11586; Tue, 1 Mar 88 16:02:47 EST
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA21522; Tue, 1 Mar 88 16:02:38 EST
Message-Id: <8803012102.AA21522@mist.UUCP>
To: cl-cleanup%sail.stanford.edu@multimax.ARPA
Subject: Issue: LET-TOP-LEVEL (version 1)
Date: Tue, 01 Mar 88 16:02:35 EST
 From: Dan L. Pierson <pierson@mist.ARPA>

Issue:         LET-TOP-LEVEL
References:    Top-Level Forms (p. 66), DEFUN (p. 67), 
               DEFVAR, DEFPARAMETER, DEFCONSTANT (pp. 68-69)
Category:      ADDITION
Edit history:  Version 1 by Pierson 3/1/88
Status:        For Internal Discussion

Problem description:

The main defining forms in CLtL do not support defining (as opposed to
creating) closures in lexical environments.

Proposal (LET-TOP-LEVEL:ALLOW-DEF):

Require implementations to support DEFUN, DEFVAR, DEFPARAMETER, and
DEFCONSTANT enclosed in a LET at top level as well as a PROGN at top
level.  Do not require support for DEFMACRO (environment irrelevant)
or EVAL-WHEN.  Explicitly note that a "top level" let can be included
in a top level PROGN.

Test Cases/Examples:

The following creates a simple resource allocation package for THINGs.
It needs to be COMPILE-FILEd to test it.

(LET ((THINGS '()))
  (DEFUN GET-THING ()
    (IF THINGS
	(PROG1 (CAR THINGS)
	  (SETF THINGS (CDR THINGS)))
	(MAKE-THING)))
  (DEFUN FREE-THING (THING)
    (SETF THINGS (CONS THING THINGS))))

Rationale:

Common Lisp tries to support lexical closures but this support is
really confined to anonymous lambdas within other function
definitions.  This proposal attempts to move lexical closures closer
to first-class status in Common Lisp.

Current practice:

The above example works in both Ibuki Lisp and Lucid, however only
Ibuki Lisp describes (SYMBOL-FUNCTION 'GET-THING) as a closure.  Both
Symbolics and TI are reported to leave GET-THING and FREE-THING as
named-lambdas instead of compiling them.

Cost to Implementors:

While there is obviously some work required, it shouldn't be too hard
since all Common Lisp compilers are required to understand functions
in lexical closures in other contexts.

Cost to Users:

None, this is an upward compatible change.

Cost of non-Adoption:

Common Lisp will continue to leave a major style of lexical closure
use unsupported.  This is probably most important to people converting
 from Scheme to Common Lisp.

Benefits:

Lexical closures will become more useful.  The increased information
hiding available may make some programs more maintainable by reducing
the number of global variables which really should be private to a
small group of functions.  It will be easier to migrate some Scheme
programming styles to Common Lisp.

Aesthetics:

The aesthetics of the language will be improved by supporting a more
uniform view and use of lexical closures.

Discussion:

It has been pointed out that much of this proposal can be accomplished
by layering macros on top of SETF of SYMBOL-FUNCTION.  The problem
with the macro approach is that it doesn't support whatever additional
environmental things the implementation may decide to do with DEFUN
(e.g. make an entry in the cross reference database).

One disadvantage of this proposal is that it doesn't interact well
with Lisp-style incremental development, for example a new top-level
defun of GET-THING wouldn't work.  Pierson believes that this is an
inherent consequence of heavy use of lexical closures and that the
best workaround is to use an inspector which can support incremental
development within the current lexical scope, however this is all
outside the purvue of this committee.

Maybe this should be a compiler proposal instead of a cleanup proposal.


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