From: Ben Moreland <[email-masked]>
To: [email-masked]
Date: Fri, 28 Jun 85 11:00:26 est

Hello --

I am interested in getting the old messages from FRANZ-FRIENDS. I am
trying to be added to this list. I would appreciate it if you would send
the old messages to me at UConn, csnet address:
      ben@uconn,    or    ben%uconn.csnet@csnet-relay

Thank you,

Ben Moreland

From: [email-masked] (Johnathan Devine)
Date: 31 May 1985 1510-EDT (Friday)
To: forum@mit-mc
Subject: Graduation tickets for Sale

Call David or Johnathan at dl 6689 or 6153 at random intervals between
10am and 1am.

Received: from MIT-XX.ARPA by MIT-MC.ARPA; 27 May 85 15:29:27 EST
Date: Mon 27 May 85 15:29:50-EDT
From: Steve Heller <[email-masked]>
Subject: Berkeley Apartment to let for July
To: [email-masked]

            July Sublet in Berkeley
            -----------------------

A 1 bedroom apartment will be available in Berkeley
for the month of July.  It is a sunny second floor
apartment, just above College, about 1 mile from UC,
on a major bus line.  The apartment is furnished,
and very nice, and would like a tennant with the
latter characteristic.  The cost is $300.  For further
information, call Kalyn at (415) 655-9100.
-------

From: [email-masked] (Michael D. O'Keefe)
Date:  4 May 1985 2237-EDT (Saturday)
To: forum@mit-mc
Cc: 
Subject: Modem help!

Is there anyone who has any knowledge of the operation of a Bell
Dataphone 212A?  Specifically:

  1) How to interface it to a phone line?  It has two RS232 type
     connectors on the back.  One is the line to the terminal, does the
     other go to the phone line somehow?

  2) What are the functions of the fron panel buttons?

  3) Is this modem autodial?

Any information or leads will be greatly appreciated.

                                       Mike
                                       (okeefe@mit-speaker)

Date: Wed, 20 Mar 85 20:01 EST
From: Kent M Pitman <[email-masked]>
Subject: defsubst in Maclisp
To: [email-masked], [email-masked]

    Date:  Wed, 20 Mar 85 18:30 EST
    From:  Barry Margolin <[email-masked]>
    Re:    defsubst in Maclisp

    Has anyone written a DEFSUBST for Maclisp (or a similar dialect)?

Yes. I think the code is in LIBLSP;LISPM on MC with my other LispM
compatibility stuff (WITH-OPEN-FILE, WITH-OPEN-STREAM, ONCE-ONLY,
MEXP, ...).

Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA; 20 MAR 85 18:30:58 EST
Date:  Wed, 20 Mar 85 18:30 EST
From:  Barry Margolin <[email-masked]>
Subject:  defsubst in Maclisp
To:  [email-masked]
Message-ID:  <[email-masked]>

Has anyone written a DEFSUBST for Maclisp (or a similar dialect)?  (See
the Chineual for a description of DEFSUBST.)  I have been trying to
write one for several days, mostly just as an academic exercise.  I
managed to implement a pretty simple one, which doesn't handle &keywords
(&optional, &rest, etc) pretty quickly (it expands into an equivalent
DEFUN at (load eval) time, and a DEFMACRO at compile-time).  I was in
the process of modifying it to deal with &keywords when I realized that
it should then also do destructuring, in order to be completely
compatible with DEFUN.  At this point I gave up.

I don't really need this, but I am curious whether anyone has done it,
and what the compile-time code looks like.
                                        barmar

Date: Wed 27 Feb 85 14:19:22-EST
From: Michael J. Beckerle <[email-masked]>
Subject: 6871 partners wanted
To: [email-masked]

I am looking for partners interested in a 6.871 project involving
knowledge-based code generation for pipelined processors. The idea is to
take a knowledge base that describes the processor pipeline, hazard
resolution etc, and a partial ordering on the instruction execution (a
data dependence graph). The result is a linear ordering of the
instructions which should run fast because it is designed with the
pipeline hazards in mind. 

I would like a partner who understands pipelining, and hazards, i.e.,
someone who is taking or has taken 6.823 (computer architecture).

I have easy access to lisp machines on the second floor of NE43, and can
arrange same for partner(s).

If you are interested, send mail to Beckerle@xx.

-------

Date:  Wed, 27 Feb 85 10:41 EST
From:  [email-masked]
Subject:  televideo terminal help
To:  [email-masked]
Message-ID:  <[email-masked]>

Is there anyone out there who could help the Hillel office fix a
televideo 950 terminal that is acting strange?  Particularly, when using
emacs, it fails to erase the previous page before printing the next one.
   If you can help, please call Hillel at 253-2982, or send mail to mc.
Thanks----Rabbi Dan Shevitz

Date: Mon 25 Feb 85 21:32:45-EST
From: Michael J. Beckerle <[email-masked]>
Subject: Tomos Moped
To: [email-masked]

There is a Tomos Moped locked up on the
west side of the building in the bike racks,
and it appears to have been there for a long
time.

If the owner of said moped is interested
in selling it, please call Sam Jordan, 
265-9706 between 5:30 and 9:30 pm. He is 
interested in buying it.

I'm just posting this query for a friend
so don't reply to me.
-------

Date: Wednesday, 10 October 1984 11:58:31 EDT
From: [email-masked]
To: [email-masked]
cc: [email-masked], [email-masked], [email-masked]
Subject: UCLA Perq
Message-ID: <[email-masked]>

The Perq at UCLA, which I have seen in person, is running the Beta release
of S5 with the "slasher 1" version of lisp -- that is, a pre-release, not
even Beta.  Thus, it does not have any of the new interfaces.  I believe
that it is using Ucode from before the fast funcall stuff and caching was
put in, but don't recall for sure.  That is, the ucode is probably 2 major
revisions old; and at least 1 major revision old.  Also, no one has a Perq
lisp yet with the faster startup granted by using only the new interfaces.
(Every version of Perq lisp that I know of still uses the old ones at least
internally -- thus they must be initialized as before -- in addition to the
new, fast initializing versions.)

--Joe

P.S.  No Perq has a 68000 in it.  Or a 68010.  All have board-level,
micro-programmable CPU's that aren't true bit-slices (like AMD2901's) but
have been described as such since the chip used for the ALU is 4-bits wide
and five are used to construct a 20-bit ALU.  (No, I don't remember which
chip, but it's not a secret.  It's some TI ALU chip.)  And though the
current board has a 20-bit wide ALU, external data paths are 16 bits wide.

Date: Wed 10 Oct 84 10:08:34-EDT
From: Daniel C. Cheng <[email-masked]>
Subject: IBM PC Software Development Positions Available
To: [email-masked]

Data Resources, Inc., a Lexington based consulting firm is seeking
computer science professionals to develop educational support software
on IBM PC based machines for a "leading business school in the Cambridge
area". This position provides both consulting and software development
opportunities. We are seeking individuals with strong technical skills
who are highly motivated and possess good interpersonal skills.

Interested applicants should forward their resumes to:
	Ms. Janet Merluzzi
	Personal Computer Products Group
	Data Resources, Inc.
	24 Hartwell Avenue
	Lexington, MA 02173

Thank you.
-------

Date: Mon 8 Oct 84 21:22:25-EDT
From: Michael M. How <[email-masked]>
Subject: Concept-LNZ manual
To: [email-masked]

Does anyone have a Concept-LNZ manual? I would  just like to see a
summary of its features.
					Thank you,
					Michael How
-------

Date: Mon, 8 Oct 1984  15:51 EDT
Sender: [email-masked]
From: Skef Wholey <[email-masked]>
To:   Charles Dolan <[email-masked]>
Cc:   [email-masked], [email-masked], [email-masked]
Subject: Benchmark - PERQ CL vs Apollo T

    Date: Monday, 8 October 1984  13:17-EDT
    From: Charles Dolan <cpd at UCLA-LOCUS.ARPA>

    UCLA has a demo unit of the new PERQ 68000 based workstation
    running Common Lisp.

The PERQ is not a 68000 based machine.  There's a bit-sliced processor inside
of it.  It's basically a 16-bit machine.

    		PERQ		DN300		DN460

    (tak ...) [3]	6.3 sec		3.4/6.3 sec [2]	1/2.7 sec [2]

Tak runs in under 5 seconds on my Perq.  The Perq Common Lisp implementation
has been undergoing extensive tuning during the past few months, and I bet
you've got a somewhat old version.

The current situation is that people at CMU are still doing most of the
development work, while the Lisp people at Perq systems are doing things like
getting better interfaces to the operating system servers up.

Over the past two weeks I've added register instructions to the Lisp
instruction set (full runtime type-checking, by the way).  Some benchmarky
things have improved dramatically, for example,
	(dotimes (i 1000000))	; That's one million
took over 20 seconds before the addition of registers, and now takes 5.5
seconds.  I bet the register instructions will help some of your other
benchmarks as well.

"Benchmarking is, at best, a black art."  I'd like to see some large bechmarks
run on a large number of machines (something like OPS5).  I like things along
the lines of compilation speed and how fast the editor reads and writes files.
Those are things that most people do a lot, and spend time waiting for.

Common Lisp and T are very different languages, and I bet I could devise some
benchmarks that ran significantly faster on the Perq than on the Apollo
machines.  Have you tried CTAK (TAK using catch and throw)?

I don't want to thwart your benchmarking effort, and I'm not offended or
anything, but I felt I should mention that the Perq Lisp system is still in the
tuning phase.

--Skef

Date:           Mon, 8 Oct 84 10:17:49 PDT
From:           Charles Dolan <[email-masked]>
To:             T-Users@Yale, Lisp-Forum@MIT-MC, Common-Lisp@Su-AI
Subject:        Benchmark - PERQ CL vs Apollo T

UCLA has a demo unit of the new PERQ 68000 based workstation
running Common Lisp. We are currently using Apollo workstations
and T. I compared the workstations on the following points:

	standard shell startup,
	standard editor startup,
	lisp editor startup,
	compilation,
	(fact 100) - recursive factorial,
	(tak 18 12 6) - code given below,
	(reverse1 *long-list*) - recursive reverse of a 100
				 element list, and
	(reverse2 *long-list*) - recursive reverse of a 100
				 element list using closures.

The DN300 is Apollo's low end workstation. It had 1.5 MB and no
local disk. The DN460 is Apollo's bit-slice implementation of the
68000 instruciton set.

		PERQ		DN300		DN460

shell		10 sec		2/5.5 sec [5]	1/3 sec [5]
editor		7 sec		1 sec		1 sec
lisp editor [1]	14/1.5 sec	23.3/3 sec	10.5/1.8 sec
compilation [4]	11 sec		54 sec		24 sec

(fact 100)	2.1 sec		1.12 sec	0.61 sec
(tak ...) [3]	6.3 sec		3.4/6.3 sec [2]	1/2.7 sec [2]
(reverse1 ...)	2.2 sec		1.2 sec		0.42 sec
(reverse2 ...)	2.7 sec		1.6 sec		0.67 sec

All times were computed by running the funciton is a loop 30
times and dividing the wall clock time by 30.

[1] Since the lisp editors are embedded in the lisp environment
    two times are given. The first is for the initial startup of
    the editor the first time it is invoked. The second is for
    subsequent invocations.

[2] The faster of the two times times is for the case when block
    complilation is used. Here the recursive calls to (tak ...)
    are compiled as jumps.

[3] In the T code explicit calls to the FIXNUM arithmetic
    routines 'FX<' and 'FX-' were used.

[4] The which was compiled is the code below plus one auxiliary
    function for each benchmark which performed the loop.

[5] The first time is for the AEGIS shell. The Second is for the
    AUX cshell.

The code follows.

T:
	(define (fact i) (cond ((eq? i 0) 1)
        	               (T (* i (fact (-1+ i))))))

Common Lisp:
	(defun fact (i) (cond ((eq i 0) 1)
			      (T (* i (fact (1- i))))))

T:
	(define (tak x y z)
	        (cond ((not (fx< y x)) z)
	              (T
	                 (tak (tak (fx- x 1) y z)
        	              (tak (fx- y 1) z x)
	                      (tak (fx- z 1) x y)))))

Common Lisp:
	(defun tak (x y z)
		(declare (type integer x)
			 (type integer y)
			 (type integer z))
		(cond ((not (< y x) z)
		      (T
			 (tak (tak (- x 1) y z)
			      (tak (- y 1) z x)
			      (tak (- z 1) x y)))))

T:
	(define (reverse1 l) 
		(cond ((null? l) nil)
                      (T (append (reverse1 (cdr l)) (list (car l))))))

Common Lisp:
	(defun reverse1 (l)
	       (cond ((null l) nil)
		     (T (append (reverse1 (cdr l )) (list (car l)))))

T:
	(define (reverse2 l) 
	   (cond ((null? l) (lambda () l))
	         (T (lambda () (append (apply (reverse2 (cdr l)) ())
	                                (list (car l)))))))

Common Lisp:
	(defun reverse2 (l)
	  (cond ((null l) (function (lambda () l)))
		(T (function
		    (lamda () (append (apply (reverse2 (cdr l)) ())
				      (list (car l))))))))

	-Charlie Dolan
	 [email-masked]

Received: from Semillon.ms by ArpaGateway.ms ; 11 SEP 84 12:17:57 PDT
Date: 11 Sep 84 12:17 PDT
From: [email-masked]
Subject: [MJackson.Wbst: Why Your Pascal and Modula-2 Programs Don't
 Work]
To: [email-masked]
cc: [email-masked],[email-masked],[email-masked]
Reply-to: [email-masked]

The classic fencepost bug?

     ----- Begin Forwarded Messages -----

Date: Tue, 11 Sep 84 11:02 EDT
From: MJackson.Wbst
Subject: Why Your Pascal and Modula-2 Programs Don't Work
To: AllWhimsy^.ES
cc: Modula-2^.ES, ProcessTechnology^
Reply-To: MJackson.Wbst

"In an array, individual elements are readily identified by means of a
computed index, which represents a position in the sequence of elements.
The address of the fifth element, for example, is simply the address of
the first element plus five times the size of an element."

--	Niklaus Wirth in the September /Scientific American/

     ----- End Forwarded Messages -----

Date: Fri 31 Aug 84 16:20:00-EDT
From: [email-masked]
Subject: mail list addition
To: [email-masked]

please add me to the lisp forum mail list. i am bob green
lcg.green@dec-marlboro
thank you...bob green
-------

Date: Fri 17 Aug 84 12:54:21-EDT
From: Daniel C. Cheng <[email-masked]>
Subject: Info request: Microcomputer file transfer protocols for PC & UNIX
To: [email-masked]

I am interested in sending files between an IBM XT and a UNIX based
supermicro (Onyx). I am aware of several file transfer protocols:
XMODEM, MODEM7, KERMIT-- does anyone know where I can obtain a 
spec of these (or others) protocols so that I can implement them
on the Onyx?

Thanks in advance.

	Dan
-------

Date: Fri 13 Jul 84 10:30:26-EDT
From: Michael J. Beckerle <[email-masked]>
Subject: where to donate cans????
To: [email-masked]

Many of us on the 2nd floor are being buried up to our knees in
empty pop cans.... and would love to find a worthy charity to take them
away for us. I have heard that there is a group of people here
who donate all their cans to the Girl Scouts. Would someone of this
group please send me a message so that we can contribute also!

...mike beckerle
-------

Received: from MIT-LISPM-4 by MIT-OZ via Chaosnet; 30 Apr 84 00:29-EDT
Date: Sunday, 29 April 1984, 23:30-EDT
From: Christopher Fry <cfry at MIT-OZ>
Subject: eval-while-possible
To: lisp-forum at MIT-OZ, lisp-forum-scrc at SCRC-TENEX

I've found the following function to be of general use when you're uncertain as to
how many evaluations are necessary, or just don't want to be bothered
in figuring it out. My own application for it is for a language
embedded in lisp, where the user is going to be calling functions in the language
with arguments that may be symbols, whose values are other expressions which should be
evaled, possibly more than once.

(defun eval-while-possible (expression &optional (instance nil) &aux values)
  "Evals expression then evals the result of the previous evaluation, and so on
   until error, or until evaluation returns a value eq to a previous value,
    then returns the version of expression
   just before the error.
   If INSTANCE is non-nil, then each evaluation
   is performed in the context of the instance. "
  (setq values (list expression))
  (loop	do
	(multiple-value-bind (the-value error?)
	    (ignore-errors
	      (cond (instance
		     (send instance :eval-inside-yourself (car values)))
		    (t (eval (car values)))))
	  (cond ((or error? (member the-value values))
		 (return (car values)))
		(t (push the-value values))))))

Date: 12 MAR 84 19:49 PST
From: [email-masked]
Subject: History of "backquote" macro
To: [email-masked], [email-masked]
cc: [email-masked], [email-masked], [email-masked],,
 [email-masked], [email-masked], [email-masked],
 [email-masked], [email-masked]

In response to your message sent  Mon, 12 Mar 84

There are two rather distinct components to the MacLisp-Style backquote,
which may have had varying influences from "history".

1) the notion of a template into which somethings were substituted existed
   since the time of Adolfo Guzman's thesis around 1967-8;  he had Lisp-level
   macros called QU and QU* which were essentially like QUOTE except that the
   form was "looked at" by a substitution parser, which substituted for certain
   key words (i.e., the equivalent of "," and ",@").  In later years (meaning
   around the time of Muddle -- 1971-75) some people were using variants of
   a macro-defining function that incorporated similar ideas.  Steele's
   MACRODEF comes to mind and so does a similar package attributed to Chuck
   Rich (both seem to have influenced DEFMACRO as well).

2) the notion of a reader macro that would "compile such a template on the
   fly into Lisp code".  I vaguely remember the influence of Muddle, especially
   for "[" like constructs so that you didn't need to type LIST, (and such
   a macro has been an essential feature of BRANDX for a long time, but with
   more serious development).  Such a reader macro wasn't in common use
   at the MIT AI lab in 1975, but after I returned from IBM (roughly, Jan 1978)
   I remember seeing the LispMachine people using it.  We quickly recognized
   its usefulness, and began a parallel development for PDP-10 MacLisp and NIL.

In fact, the "backquote" reader macro and DEFMACRO are so intertwined
that it has often been said that one can't understand backquote until he's
personally written a bunch of macro-producing macros using the ",'," and ",,"
paradigms.

The Post-1978 development as you (KMP) outlined in your note is more-or-less
as I remember it too.

Received: by YALE-BULLDOG via CHAOS; Mon, 12 Mar 84 17:25:29 EST
Date:    Mon, 12 Mar 84 17:22:04 EST
From:    Drew McDermott <[email-masked]>
Subject: Backquote
To:      [email-masked]
Cc:      [email-masked], [email-masked], 
         [email-masked], [email-masked], 
         [email-masked], [email-masked], 
         [email-masked], [email-masked]

As far as I know, Sussman and I invented backquote, around 1973,
as part of Conniver.  However, we were inspired by
Planner/Muddle, which had the convention that lists evaluated to
lists of the values of their elements; function calls were
indicated by angle brackets.  Furthermore, symbols evaluated to
themselves, too.  You had to say ".var" to get the value of var.
Hence what would traditionally be indicated by
    (LIST 'A X (+ I 1))
was in Planner/Muddle written
    (A .X <+ I 1>)
We wrote this as
    !"(A @X @(+ I 1))
(See pp.  85-86 of the Conniver Reference Manual, AI Memo 259a.)
Sussman later changed !"  to ` (prettier and essential once
strings existed), and made it copy as much as possible of its
input (so it was just as efficient as ordinary quote).  (He also
changed "@" to ","; in the original, ,X meant the Conniver value
of X, while @X meant the Lisp value.)

The original Planner/Muddle notation was due to Carl Hewitt and
Chris Reeve.
-------

From: [email-masked]
Date: 11 Mar 84 16:36:21 PST
Subject: Re: Backquote history
In-reply-to: [email-masked]'s message of 11 Mar 84 16:04 EST
To: Kent M Pitman <[email-masked]>
cc: [email-masked], [email-masked],
 [email-masked], [email-masked],
 [email-masked], [email-masked], [email-masked],
 [email-masked]

I'm glad to hear that we are not alone in having some arguments about
Backquote. There's been some back-and-forth about the Interlisp version,
with a variety of different opinions and implementations.

Recently, Warren Teitelman returned to me a document I had written in
1972 describing a number of features I had added to Lisp/360 at Stanford
in 1971 (with advice from Sridharan.)

Among the various packages was a backquote-like facility.

JonL had dismissed a number of my arguments as those of a "latecomer",
but he threw me out of his office when I suggested I might have even
INVENTED the idea.

It would be quite likely that this was something that Sridharan or I had
seen elsewhere, but it is also possible that this was something that
migrated out of Lisp/360, or that, being an obvious idea, it had arisen
spontaneously in a number of different contexts.

I was wondering if any of the examples you saw might pre-date 1972.

Larry

Date: 12 March 1984 15:26-EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  Backquote history
To: ACW @ SCC-WAIKATO
cc: LISP-FORUM @ MIT-MC, MASINTER.PA @ PARC-MAXC
In-reply-to: Msg of Mon 12 Mar 84 12:10 EST from Allan C. Wechsler <acw%SCC-WAIKATO at MIT-MC.ARPA>

Mentioning MDL's list/form notation reminds me: anybody who is interested
in issues of quoting and quasi-quoting should definitely take a look at
Brian Smith's 3-LISP.

Date: 12 March 1984 13:18-EST
From: Kent M Pitman <KMP @ MIT-MC>
Subject:  [GJS: Backquote history]
To: LISP-FORUM @ MIT-MC
cc: Masinter.PA @ PARC-MAXC
References:
 Msg of 12 Mar 84 12:10-EST from acw%SCC-WAIKATO @ MIT-MC.ARPA,
 Msg of 11 Mar 84 18:37-PST from Gerald Jay Sussman <GJS @ CIT-20.ARPA>

Actually, it looks like it goes back farther than MDL...

  Date: 11 Mar 1984 1837-PST
  From: Gerald Jay Sussman <GJS at CIT-20.ARPA>
  To:   Kent M Pitman <KMP at MIT-MC.ARPA>
  Re:   Backquote history
  In-Reply-To: Your message of 11 March 1984 16:04-EST

  I remember a backquote-like idea being around when I was an undergraduate.
  Adolpho Guzman and ?MacIntosh had a language called CONVERT (embedded in
  Lisp) which had an un-quoting quotation FEXPR (These were the days before
  there was even "'" syntax.).  In addition, we had one in MicroPlanner, and
  in Conniver (gotten from Guzman's idea).  MUDDLE had the whole syntax
  reversed to make that work out neatly.

I notice that the source to the Maclisp TRACE package has a macro called
QU* and which allows you to say things like
 (QU* (... (EV ...) (EV* ...) ...))
where QU* is like "`", EV is like "," and "EV*" is like ",@". This may
be an example of the sort of "un-quoting quotation FEXPR" which GJS is
referring to.

For anyone interested in reading historical code, I recommend the functions
QU*, QU*1, and TRACE-1 (which uses QU*) in the file "MC: LSPSRC; TRACE >".
The file was last modified in 1981 and looks to have been "modernized" a
bit as it was modified, but most of its coding and even its grinding style
is much older. There is a modification history at the top of the file 
detailing the origins of the code therein.

Received: from SCC-ROCKY by SCC-WAIKATO with CHAOS; Mon 12-Mar-84 12:10:35-EST
Date: Mon, 12 Mar 84 12:10 EST
From: "Allan C. Wechsler" <[email-masked]>
Subject: Backquote history
To: [email-masked], [email-masked]
In-reply-to: The message of 11 Mar 84 14:38-EST from MASINTER.PA at PARC-MAXC

I think the original ideas come from MDL.  In MDL, lists and forms are
two different data types.  Lists (written with parens) self-evaluate,
and forms (written with angle brackets) evaluate like forms do in Lisp.

(+ 2 3) => (1 2 3)
<+ 2 3> => 5

Then there is a weird mapping convention -- evaluation distributes over
lists.

(+ <+ 2 3> 5) => (+ 5 5)

There is a quote for those rare occasions where you don't want to
evaluate a form yet, but usually the things you would be quoting are
lists so you don't need the quote anyway.

Symbols self-evaluate in MDL -- you have to tell it you want the value
of a variable.

<SETG FOO 100>  =>  100
FOO => FOO
,FOO => 100

So you can imagine:

(4 ,FOO 5) => (4 100 5)

Finally, instead of comma-atsign they have exclamation:

<SETG FOO (1 2 3)> => (1 2 3)
(3 4 !,FOO 5) => (3 4 1 2 3 5)
(3 4 !<REST ,FOO> 5) => (3 4 2 3 5)

This stuff is sort of basic to MDL's evaluation philosophy, and they
have probably had it since their beginning in the early 70's.

Ref.  "The MDL Programming Language", S.W. Galley and Greg Pfister,
1979, MIT Lab for Computer Science.

   --- Allan

Date: 11 March 1984 16:04-EST
From: Kent M Pitman <KMP @ MIT-MC>
Subject:  Backquote history
To: MASINTER.PA @ PARC-MAXC
cc: LISP-FORUM @ MIT-MC, Guy.Steele @ CMU-CS-A, McDermott @ YALE,
    Genesereth @ SU-SCORE, Dick @ MIT-OZ, Hewitt @ MIT-OZ, GJS @ MIT-OZ
In-reply-to: Msg of 11 MAR 84 11:38 PST from MASINTER.PA at PARC-MAXC.ARPA

    Date: 11 MAR 84 11:38 PST
    From: MASINTER.PA at PARC-MAXC.ARPA
    To:   LISP-FORUM at MIT-MC.ARPA
    Re:   Backquote history

    Anybody remember where backquote came from? I.e., who invented it, 
    when it got added to MacLisp, etc?

Seems like everyone and his brother had some sort of backquote.
It may be hard to come up with a single originator. The LispM
version predates the Maclisp version, so its presence in Maclisp
was probably most directly a compatibility measure; though at the
same time, obviously, a good idea in its own right. But the LispM
crowd probably didn't originate it either. It goes back farther
than I can remember (which would be 77 or so) anyway.

What is perhaps more interesting than who created it was the amount 
of variety in these things. Here are some of the design decisions
that became involved ...

 * There was a lot of variety in how , and ,@ things were marked. These
   questions included what chars we could do without. eg, I was one of the
   people making a lot of noise about "," not being whitespace any more,
   so you couldn't write (5,3) to mean ordered pairs. In retrospect, this
   didn't turn out to be much of a loss. Also, there was a question of
   whether two char markers like ",@" and ",." were a good idea since 
   for example, (LAMBDA (X @X) `(FOO ,X ,@X ,@ X , @X)) could be visually
   confusing. But it was a choice between two char markers and losing another
   readmacro char, and no one wanted to give up yet another char.

 * There was question about where copying should be allowed. ie,
   if you did (DEFUN F (X) `(,X Y)) could you do (SETF (CADR (F ...)) ...)
   on the result without affecting F's future behavior. Early versions
   of backquote guaranteed copying, so `(A B C) was like (COPYTREE '(A B C)).
   This was eventually decided to be a bad idea. The current backquote does
   not define the sharing behavior; it tends to share structure where possible
   but is not defined to do so.

 * There was question about how nesting worked. In particular, some people
   claimed that ,, type things should be disallowed. Others claimed that 
   you should do outside-in counting rather than inside-out. The current 
   behavior is inside-out. There was a long argument between Bawden, McDermott,
   Steele, Rees, myself and a few others. If you're interested in that,
   MC: LSPMAI; BACKQ XMAIL contains this discussion.

 * There was also question about whether quoting or non-quoting should be
   the default. Dick Waters had a variant where quoting was not the default.
   Without seeing it, you might not guess the advantage, but the answer is
   that you didn't have to write LIST, CONS, etc. eg, [X Y Z] was like
   (LIST X Y Z), [X ! Y] was like (CONS X Y). There were advantages to this,
   but basically it loses out when you start to look at large expressions
   with little variability, since `(LAMBDA (,X Y) (+ ,X Y)) is almost the
   same "shape" as the result it will produce, which is not true of
   ['LAMBDA [X] ['+ X 'Y]] which is not as visually similar to its result.

 * I'm sure, though I can't recall specifically, there must have been heavy
   controversy about whether destructive operations like ,. should be
   allowed. I certainly don't like this one.

 * There was also a question of what the backquote macro should read as.
   It could either read directly as calls to LIST, CONS, etc. or it could
   read as macros which would later expand to calls to LIST, etc. when
   evaluted or compiled. According to the initial release notes, the first
   version expanded at readtime, which of course meant that GRINDEF called
   on such code gave a very verbose display. A switch, BACKQUOTE-EXPAND-WHEN,
   was later added so that you could select EVAL or READ time expansion.
   The default, EVAL, now allows GRINDEF to win on backquoted code.

 * There were also some bogus arguments made like that we didn't need `
   and ' to be different chars and that we should just let , be put in any
   ' expression. Such were beaten down by appeals to expressions like `',X
   which are quite common.

On Sunday, 17-Sep-78, HIC and JONL announced backquote as an official
autoloading part of Lisp (version 1742).

On Thurday, 7-Jun-79, JONL announced the introduction of ",.", the 
BACKQUOTE-EXPAND-WHEN feature, and the ability of GRINDEF to win on this
stuff.

I doubt the names of who announced these features are related to who came
up with them. Alan and I just tried to think of places where we
had seen backquote-like ideas; we came up with early versions of the
sources and/or sources to Scheme, LispM, PLASMA and Macsyma.
It was all a product of much negotiation among many people with similar 
but subtly differing ideas.

Date: 11 March 1984 15:32-EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  Backquote history
To: MASINTER.PA @ PARC-MAXC
cc: LISP-FORUM @ MIT-MC
In-reply-to: Msg of 11 MAR 84 11:38 PST from MASINTER.PA at PARC-MAXC.ARPA

I think that most of what I know about backquote can be found in the file
LSPMAI;BACKQ XMAIL on MIT-MC.  That file contains an extended discussion I
had with Drew McDermott about the history, philosophy and implementation of
bacquote.

Date: 11 MAR 84 11:38 PST
From: [email-masked]
Subject: Backquote history
To: [email-masked]

Anybody remember where backquote came from? I.e., who invented it, when
it got added to MacLisp, etc?

Date: 15 Feb 1984 06:24-PST
Sender: SAE-ADA@USC-ECLB
Subject: Addition to list
From: SAE-ADA@USC-ECLB
To: lisp-forum@MIT-MC
Cc: sae-ada@USC-ECLB
Message-ID: <[USC-ECLB]15-Feb-84 06:24:09.SAE-ADA>

Just recently I saw a reference to this list in the Arpanet Franz
Friends list. Is it possible to join this list? If so, my address
is: CSNet  debbie.kei-vax.umcp-cs at udel-relay
    Arpanet sae-ada at usc-eclb
Please let me know when this will become effective.

Thank You
Debbie Franks

Date: 27 September 1983 20:10 EDT
From: George J. Carrette <GJC @ MIT-MC>
Subject:  your note on Function Cells.
To: JonL.pa @ PARC-MAXC
cc: LISP-FORUM @ MIT-MC, Padget @ UTAH-20
In-reply-to: Msg of Tue 27 Sep 83 16:16 PDT from JonL.pa at PARC-MAXC.ARPA

A loaded VAX-NIL MACSYMA has about 14 thousand of what you
call slink cells allocated, mostly for function cells. So if
you had implemented them as a slot in the symbol it would have
indeed been a loser. Actually, another thing the indirection
buys us is to make it possible to relocate symbols without putting
a lot of work into looking at compiled code or its support structures.

Another kind of function cell we see a lot of now is a
flavor-method-table entry. These also get a regular function
cell too now, for the purpose of "book-keeping" in the assembler/loader,
so the figure of 14 thousand is more than slightly bloated by this
and by procedures on property lists. The garbage collector can
clean up this garbage though if the loader did a MAKFUNBOUND.

As you pointed out, the multiple-namespace concept is a very useful
one, and one that programmers have to be able deal with.
People should know that real Scheme programmers can make use of the 
multiple-namespace idea too. In Yale T or MIT "6.001 " scheme one
might do a few different things:

(putprop 'foo (lambda (...) ...) 'bar)

and then write

((get'foo'bar) ...)

or define something that looks cleaner and runs faster such as:

(define-namespace foo)

(define-in-namespace (foo bar) (lambda (...) ...))

and then write

((foo bar) ...)

The *hack* is that languages that are implemented efficiently enough
in *general* allow the user to add his own namespace concepts which will
run as fast as if the implementor had wired them into the system and
wrote about them in the manual himself.

I have observed that T, MIT SCHEME, VAX-NIL, and Lispmachine(s)
live up to this *hack*, requiring slightly different amounts of
kludgery on the part of the user in some cases, but with nothing at
the level of LAP or MICROCODE being required. 

This puts the arguments on a totally different level, at least for
people with practical access to these kinds of languages/machines.

You can do an excelent implementation of maclisp namespacing in T,
and vice-versa (for the maclisp descendants such as lispm and nil).
On the other hand, architectural optimizations in hardware and/or
software can make it a real bitch (to use the techical term) to implement
tail-calling in some implementations.

-gjc

Date: Tue, 27 Sep 83 16:16 PDT
From: [email-masked]
Subject: Function Cells -- the history
To: [email-masked]
cc: [email-masked]

There are two parts to your question:
  1) who first converted atoms (i.e. LITATOMs or SYMBOLs) from list
     structure with weird pointer in the first CAR, to standard block 
     record structure, and
  2) who first differentiated between function context and argument
     context when interpreting an atom.
No doubt, there is an element of "why" in your question too.

RE point 1:

Peter Deutsch's answer is quite correct as far as I know -- BBN Lisp
(predecessor to InterLisp) in mid 1960's.  The arguments I heard in 
later years for justification had more to do with paging behaviour 
of compiled code rather than any other.  It was *not* (emphasize!) for
the purpose of implementing point 2.

Interestingly, VAX/NIL had a modified "structure" for SYMBOLs; it had
been noted in MACSYMA that  big systems could easily contain 2000 or 
more symbols, only a small fraction of which utilised both the function 
cell and the value cell.  So for space saving a kludge was perpetrated in
which every symbol had one cell which was a pointer to either a function 
cell, or a value cell, or a more standard block record of all requisite cells.  
The reason this was "space saving" was that the implementation of
Local-vs-Dynamic and Function-vs-Value are independent, and thus in
fullness, one needs 4 (four!) value cells.  Speed of access isn't an issue, 
since compiled code normally links thru the value cell itself (or function
cell, if you must) rather than thru the symbol header; also, the extra cost
for this "hair" is verry small in terms of VAX instructions.

RE point 2:

Did any of the replies to you so far note that this differentiation was
part of Lisp1.5.?  See page 18 of the "LISP 1.5 Programmer's Manual" where 
the classic scheme is described.   I did not "invent" this scheme.  Neither 
did MacLisp, nor its predecessor PDP6 Lisp, originate it.  It was inherited 
directly from Lisp 1.5 and CTSS Lisp  [remember CTSS?  the "Compatible Time
Sharing System" on a greatly modified IBM 7090?  Most of the Lisp world
remembers only ITS -- "Incompatible Timesharing System" -- and now it too 
is passing away.  Sic Transit Gloria Mundi (sic)]

I venture the opinion that the underlying reason why "uniform" treatment
of identifiers is ever thought to be desirable is that it somewhat simplifies 
the coding and conceptual complexity of the interpreter/system.  There is a
strong series of arguments *against* this "optimisation", made by users of 
said systems.  Dan Bobrow offered the most compelling of these in his 
answer: essentially stated, there is a general expectation that the function
name space is global, unless otherwise stated, and that the variable name 
space is local, unless otherwise stated.  Once this distinction is admitted, 
there is little point in trying to force both meanings into a single "value" 
cell  -- the conceptual simplicity has been forfeited, and since "function 
cell" and "value cell" machinery are isomorphic, there is virtually no 
coding advantage remaining.

FUNCALL/APPLY* have been around "since antiquity" to make the exceptions
for function syntax, but VAX/NIL and current CommonLisp permit local
re-binding of function cells *** as an option;  The Bobrow "general
expectation" is not violated in these systems.   More recently, (i.e., post-1977)
there have been introduced declarations and/or constructs into Interlisp,
LispMachineLisp, VAX/NIL, and CommonLisp to supply the second exception
noted above, namely symbolic constants.

I have frequently offered the observation that this distinction is also
rooted in mathematical notation, where journals generally distinguish
function names from variable names by any of a number of devices:  
such as, slant type-face vs perpendicular, boldface versus regular, or
conventional subsets of letters (e.g., "f" and "G" are clearly function 
names, whereas "x" and "Y" are variable names).   Curiously, I've heard 
that there is a reversal of some of these conventions between the American 
and the European publishers.  Can anyone verify this?)

There seems also to be some confusion about the implementation status of
this "distinction", that variables are by default local.   As far as I know,
this *is* true of all major Lisp implementations I've worked with.  What
isn't true is that that the interpreters of said systems "do the right thing" 
(as opposed to the compiled code environment, which defines the semantics). 
 Almost without exception, the interpreters implement **only** fluid 
bindings.  VAX/NIL had an interpreter that correctly implemented both 
local and fluid variables (see my paper in the 1982 Lisp Conference for a
description of a non-consing scheme to do it).   Many toy interpreters have 
been built which implement distinctions, but do so by consing up the usual
old alist environment, or some equivalent thereof.  Another interesting
interpreter which implements local variables was done prior to 1977 by the
group at IBM Research Center in Yorktown Heights (in Lisp/370), in which
the interpretation of a lambda application did a mini-compilation in order to 
get *exactly* the same stack frame as would be built had the code been truly
compiled; the claim was that you wouldn't see differences between compiled 
and interpreted code in Lisp/370.

More in defense of my conjecture above.:

Bobrow tells me that the first implementation of 940Lisp (the "root
stock" of BBN lisp) was with the function/variable "optimisation" 
mentioned above.  On a small computer, cramped for space, with 
a one-man implementation team  . . .  but the user community 
balked, and convinced the implementor to re-support the 
mathmatically grounded distinction between function context
and value context.  Major Lisp systems today have long passsed
the point where they are one-man projects, but happily haven't 
reached OS syndrome yet (i.e., a system so big, with so many ad-hoc 
extensions and patches, that no one even knows a complete subset 
of people who collectively understand the system).

Several of the SCHEME-lovers have privately expressed the opinion to me
that the value of SCHEME is that it doesn't have a user community (except 
for learners and tinkers), and thus *can* be kept super-simple and "clean".
David Warren, a principle implementor of PROLOG, also expressed (privately)
such an opinion, and will rue the day that the Japanese turn Prolog into 
some kind operating system for 5th Generation hardware.

There will always be difference of viewpoint between those who want to
"muck around" with program semantics and small, "clean" systems, and 
those who want a full complement of "power tools" for doing AI research 
and applications program development.