Bad ideas

[George J. Carrette <GJC at MIT-MC>]

cc: HIC at MIT-MC, BUG-LISP at MIT-MC, BUG-LISPM at MIT-MC

    Date: 07/15/80 23:22:16
    From: PSZ at MIT-ML
    To:   hic
    cc:   (BUG LISP) at MIT-ML, (BUG LISPM) at MIT-ML, GJC at MIT-ML
    Re:   Bad ideas

    My a priori belief shows through in my phrasing, but I am by no means immune
    to a good argument.  I was really just expressing a desire for some consensus
    on it before it gets installed and I begin to see (dread the thought) things
    like my perfectly reasonable
    	(setq space 3000)
    turn behind my back into
    	(setq 40 3000),
    as I think it likely that such "expanding constants" will be one plausible use
    of the facility you are planning.  Please note that I am not yet prepared to
    argue the details (e.g., whether expansion should happen in quoted contexts,
    implicitly quoted contexts, whether it should be lexically or dynamically
    specified, or any such meaty issues).  I am still searching for a good case
    to be made for the fundamental idea.  Although I have at times had cravings for
    just such a feature, some reflection has so-far dissuaded me (like some
    cravings for giant anchovy pizzas).  Someone please step forward and
    demonstrate a program in which having this feature is a big win, outweighing
    the disadvantage of further weakening the transparency of Lisp.


Well, what I was doing (just so happens in maclisp), was
implementing closures with lexically scoped instance variables,
as apposed to the special variables which the lisp machine uses.

(defclosure foo (a b c d)
	    ((sum 0)) ; def-struct like specs.
     
           ...body ...)

(setq q (make-foo-closure ... defstruct-like specifications ...))

(call q 1 2 3) =>

(lsubrcall t (pointer-slot q) (data-slot q) 1 2 3)

simple eh? What actually gets defined for FOO is an
lsubr which takes as its first argument a HUNK with the
environment.  Since SUM is an instance variable you want
SUM to expand into (CXR <17> DATA) and (SETQ SUM FOO) to
go to (SETF (CXR <17> DATA) FOO). The defstruct-like
instance variable specs are actually used as a defstruct
to define the variable structure. (A HUNK in haclisp, oops, I
mean maclisp)

However, if in the body we have (LET ((SUM 34)) we DON'T want
that to be (LET (((CXR 3 DATA) 34) ...) !!!! 

To further complicate things, I want the so-called ATOM-MACRO
properties to be in effect LOCAL to the BODY only. They
do not want to be global properties.

I know that using these atomic-macros-of-the-first-kind
DOES NOT INTERFERE WITH THE TRANSPARENCY OF LISP.
Note: any SETQ of a special variable does not qualify as
being transparent lisp programming anyway.

HIC may want to use atomic-macros-of-the-SECOND-kind, and so
might I for other purposes. I don't think that one excludes
the other. Although the ones I want would be harder to implement.