[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Proposed change to SPECIAL: quick poll



I am in favor of the following proposed change to SPECIAL declarations.
Making them work two different ways in different contexts was the hardest
part of writing the interpreter, and requires an ugly explanation in
the manual.  Opinions?
--Guy

- - - - Begin forwarded message - - - -
Received: from CMU-CS-PT by CMU-CS-A; 5-Apr-83 10:56:01-EST
Received: from CMU-CS-C by CMU-CS-PT;  5 Apr 83 10:48:53 EST
Received: ID <FAHLMAN@CMU-CS-C>; 5 Apr 83 10:51:19 EST
Date: Tue, 05 Apr 1983 14:51:00 -0000
From: Scott E. Fahlman <Fahlman@CMU-CS-C>
To:   steele@CMU-CS-C
Cc:   slisp@CMU-CS-C
Subject: global specials


Guy,

In working on the new lexical eval, I have come more and more to believe
that the rules for the special declaration are ill-formed.  As I
understand it, a SPECIAL declaration at the start of a variable-binding
form is relevant only to that particular incarnation of the variable in
question; a SPECIAL declaration at top-level declares a variable
to be globally special; a SPECIAL declaration anywhere else is an error.
This "globally special" business is an exception to the general rule
about variable-affecting declarations, but it seems absolutely necessary
to have global specialness around for the convenient writing of code
(using DEFVAR, etc.), so we can't just flush it in the name of
uniformity.

My problem is that I don't think the concept of TOP-LEVEL is
well-defined, and any intuitively correct definition would seem to be
computationally intractable.  Tying this concept to READ seems wrong,
since code could be generated internally or could be read in by
something other than the system standard reader.  Tying it to what is on
the stack at present is expensive and fails in a similar way.  For
example, it would prevent the user from building a loop that reads
things from a file, takes some notes on what is coming in, and then
passes the stuff to eval.  This EVAL would see user-defined functions
on the stack and would not believe itself to be at top level.

Any thoughts or suggestions?  My best shot at this is to restrict the
SPECIAL declaration to appearing at the start of binding forms and to
affect only that incarnation, but to introduce a new declaration
GLOBALLY-SPECIAL that can appear anywhere and that does what the current
top-level SPECIAL declaration does.  Then we can keep our defvars and
such (converting them to the use of GLOBALLY-SPECIAL, but we don't have
to appeal to the concept of "top level".  It also cleans up the manual a
bit, getting rid of an ugly and confusing exception.  The price is that
old Maclisp files would have to be converted if they use top-level
SPECIAL declarations directly and not via DEFVAR, but that's a fairly
small price to pay.  

Unless you have a better suggestion, I would like to propose this change
to Common Lisp and try to get it into the manual in time.  In any event,
this is what I am currently implementing in the new eval, since I can't
see how to make top-levelness win.

-- Scott
- - - - End forwarded message - - - -