define -- a modest proposal

[MITCHELL WAND <WAND%northeastern.edu@CSNET-RELAY.ARPA>]

I think it is clear that we do not have a consensus on the semantics of 
internal DEFINE.  My understanding of the compromise reached at Brandeis was 
that lexically nested DEFINE would retain the MIT semantics, whereas
the IU semantics could be obtained by using DEFINE! .   The current report 
does not appear to be compatible with that compromise, because it would appear 
necessary to do a

(define foo 'hunoz)

at top-level before one can legally do a set! on foo from an interior scope.

Analyzing this situation, there are two operations involved in a define:

1.  Binding the identifier to some location.
2.  Storing a value in that location.  

The latter operation is clearly doable by set!, so the only issue is #1.
The MIT semantics has DEFINE performing #1 on the current scope.  The 
advantage of this proposal is that it is uniform on both "top-level" and 
interior scopes.  The disadvantage is that it essentially creates a new scope 
(region) in the program which is not delimited by parentheses.  [Perhaps the 
grammar could be fixed to recognize this new, non-list-structure phrase?].
This is an unpleasantness at the top level which I do not think we understand.

[Perhaps we should separate DEFINE into two procedures:

(make-local-variable 'foo)
(set! foo value)

[shades of GNU Emacs-Lisp!!]]

[Another, separate, argument against including internal define as an optional
feature in the report is that, unlike the other optional features in the 
report, it requires pervasive modifications in many other sections of the 
report].

Nevertheless, I am not yet arguing for elimination of internal defines from 
the report, in keeping with the compromise reached at Brandeis.

What I will argue for is the following:

An implementation may have a top level (initial, whatever) environment in 
which every possible identifier is bound (though only some are initialized).

This would allow programs in that implementation to do a set! on a global 
variable (excuse me, a variable in the current top-level environment) from an 
internal scope without having to explicitly bind the variable in the initial 
scope.  It would also allow MIT-style define to proceed, as it does not 
require the existence of a distinguished global environment.

I think this proposal retains the spirit of the Brandeis agreement on this 
issue.

Mitchell Wand