[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: PSZ at MIT-ML
- Subject: Bad ideas
- From: George J. Carrette <GJC at MIT-MC>
- Date: Wed ,16 Jul 80 00:42:00 EDT
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
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.
(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
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.