New special forms -- CALL and VAR (or some such)

[Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>]

I find the presentation of special forms very clumsy. I believe that it would be
much smoother if we would introduce two new special forms. I call them VAR and CALL.
Jonathan points out that the VAR special form was effectively in the original 
(unrevised) SCHEME report as the STATIC special form. In any case, the idea would
be that (VAR X) is the same as X in a program. (CALL X . args) would be the same as
(X . args) where X didn't name a special form. I'm susceptible to other names. eg,
VARIABLE-REFERENCE is a fine alternative for VAR. FUNCTION-CALL, COMPOSITION, or
FUNCTION-COMPOSITION are ok for CALL. The main point is that it should be possible
to define the language completely in terms of special forms. eg, we first introduce
expressions that look like:
 (LAMBDA (X Y) (CALL (VAR +) (VAR X) (VAR Y)))
and then introduce abbreviations for VAR and CALL forms such that
 (LAMBDA (X Y) (+ X Y))
means the same thing. The result is that when describing evaluable expressions
you don't have to disjoin into (keyword . ...) and (fn . ...). Instead, you get a
fair amount of mileage in the initial exposition out of just saying that there are 
only special forms, and then relaxing the description. 
Early T had these primitives, and I thought they made my first T manual look nicer,
but they seem to have gotten lost over time.

Anyway, does anybody buy this idea?

--- Text that follows is just for fun and not part of the above proposal ---

By the way, in the early T it was even possible to write:
 (LAMBDA (0 1) (CALL (VAR +) (VAR 0) (VAR 1)))
or
 (LAMBDA (0 1) (+ (VAR 0) (VAR 1)))
ie, you could have non-symbol variable names. This got lost at some point, but I
still think this was kinda fun.

As a hack, I even wrote things like:
 (DEFINE (GENSYM)
   (LET ((CELL (LIST 'VAR NIL)))
     (SET (CADR CELL) CELL)
     CELL))
 (DEFINE FOO (LET ((V1 (GENSYM))
		   (V2 (GENSYM)))
	       (ENCLOSE `(LAMBDA (,V1 ,V2) (+ ,V1 ,V2)))))
 (FOO 1 2) => 3
The reason for the CADR-circular result of GENSYM may not be completely obvious
on first glance. I think it's the only way to satisfy the relevant constraints,
though. I certainly won't try to argue that this was the "right thing", but it
certainly struck me as novel. Hope some of you find it amusing...