Received: from csnet-relay by MIT-MC.ARPA.ARPA; 28 Jun 85 22:29:16 EDT Received: from uconn by csnet-relay.csnet id ag09388; 28 Jun 85 22:26 EDT Received: by CARCVAX.ARPA (4.12/) id AA08024; Fri, 28 Jun 85 11:00:26 est Date: Fri, 28 Jun 85 11:00:26 est From: Ben Moreland To: LSPMAI@mit-mc.ARPA 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  Received: from mit-athena by MIT-MC.ARPA 31 May 85 15:11:19 EST Received: from mit-andromache (mit-andromache.ARPA) by mit-athena (4.12/4.7) id AA01959; Fri, 31 May 85 15:13:24 edt Received: by mit-andromache (4.12/4.7) id AA18909; Fri, 31 May 85 15:10:19 edt From: jddevine%mit-andromache@mit-athena.ARPA (Johnathan Devine) Message-Id: <8505311910.AA18909@mit-andromache> 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 Subject: Berkeley Apartment to let for July To: forum@MIT-MC.ARPA 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. -------  Received: from mit-athena by MIT-MC.ARPA; 4 MAY 85 22:38:36 EDT Received: from mit-speaker (mit-speaker.ARPA) by mit-athena (4.12/4.7) id AA09377; Sat, 4 May 85 22:40:51 edt Received: by mit-speaker (4.12/4.7) id AA05705; Sat, 4 May 85 22:37:09 edt From: okeefe%mit-speaker@mit-athena.ARPA (Michael D. O'Keefe) Message-Id: <8505050237.AA05705@mit-speaker> 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)  Received: from SCRC-STONY-BROOK by MIT-MC via Chaosnet; 20 MAR 85 22:29:41 EST Received: from SCRC-RIO-DE-JANEIRO by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 200859; Wed 20-Mar-85 20:01:10-EST Date: Wed, 20 Mar 85 20:01 EST From: Kent M Pitman Subject: defsubst in Maclisp To: Margolin@MIT-MULTICS.ARPA, lisp-forum@MIT-MC.ARPA In-Reply-To: <850320233024.242229@MIT-MULTICS.ARPA> Message-ID: <850320200132.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Wed, 20 Mar 85 18:30 EST From: Barry Margolin 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 Subject: defsubst in Maclisp To: lisp-forum@MIT-MC.ARPA Message-ID: <850320233024.242229@MIT-MULTICS.ARPA> 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 Subject: 6871 partners wanted To: forum@MIT-MC.ARPA 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: DShevitz@MIT-MULTICS.ARPA Subject: televideo terminal help To: forum@MIT-MC.ARPA Message-ID: <850227154120.163844@MIT-MULTICS.ARPA> 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 Subject: Tomos Moped To: forum@MIT-MC.ARPA 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: Joseph.Ginder@cmu-cs-spice.arpa To: wholey@cmu-cs-c.arpa cc: T-Users@yale.arpa, Lisp-Forum@mit-mc.arpa, Common-Lisp@su-ai.arpa Subject: UCLA Perq Message-ID: <1984.10.10.15.38.13.Joseph.Ginder@cmu-cs-spice.arpa> 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 Subject: IBM PC Software Development Positions Available To: forum@MIT-MC.ARPA 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 Subject: Concept-LNZ manual To: forum@MIT-MC.ARPA Does anyone have a Concept-LNZ manual? I would just like to see a summary of its features. Thank you, Michael How -------  Received: ID ; Mon 8 Oct 84 15:51:34-EDT Date: Mon, 8 Oct 1984 15:51 EDT Message-ID: Sender: WHOLEY@CMU-CS-C.ARPA From: Skef Wholey To: Charles Dolan Cc: Common-Lisp@SU-AI.ARPA, Lisp-Forum@MIT-MC.ARPA, T-Users@YALE.ARPA Subject: Benchmark - PERQ CL vs Apollo T In-reply-to: Msg of 8 Oct 1984 13:17-EDT from Charles Dolan Date: Monday, 8 October 1984 13:17-EDT From: Charles Dolan 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 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 cpd@UCLA-LOCUS.ARPA  Received: from Semillon.ms by ArpaGateway.ms ; 11 SEP 84 12:17:57 PDT Date: 11 Sep 84 12:17 PDT From: JonL.pa@XEROX.ARPA Subject: [MJackson.Wbst: Why Your Pascal and Modula-2 Programs Don't Work] To: Guy.Steele@CMU-CS-A.ARPA cc: Bug-Lisp@MIT-MC.ARPA,Lisp-Forum@MIT-MC.ARPA,LispCore^.pa@XEROX.ARPA Reply-to: JonL.pa@XEROX.ARPA 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: LCG.GREEN@DEC-MARLBORO.ARPA Subject: mail list addition To: lisp-forum@MIT-MC.ARPA 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 Subject: Info request: Microcomputer file transfer protocols for PC & UNIX To: forum@MIT-MC.ARPA 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 Subject: where to donate cans???? To: forum@MIT-MC.ARPA 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 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: JONL.PA@PARC-MAXC.ARPA Subject: History of "backquote" macro To: kmp@mit-mc.ARPA, Lisp-Forum@mc.ARPA cc: McDermott@Yale.ARPA, Guy.Steele@cmuc.ARPA, Dick%MIT-OZ@mc.ARPA,, Hewitt@mc.ARPA, gjs@mc.ARPA, Genesereth@Score.ARPA, Masinter.PA@PARC-MAXC.ARPA, JonL.PA@PARC-MAXC.ARPA 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 Subject: Backquote To: kmp@MIT-MC.ARPA Cc: MASINTER.pa@PARC-MAXC.ARPA, LISP-FORUM@MIT-MC.ARPA, Guy.Steele@CMU-CS-A.ARPA, Mcdermott@YALE.ARPA, Genesereth@SU-SCORE.ARPA, Dick%MIT-OZ@MIT-MC.ARPA, Hewitt%MIT-OZ@MIT-MC.ARPA, GJS%MIT-OZ@MIT-MC.ARPA 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: masinter.pa@PARC-MAXC.ARPA Date: 11 Mar 84 16:36:21 PST Subject: Re: Backquote history In-reply-to: KMP@MIT-MC.ARPA's message of 11 Mar 84 16:04 EST To: Kent M Pitman cc: MASINTER.pa@PARC-MAXC.ARPA, LISP-FORUM@MIT-MC.ARPA, Guy.Steele@CMU-CS-A.ARPA, McDermott@YALE.ARPA, Genesereth@SU-SCORE.ARPA, Dick@MIT-OZ.ARPA, Hewitt@MIT-OZ.ARPA, GJS@MIT-OZ.ARPA 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 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 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 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 Actually, it looks like it goes back farther than MDL... Date: 11 Mar 1984 1837-PST From: Gerald Jay Sussman To: Kent M Pitman 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" Subject: Backquote history To: MASINTER.PA@PARC-MAXC.ARPA, lisp-forum@MIT-MC.ARPA 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. => 100 FOO => FOO ,FOO => 100 So you can imagine: (4 ,FOO 5) => (4 100 5) Finally, instead of comma-atsign they have exclamation: => (1 2 3) (3 4 !,FOO 5) => (3 4 1 2 3 5) (3 4 ! 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 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 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: MASINTER.PA@PARC-MAXC.ARPA Subject: Backquote history To: lisp-forum@mit-mc.ARPA 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 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: JonL.pa@PARC-MAXC.ARPA Subject: Function Cells -- the history To: Padget@Utah-20.ARPA cc: Lisp-Forum@MIT-MC.ARPA 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.