Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.39) id AA14766; Wed, 28 Nov 84 11:36:15 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA10120; Wed, 28 Nov 84 11:37:30 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA15208; Wed, 28 Nov 84 11:32:50 pst Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA14658; Wed, 28 Nov 84 11:32:04 pst Message-Id: <8411281932.AA14658@UCB-VAX.ARPA> Date: 28 Nov 84 14:24:42 EST From: Timothy.Glavin@CMU-CS-CAD Subject: cmulisp docs To: BBoard.Maintainer@CMU-CS-A Does anyone know the location of on-line documentation for cmulisp. If not, is there a source for hard copy documentation? I have the Foderaro Franz Lisp Manual, I only looking for info on the CMU ideosyncracies. -- Tim (tg@cad)  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.39) id AA14559; Thu, 15 Nov 84 20:54:48 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA26301; Thu, 15 Nov 84 20:54:46 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA13810; Thu, 15 Nov 84 20:51:49 pst Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA14507; Thu, 15 Nov 84 20:51:52 pst Received: from ucbruby.CC.Berkeley.ARPA (ucbruby.ARPA) by ucbjade.CC.Berkeley.ARPA (4.18/4.27.5) id AA01653; Thu, 15 Nov 84 20:51:05 pst Received: by ucbruby.CC.Berkeley.ARPA (4.18/4.27.6) id AA02961; Thu, 15 Nov 84 20:50:39 pst Date: Thu, 15 Nov 84 20:50:39 pst From: weeks%ucbruby.CC@Berkeley (Harry Weeks) Message-Id: <8411160450.AA02961@ucbruby.CC.Berkeley.ARPA> To: franz-friends@Berkeley Subject: Lisp implementation details. Are there any technical reports or memoranda available which describe the internal workings of Franz? -- Harry  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.39) id AA11832; Thu, 15 Nov 84 18:16:03 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA26224; Thu, 15 Nov 84 18:15:48 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA12102; Thu, 15 Nov 84 18:09:13 pst Received: by UCB-VAX.ARPA (4.24/4.39) id AA11658; Thu, 15 Nov 84 18:09:11 pst Received: from ucscd.UCSC (ucscd.ARPA) by ucscc.UCSC (4.12/4.7) id AA23553; Thu, 15 Nov 84 10:48:02 pst Received: by ucscd.UCSC (4.12/4.7) id AA04900; Thu, 15 Nov 84 10:45:19 pst Date: Thu, 15 Nov 84 10:45:19 pst From: ucscc!pravda%ucscd.ucscc.UUCP@Berkeley (05550000) Message-Id: <8411151845.AA04900@ucscd.UCSC> To: franz-friends%c.CC@Berkeley Subject: mailing list name change Please stop sending to ucscc!figgy instead add ucbvax!ucscc!lispers Thank you.  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.39) id AA22530; Tue, 13 Nov 84 06:23:56 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA22808; Tue, 13 Nov 84 06:23:12 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA04848; Tue, 13 Nov 84 06:20:04 pst Received: from uw-beaver.arpa (uw-beaver.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA05430; Mon, 12 Nov 84 15:45:22 pst Received: by uw-beaver.arpa (4.12/2.2) id AA28549; Mon, 12 Nov 84 15:43:15 pst Return-Path: Received: by ssc-vax (4.12/4.7) id AA03520; Mon, 12 Nov 84 09:58:10 pst Date: Mon, 12 Nov 84 09:58:10 pst From: ssc-vax!steve@uw-beaver.ARPA (Steve White) Message-Id: <8411121758.AA03520@ssc-vax> To: uw-beaver!JonL.pa@XEROX, uw-beaver!smh@mit-eddie Subject: Re: readtable within fasl Cc: uw-beaver!franz-friends@Berkeley My problem was a bit simplier then the general case you mention. In MRS a 'variable' is really a reader-macro ($) that at read time assigns a special value to each variable-base-name. Basically it does a (set (implode `(|$| . ,(explodec name))) 'bl). for side-effects of marking the symbol as a variable. When compiling files containing MRS code the compiler would execute the call inside its environment, placing the *unbound* literals (as .asciz) in the object file to be READ in at load time... so MRS would get the symbols and treat them as symbols not variables. The only reason i mention this is that the workaround used might be useful for others seeking side effects within macros etc. My workaround (h.a.c.k) was to use a special variable liszt-eof-forms as a queue of the above SET forms and to provide a different macro expansion for compile-time. So (setsyntax '|$| 'macro #'(lambda nil (let ((varname (implode `(|$| ,@(explodec (read)))))) (addq `(setq ,varname 'bl) liszt-eof-forms) varname))) ;; return variable name to liszt! [where ADDQ does the correct thing if the variable has already been seen], adds the following to the object file .asciz "$xyz" .asciz "(setq $xyz 'bl)" which basically works (don't gag!) steve white YAP -- (yet another problem) : does anyone at MIT have a list of fixes to franz 38.91 to make the zeta-lisp environment work :-) I started fixing a few things but it looks like something that might MIT may have already done. ((or any plans to put NIL under UNIX? 8-) ))  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.39) id AA20775; Tue, 13 Nov 84 04:28:19 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA22759; Tue, 13 Nov 84 04:27:32 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA04324; Tue, 13 Nov 84 04:26:24 pst Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA20746; Tue, 13 Nov 84 04:25:59 pst Received: from wisdom.BITNET by ucbjade.CC.Berkeley.ARPA (4.17/4.27.5) id AA10274; Tue, 13 Nov 84 04:24:53 pst Received: by wisdom.BITNET (4.12/4.7) id AA01997; Tue, 13 Nov 84 11:29:45 -0200 Date: Tue, 13 Nov 84 11:29:45 -0200 From: jaakov%wisdom.BITNET@Berkeley (Jacob Levy) Message-Id: <8411130929.AA01997@wisdom.BITNET> To: franz-list%wisdom.BITNET@Berkeley Subject: Announcement of new Lisp for UN*X 4.x VAXen I don't know if this is the appropriate place for this announcement, but here goes anyway :- YLISP, a Coroutine-based Lisp System for VAXen. -=============================================- A friend of mine, Yitzhak Dimitrovski, and myself, wrote a Lisp system for UN*X 4.x systems on VAXen. It has the following features :- o - Coroutines and closures. The system uses these to implement the user-interface, single-stepping and error-handling. It's easy to write a scheduler and time-share YLISP between two or more user programs. o - Multiple-dimension arrays. o - Multiple name spaces (oblists) arranged in a tree hierarchy. This is similar to the Lisp Machine facility. o - Defstruct structure definition package. o - Flavors object-oriented programming tools. o - User-extensible evaluator (it is possible to (re)define the actions of 'eval', 'apply' and 'print' relative to all user- and pre-defined types). o - Integer arithmetic. No floating-point, sorry. don't think that that's really necessary, but *could* be hacked. No BIGNUMs either. o - Good user-interface with history, sophisticated error handling and function-call and variable-assignment tracing facilities. o - Extensive library of ported and user-contributed programs,such as a variant of the Interlisp structure editor, 'loop' macro, 'mlisp' Pascal-like embedded language, etc. o - Compiler that generates efficient native assembler code for the VAXen. The compiler is provided as a separate program,due to size considerations. The compiler is written entirely in Lisp, of course. o - Extensive online documentation, as well as a 400-page manual describing the whole system from a programmer's point of view. The system is named 'YLISP', and was written for 4.1 when we were students at the Hebrew University at Jerusalem. Since then, Yitzhak has left for the US and is currently a Ph.D. student in Prof. Schwartz's Supercomputer group at Courant. I have continued to develop the system on my own, and have ported it to UN*X 4.2. I am looking for a site that is willing to handle the distribution of this software from the US, by letting one FTP it from their computer. Alternatively, I am also willing to supply people with magtapes of YLISP, for the cost of the tape and handling charges (about 70$ a piece). If you are interested, please respond by electronic mail to one of the addresses given below. I will be ready to start distributing the system in two weeks' time. Rusty Red (AKA Jacob Levy) BITNET: jaakov@wisdom CSNET and ARPA: jaakov%wisdom.bitnet@wiscvm.ARPA UUCP: (if all else fails..) ..!decvax!humus!wisdom!jaakov  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.39) id AA21504; Sun, 11 Nov 84 19:10:31 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA21063; Sun, 11 Nov 84 19:15:44 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA19376; Sun, 11 Nov 84 19:11:37 pst Received: from udel-relay (udel-gw.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA21463; Sun, 11 Nov 84 19:08:46 pst Message-Id: <8411120308.AA21463@UCB-VAX.ARPA> Received: From udel-dewey.ARPA by udel-relay.ARPA id a010044 ;11 Nov 84 22:09 EST Date: Sun, 11 Nov 84 22:07:41 EST From: johnson To: David.Yaskin@cmu-cs-h.ARPA Cc: franz-friends@Berkeley, johnson%udel-eecis1.delaware@udel-relay.ARPA Subject: Re: Franz Question -------------------- for franz ----------------------------- In franz lisp, 'prinlevel' is a variable controlling the depth to which the top-level is to print lists, 'prinlength' controls how many elements of a list are printed by the top-level. For either variable, a value of 'nil' represents infinite depth or length. If franz is printing expressions as '&' then prinlevel has a value of 0. you should (setq prinlevel nil) to print lists of arbitrary depth. (see Appendix B of the Franz manual) ---------------- for CMU -------------------- In CMULisp, tlprint does the top-level printing, and this is defined, (in, at least the 2 systems that I use) as: '(lambda (x) (printlev x 4)) if your functions always return &, then perhaps someone has defined it as '(lambda (x) (printlev x 0)) if you want to change it you may either: 1. (sstatus translink nil) (defun tlprint (x) (printlev x )) OR, the solution I prefer: 2. (load 'toplevel) ; unnecessary in some installations. (defun tlprint (x) (top-print x)) causing 'prinlevel' and 'prinlength' to have the effect described above for the franz system. NB: the tempting solution: (defun tlprint (x) (printlev x prinlevel)) FAILS in the case that prinlevel is nil -johnson@udel-ee  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.39) id AA01324; Mon, 12 Nov 84 06:44:03 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA21603; Mon, 12 Nov 84 06:49:41 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA22731; Mon, 12 Nov 84 06:45:39 pst Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA01316; Mon, 12 Nov 84 06:42:54 pst Message-Id: <8411121442.AA01316@UCB-VAX.ARPA> Date: 12 Nov 84 09:34:14 EST From: Nancy.Skooglund@CMU-RI-ISL1 Subject: append to file answer found To: BBoard.Maintainer@CMU-CS-A Thanks to all who responded to my Franz lisp question about opening a file for output and appending to it. Here's how it works: (outfile ' 'a) 'a may be replaced by any symbol or string whose name begins with a. Nancy  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.39) id AA21794; Sun, 11 Nov 84 19:30:39 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA21079; Sun, 11 Nov 84 19:35:54 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA19491; Sun, 11 Nov 84 19:31:52 pst Received: from udel-relay (udel-gw.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA21770; Sun, 11 Nov 84 19:29:03 pst Message-Id: <8411120329.AA21770@UCB-VAX.ARPA> Received: From udel-dewey.ARPA by udel-relay.ARPA id a010257 ;11 Nov 84 22:29 EST Date: Sun, 11 Nov 84 22:21:49 EST From: johnson To: Nancy.Skooglund@cmu-ri-isl3.ARPA Cc: franz-friends@Berkeley, johnson%udel-eecis1.delaware@udel-relay.ARPA Subject: Re: opening file for output, append In later versions of franz, 'outfile' takes a second argument; to open a file for appending: (setq portname (outfile ' 'a)) {try: (help outfile) for a full description.} If this does not work on your version, I have a hack that associates a port with ANY open file descriptor, but it uses 4.x system calls, - so don't request it unless the you can't use the new 'outfile' function. -johnson@udel-ee  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.39) id AA15769; Sun, 11 Nov 84 11:55:31 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA20879; Sun, 11 Nov 84 12:00:33 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA16052; Sun, 11 Nov 84 11:57:03 pst Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA15747; Sun, 11 Nov 84 11:54:17 pst Message-Id: <8411111954.AA15747@UCB-VAX.ARPA> Date: 11 Nov 84 00:15:49 EST From: David.Yaskin@CMU-CS-H Subject: Franz Question To: BBoard.Maintainer@CMU-CS-A How does one change the depth and length of list returned from functions. While using CMULisp it keeps returning & instead of my list. David Yaskin ( day@h)  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.39) id AA04505; Fri, 9 Nov 84 12:14:35 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA18678; Fri, 9 Nov 84 12:17:17 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA26238; Fri, 9 Nov 84 12:09:40 pst Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.39) id AA04311; Fri, 9 Nov 84 12:06:51 pst Message-Id: <8411092006.AA04311@UCB-VAX.ARPA> Date: 9 Nov 84 14:02:29 EST From: Nancy.Skooglund@CMU-RI-ISL3 Subject: opening file for output, append To: BBoard.Maintainer@CMU-CS-A Does anyone know how to open a file for output in Franz lisp and @i(append) to that file? The function "outfile" always deletes the old version first. Thanks, Nancy Skooglund  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.31) id AA28957; Thu, 8 Nov 84 16:38:40 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA17759; Thu, 8 Nov 84 16:41:52 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA17894; Thu, 8 Nov 84 16:34:36 pst Received: from Xerox.ARPA (xerox.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA27172; Thu, 8 Nov 84 15:30:06 pst Message-Id: <8411082330.AA27172@UCB-VAX.ARPA> Received: from Burger.ms by ArpaGateway.ms ; 08 NOV 84 15:29:24 PST Date: 8 Nov 84 15:22 PST From: JonL.pa@XEROX.ARPA Subject: Re: readtable within fasl In-Reply-To: Steven M. Haflich 's message of Thu, 8 Nov 84 10:33:41 est To: smh@mit-eddie.ARPA Cc: franz-friends@Berkeley The problems with a user-tailorable READ is one of the reasons why, over 12 years ago, we chose a format for MacLisp's FASL files that is somewhat akin to a position-independent list encoding. (But in fact, it was primarily for speed that the READ-oriented option was abandoned). However, there was still the need to introduce load-time evaluation, in order to create structures that can't be known even faintly at compile time; there is an "internal" marker, accessible to the MacLisp user as a global variable (named SQUID, I believe), so that the portions of a structure that need to be eval'd at load time could be marked. E.g. (FOO 3 '(SOME (DEEPLY NESTING (LIST IN #,LISPSYSTEMDATE)))) and the #, signals a spot for load-time evaluation, even though the overall structure is essentally a QUOTE form. One needn't imagine that #, is the only client of this "internal" marker -- it provides the way to get all but the trivial datatypes into quotified structures; for example, I may have an input syntax for arrays, but still PRINT won't put them out (MacLisp PRINT won't, at least), and certainly not every conceivable datatype needs a special encoding for the FASL file format; merely a LIST, which is viewed as a general program by EVAL, is satisfactory to create any createable datatype instance. Interlisp too has a loadtime evaluation construct, but it may only replace a QUOTE -- not some sub-piece of data underneath a QUOTE, such as indicated by the #, above. A primary reason for this limitation is the similarity of Interlisp's and Franz's compiler output formats -- basically an ascii string to which READ is applied. MacLisp's loader is indeed quite more complex, but it results in a space savings for the FASL files and a considerable time savings when loading them. -- Jon L White --  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.31) id AA25668; Thu, 8 Nov 84 14:25:43 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA17622; Thu, 8 Nov 84 14:29:04 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA16474; Thu, 8 Nov 84 14:24:38 pst Received: from SU-SCORE.ARPA (su-score.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA25584; Thu, 8 Nov 84 14:22:00 pst Message-Id: <8411082222.AA25584@UCB-VAX.ARPA> Date: Thu 8 Nov 84 14:21:16-PST From: Rene Bach Subject: printing delayed in Eunice To: franz-friends@Berkeley Cc: bach@SU-SCORE.ARPA It appears that printing gets delayed in Eunice. What I mean by that is that I have a print statement which should indicate that the system is progressing. However, the system is chugging along, nothing shows for a long while and then the printing happens ALL at ONCE ! As if the output was buffered and go printed when something else needed to be printed. As anyone run across this before ? Is there a flag one needs to set ? Has it to do with Eunice ? What I am printing is just an atom and a ", ". When I print longer stuff, no buffering is noticed. Thanks Rene -------  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.31) id AA22933; Thu, 8 Nov 84 12:21:47 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA17470; Thu, 8 Nov 84 12:25:30 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA15294; Thu, 8 Nov 84 12:17:02 pst Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA22393; Thu, 8 Nov 84 11:59:13 pst Message-Id: <8411081959.AA22393@UCB-VAX.ARPA> Received: by mit-eddie.Mit-chaos.Arpa id AA21531; Thu, 8 Nov 84 12:51:14 est Date: Thu, 8 Nov 84 12:51:14 est From: Steven M. Haflich To: franz-friends@Berkeley Subject: Re: Re: readtable within fasl There was a typo in my previous mailing. The function "explodec" should have been "exploden".  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.31) id AA17130; Thu, 8 Nov 84 07:48:34 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA17161; Thu, 8 Nov 84 07:52:29 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA12925; Thu, 8 Nov 84 07:49:13 pst Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA17112; Thu, 8 Nov 84 07:46:31 pst Message-Id: <8411081546.AA17112@UCB-VAX.ARPA> Received: by mit-eddie.Mit-chaos.Arpa id AA20888; Thu, 8 Nov 84 10:33:41 est Date: Thu, 8 Nov 84 10:33:41 est From: Steven M. Haflich To: franz-friends@Berkeley Subject: Re: readtable within fasl I too was bothered by fasl's insistence on using the standard readtable to process literals in liszt-compiled files until I realized the reason for this limitation: All source input to liszt is processed by `read' -- that is, the compiler reads only forms, never ascii strings. In order to place a literal form in an object file, liszt must essentially convert the form back into ASCII via `print'. (Actually, a somewhat modified version which knows how to wrap an assembler `.asciz' directive around the printed representation of the form, etc.) Unfortunately, liszt can make no easy assumption about what strange readtable is likely to be active at load time, so the only sane choice is to use the standard readtable. In other words, you shouldn't think of literal forms stored in a fasl object file as external (ASCII) representation of lisp data. Rather, liszt/fasl use ASCII as a convenient "position-independent" encoding of a form which has already been processed by read at compile time. This is entirely analogous to what traditional compilers and assemblers do with numeric constants represented in ASCII inside a program, except their compiler-to-loader data format uses the native binary number representation of the object machine. One could argue that this isn't really a limitation provided one is willing and able to provide the desired readtable at compile time. Usually this isn't a problem, although I once I had a macro which wanted to insert into a form a particular uninterned symbol which (obviously) couldn't even exist until execution time. I was forced to wrap the form inside another function which would accomplish the substitution at load time. There is no reason liszt could not be made to copy ASCII forms into the fasl file without read->print translation, but this would require changes to the compiler and to fasl format, things not to be done lightly. If you *really* need the facility, and don't need to read huge volumes of data, you could include ASCII forms inside a fasl file by encoding them as lisp strings, and seeing that they get processed by an appropriate function at load time, something like: (defun strange-read (str) (let ((readtable strange-readtable)) (readlist (explodec str)))) Then you can do things like: (setq foo (strange-read ") a b )c d( e (") [What? You don't like my readtable with the parens reversed?] The invocation of `strange-read' can, of course, be conveniently macrofied. If appropriate, automatic printing of literal strings can also be performed by compile time macros. You will have to deal with the problem of escaping quotes inside these forms, and you might want to enable string garbage collection if you do a lot of this sort of thing. I know it's ugly, but... Steve Haflich  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.31) id AA06518; Wed, 7 Nov 84 19:54:34 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA16593; Wed, 7 Nov 84 19:58:00 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA08630; Wed, 7 Nov 84 19:52:19 pst Received: from uw-beaver.arpa (uw-beaver.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA05368; Wed, 7 Nov 84 18:51:47 pst Received: by uw-beaver.arpa (4.12/2.2) id AA00936; Wed, 7 Nov 84 17:50:03 pst Return-Path: Received: by ssc-vax (4.12/4.7) id AA06915; Wed, 7 Nov 84 17:24:40 pst Date: Wed, 7 Nov 84 17:24:40 pst From: ssc-vax!steve@uw-beaver.ARPA (Steve White) Message-Id: <8411080124.AA06915@ssc-vax> To: uw-beaver!franz-friends@Berkeley Subject: readtable within fasl In "fasl.c" before the literals are read back out of the object file, the readtable is rebound to the 'standard-readtable'. This short-circuits any type of character macro expansion. Does anyone known a workaround for this? In NIL you can specify the readtable associated with the object code, I guess I'm wondering how to mimic this behavior in franz? thanks steve white (ssc-vax!steve@uw-beaver)  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.31) id AA06197; Tue, 6 Nov 84 16:19:42 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA15291; Tue, 6 Nov 84 16:22:39 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA25403; Tue, 6 Nov 84 16:15:33 pst Received: from SCRC-STONY-BROOK.ARPA (scrc-stony-brook.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA06061; Tue, 6 Nov 84 16:12:18 pst Message-Id: <8411070012.AA06061@UCB-VAX.ARPA> Received: from CHAGRIN by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 122057; Tue 6-Nov-84 19:13:41-EST Date: Tue, 6 Nov 84 19:11 EST From: Richard Brenner Subject: Job Opportunities To: maple-sys@Berkeley, symalg%rand-unix.arpa%csnet-relay.arpa@SCRC-CUPID.ARPA, franz-friends@Berkeley In-Reply-To: The message of 6 Nov 84 15:51-EST from Richard Pavelle Symbolics, Inc. of Cambridge is the acknowledged leader in the field of Symbolic Processing, offering the premier LISP-based Symbolic Processor for advanced problem-solving applications. We are a fast-growing, high-tech company with new, modern facilities right in Cambridge. Recent expansion has created opportunities for the following experienced professionals: Member of Technical Staff You will assist with maintenance and enhancement of MACSYMA, a large Computer Algebra System written in LISP and used by engineers and scientists for performing symbolic computations. Immediate projects could include design and implementation of tools for conversion to Common LISP, improving modularity, modernizing the user interface, improving performance, and design and implementation of new mathematical packages based on the latest available algorithms. Work will be performed on all versions of MACSYMA using Symbolics 3600 Family Lisp Machines. A strong background in mathematics and Lisp programming is preferred. Experience with MACSYMA is desirable. Technical Sales Support Engineer You will provide technical support to our internal sales staff, to customers and to prospective customers. Responsibilities include assistance at demonstration sites, installations on several kinds of machines, and a full range of customer support activities. This could include design, development and delivery of a trainging course for MACSYMA users. Qualified applicants will have experience with a high-level language, preferably MACSYMA. Good written and verbal communication skills and prior software project involvement are desired. B.S. degree or equivalent and 2 years experience preferred. Qualified candidates should send their resume,in strict confidence, including salary history, to Gina Setteducati, Personnel Supervisor, Symbolics, Inc., 11 Cambridge Center, Cambridge, MA 02142. An equal opportunity employer.  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.31) id AA14430; Mon, 5 Nov 84 17:32:47 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA14076; Mon, 5 Nov 84 17:35:40 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA14064; Mon, 5 Nov 84 17:32:56 pst Received: by UCB-VAX.ARPA (4.24/4.39) id AA14362; Mon, 5 Nov 84 17:30:11 pst Return-Path: Received: by decvax.UUCP (4.12/1.0) id AA28321; Mon, 5 Nov 84 16:46:11 est Date: Sun, 4 Nov 84 21:23:59 est From: Neal Holtz Message-Id: <8411050223.AA07104@clan. UUCP> Received: by clan. UUCP (4.12/3.14) id AA07104; Sun, 4 Nov 84 21:23:59 est To: nrcaero!dciem!utzoo!decvax!ucbvax!franz-friends@Berkeley Subject: Franz on Apollos (or -- Fritz Kunze, where are you?) Sorry to send this to the newsgroup, but if Fritz (or anyone else, for that matter) can tell me anything about the possibility of having Franz run on Apollo workstations (under AEGIS) in the near future, I would be most appreciative.  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.31) id AA06575; Mon, 5 Nov 84 11:54:51 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA13598; Mon, 5 Nov 84 11:57:44 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA08762; Mon, 5 Nov 84 11:41:38 pst Received: from mitre (mitre.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA06184; Mon, 5 Nov 84 11:38:18 pst Message-Id: <8411051938.AA06184@UCB-VAX.ARPA> Date: 5 Nov 1984 14:17:36 EST (Monday) From: Marshall Abrams Subject: Call for papers: Expert Systems Symposium To: add1.@mitre Cc: abrams@mitre Call for Papers Expert Systems in Government Conference October 23-25, 1985 THE CONFERENCE objective is to allow the developers and implementers of expert systems in goverenment agencies to exchange information and ideas first hand for the purpose of improving the quality of existing and future expert systems in the government sector. Artificial Intelligence (AI) has recently been maturing so rapidly that interest in each of its various facets, e.g., robotics, vision, natural language, supercomputing, and expert systems, has acquired an increasing following and cadre of practitioners. PAPERS are solicited which discuss the subject of the conference. Original research, analysis and approaches for defining expert systems issues and problems such as those identified in the anticipated session topics, methodological approaches for analyzing the scope and nature of expert system issues, and potential solutions are of particular interest. Completed papers are to be no longer than 20 pages including graphics and are due 1 May 1985. Four copies of papers are to be sent to: Dr. Kamal Karna, Program Chairman MITRE Corporation W852 1820 Dolley Madison Boulevard McLean, Virginia 22102 Phone (703) 883-5866 ARPANET: Karna @ Mitre Notification of acceptance and manuscript preparation instructions will be provided by 20 May 1985. THE CONFERENCE is sponsored by the IEEE Computer Society and The MITRE Corporation in cooperation with The Association for Computing Machinery, The american Association for Artificial Intelligence and The American Institute of Aeronautics and Astronautics National Capital Section. This conference will offer high quality technical exchange and published proceedings. It will be held at Tyson's Westpark Hotel, Tysons Corner, McLean, VA, suburban Washington, D.C. TOPICS OF INTEREST The topics of interest include the expert systems in the following applications domains (but are not limited to): 1. Professional: Accounting, Consulting, Engineering, Finance, Instruction, Law, Marketing, Management, Medicine Systems, Intelligent DBMS 2. Office Automation: Text Understanding, Intelligent 3. Command & Control: Intelligence Analysis, Planning, Targeting, Communications, Air Traffic Control 4. Exploration: Space, Prospecting, Mineral, Oil Archeology 5. Weapon Systems: Adaptive Control, Electronic Warfare, Star Wars, Target Identification 6. System Engineering: Requirements, Preliminary Design, Critical Design, Testing, and QA 7. Equipment: Design Monitoring, Control, Diagnosis, Maintenance, Repair, Instruction 8. Project Management: Planning, Scheduling, Control 9. Flexible Automation: Factory and Plan Automation 10. Software: Automatic Programming, Specifications, Design, Production, Maintenance and Verification and Validation 11. Architecture: Single, Multiple, Distributed Problem Solving Tools 12. Imagery: Photo Interpretation, Mapping, etc. 13. Education: Concept Formation, Tutoring, Testing, Diagnosis, Learning 14. Entertainment and Intelligent Games, Investment and Expert Advice Giving: Finances, Retirement, Purchasing, Shopping, Intelligent Information Retrieval  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.31) id AA04827; Sun, 4 Nov 84 23:24:36 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA12821; Sun, 4 Nov 84 23:27:41 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA03125; Sun, 4 Nov 84 23:25:12 pst Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA04781; Sun, 4 Nov 84 23:22:27 pst Received: from ucb-vax.arpa by csnet-relay.arpa id a006482; 5 Nov 84 2:21 EST Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA04236; Sun, 4 Nov 84 22:58:35 pst Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA) by ucbjade.CC.Berkeley.ARPA (4.17/4.27.2) id AA14292; Sun, 4 Nov 84 22:59:18 pst Received: by ucbopal.CC.Berkeley.ARPA (4.17/4.28) id AA03601; Sun, 4 Nov 84 22:59:26 pst Date: Sun, 4 Nov 84 22:59:26 pst From: Fritz Kunze Message-Id: <8411050659.AA03601@ucbopal.CC.Berkeley.ARPA> To: franz-friends%ucb-vax.arpa%csnet-relay.arpa@csnet-relay.ARPA, holtz%carleton.cdn%ubc.csnet%csnet-relay.arpa@csnet-relay.ARPA Subject: Re: Franz on Apollos (or, Fritz Kunze, where are you?) We are working on an Apollo port right now. Due to some non-standard features in the Apollo operating system, the port is requiring far more time than we originally anticipated. We are very close to a working interpreter, but the compiler will require more time. Are you interested in the Interpreter first? ---Fritz Kunze Franz Inc. 2920 Domingo, suite 203 Berkeley, CA 94705 (415) 540-1224  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.31) id AA04557; Sun, 4 Nov 84 14:40:50 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA12450; Sun, 4 Nov 84 14:43:31 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA03203; Sun, 4 Nov 84 14:39:06 pst Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA04466; Sun, 4 Nov 84 14:36:25 pst Received: from ubc by csnet-relay.csnet id a004399; 4 Nov 84 15:43 EST Date: Sun, 4 Nov 84 12:37:03 pst Received: by ubc-ean.UUCP id AA17658; Sun, 4 Nov 84 12:37:03 pst From: Neal Holtz To: franz-friends%ucb-vax.arpa@csnet-relay.ARPA Mmdf-Warning: Parse error in preceding line at CSNET-RELAY.ARPA Message-Id: 133:holtz@carleton.cdn Subject: Franz on Apollos (or, Fritz Kunze, where are you?) Sorry to send this to the newsgroup, but if Fritz (or anyone else, for that matter) can tell me anything about the possibility of having Franz run on Apollo workstations (under AEGIS) in the near future, I would be most appreciative.  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.31) id AA04561; Sun, 4 Nov 84 14:41:04 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA12453; Sun, 4 Nov 84 14:43:40 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA03212; Sun, 4 Nov 84 14:39:20 pst Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA04473; Sun, 4 Nov 84 14:36:37 pst Received: from ubc by csnet-relay.csnet id a004408; 4 Nov 84 15:45 EST Date: Sun, 4 Nov 84 12:37:03 pst Received: by ubc-ean.UUCP id AA17658; Sun, 4 Nov 84 12:37:03 pst From: Neal Holtz To: franz-friends%ucb-vax.arpa@csnet-relay.ARPA Mmdf-Warning: Parse error in preceding line at CSNET-RELAY.ARPA Message-Id: 133:holtz@carleton.cdn Subject: Franz on Apollos (or, Fritz Kunze, where are you?) Sorry to send this to the newsgroup, but if Fritz (or anyone else, for that matter) can tell me anything about the possibility of having Franz run on Apollo workstations (under AEGIS) in the near future, I would be most appreciative.  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.31) id AA08904; Thu, 1 Nov 84 16:03:26 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA08432; Thu, 1 Nov 84 16:04:25 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA05698; Thu, 1 Nov 84 16:02:58 pst Received: from WISCVM.ARPA (wiscvm.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA08850; Thu, 1 Nov 84 16:00:19 pst Message-Id: <8411020000.AA08850@UCB-VAX.ARPA> Received: from ENG20201@BOSTONU.BITNET by WISCVM.ARPA on 11/01/84 at 18:00:40 CST Date: 1-Nov-84 18:58:53 EST From: John Sutter Subject: Pretty typer To: franz-friends@Berkeley Cc: eng20201%BOSTONU.bitnet@WISCVM.ARPA ----- Does anyone know of a pretty typer for Franz Lisp?.. If you do, please reply to me directly. Thanks ---- John -----  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.31) id AA04483; Wed, 31 Oct 84 18:39:24 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA07031; Wed, 31 Oct 84 17:57:22 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA14939; Wed, 31 Oct 84 17:37:36 pst Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA02960; Wed, 31 Oct 84 17:14:37 pst Message-Id: <8411010114.AA02960@UCB-VAX.ARPA> Date: 31 Oct 84 20:08:41 EST From: Ingemar.Hulthage@CMU-RI-ISL2 Subject: Floating point division To: BBoard.Maintainer@CMU-CS-A Is there a pre-defined function in Franz Lisp that never uses integer division when it differs from floating point division ? Obviously it is easy to write (quotient (float a) b) or to write a function/macro with the same effect. However, since Franz does a good job of dealing with different kinds of numbers in other cases, it is inconvenient and inefficient if such a function is not available in the system.  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.31) id AA15324; Wed, 31 Oct 84 12:43:38 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA06662; Wed, 31 Oct 84 12:44:40 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA09034; Wed, 31 Oct 84 12:40:33 pst Received: from wisc-crys.arpa (wisc-crys.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA15180; Wed, 31 Oct 84 12:37:38 pst Received: from wisc-ai.uwisc by wisc-crys.arpa; Wed, 31 Oct 84 14:35:47 cst Date: Wed, 31 Oct 84 14:35:55 cst From: neves%wisc-ai.uwisc@wisc-crys.ARPA (David Neves) Message-Id: <8410312035.AA25488@wisc-ai.uwisc> Received: by wisc-ai.uwisc; Wed, 31 Oct 84 14:35:55 cst To: franz-friends@Berkeley Subject: re: Indenting lisp code in VI Thanks for the response on indenting for Franz. It seems as though our systems people do not use Lisp and so have set up everyone's .exrc file to map = to something else. Your site might be doing the same thing to this or other VI/Lisp features! Stop them now.  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.31) id AA13739; Wed, 31 Oct 84 11:36:45 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA06544; Wed, 31 Oct 84 11:37:35 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA07802; Wed, 31 Oct 84 11:35:57 pst Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA13682; Wed, 31 Oct 84 11:33:13 pst Received: from bostonu by csnet-relay.csnet id ac00303; 31 Oct 84 14:27 EST Received: by csvaxa.ARPA (4.12/4.7) id AA14678; Wed, 31 Oct 84 13:53:18 est Date: Wed, 31 Oct 84 13:53:18 est From: Rafail Ostrovsky Message-Id: <8410311853.AA14678@csvaxa.ARPA> To: FRANZ-FRIENDS%ucb-vax.arpa@csnet-relay.ARPA Subject: MAILING LIST Hello. I would like to subscribe to your mailing list. I am a grad. student at Boston U. My address is: raf%bostonu.csnet@CSNET-RELAY.CSNET Thank you, -Raf  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.31) id AA07060; Wed, 31 Oct 84 05:54:27 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA05598; Wed, 31 Oct 84 05:55:30 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA04156; Wed, 31 Oct 84 05:54:58 pst Received: from udel-relay (udel-gw.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA07029; Wed, 31 Oct 84 05:52:24 pst Message-Id: <8410311352.AA07029@UCB-VAX.ARPA> Received: From udel-dewey.ARPA by udel-relay.ARPA id a018834 ;31 Oct 84 8:55 EST Date: Wed, 31 Oct 84 8:47:19 EST From: johnson To: franz-friends@Berkeley Cc: johnson%udel-dewey.delaware@udel-relay.ARPA Subject: response to lisp/vi question in response to: >I would like to use "=" in VI to indent my lisp code. When I >type "=" in front of some lisp code I get >No alternate filename to substitute for #0 >How do I indent Lisp code (besides using autoindent)? 1. When I type "=" in vi (without :set lisp) I get no response at all. Is it possible that you defined a macro named "=" ? { check your ~/.exrc file for a line beginning: :map = } 2. Even after: :set lisp A single "=" does not seem to cause the correct action, however, two successive "="s do. to summarize: 1. remove any mapping of "=" from ~/.exrc 2. :set lisp 3. use "==" rather than "=" - johnson@udel-ee  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.31) id AA27805; Tue, 30 Oct 84 14:45:41 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA04597; Tue, 30 Oct 84 15:46:11 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA04963; Tue, 30 Oct 84 14:38:15 pst Received: from wisc-crys.arpa (wisc-crys.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA27563; Tue, 30 Oct 84 14:36:12 pst Received: from wisc-ai.uwisc by wisc-crys.arpa; Tue, 30 Oct 84 16:35:00 cst Date: Tue, 30 Oct 84 16:34:59 cst From: neves%wisc-ai.uwisc@wisc-crys.ARPA (David Neves) Message-Id: <8410302234.AA21547@wisc-ai.uwisc> Received: by wisc-ai.uwisc; Tue, 30 Oct 84 16:34:59 cst To: franz-friends@Berkeley Subject: vi/franz question This is a vi/franz question. I would like to use "=" in VI to indent my lisp code. When I type "=" in front of some lisp code I get No alternate filename to substitute for #0 How do I indent Lisp code (besides using autoindent)? -Thanks, David  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.31) id AA25884; Tue, 30 Oct 84 13:22:17 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA04440; Tue, 30 Oct 84 14:22:53 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA03406; Tue, 30 Oct 84 13:18:32 pst Received: from tove.ARPA (tove.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA24224; Tue, 30 Oct 84 12:15:01 pst Received: by tove.ARPA (4.12/4.7) id AA09504; Thu, 25 Oct 84 16:46:39 edt From: Liz Allen Message-Id: <8410252046.AA09504@tove.ARPA> Date: 25 Oct 1984 1646-EDT (Thursday) To: Rene Bach Cc: franz-friends@Berkeley Subject: Re: A question In-Reply-To: Your message of Thu 25 Oct 84 09:31:09-PDT. <8410251628.AA00848@UCB-VAX.ARPA> From: Rene Bach I am new on this list and haven't seen any other messages. There isn't too much mail here. Is there a way to find out what are all the atoms which have been defined in Franz (a la mapatoms of INterlisp) ?? The functions (oblist) returns a list of all the atoms. -Liz  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.31) id AA24566; Tue, 30 Oct 84 12:27:20 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA04361; Tue, 30 Oct 84 13:27:33 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA02909; Tue, 30 Oct 84 12:19:45 pst Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.31) id AA23363; Tue, 30 Oct 84 11:43:13 pst Received: by ucbmike.arpa (4.24ucb/4.33) id AA04265; Tue, 30 Oct 84 12:43:39 pst Date: Tue, 30 Oct 84 12:43:39 pst From: John Foderaro (on a sun) Message-Id: <8410302043.AA04265@ucbmike.arpa> To: mrose%udel-dewey.delaware@udel-relay.ARPA, franz-friends@Berkeley Subject: Re: Where is franz-friends-request In-Reply-To: Your message of 28 Oct 84 10:04:05 EST (Sun) franz-friends-request@berkeley is valid. occasionlly the mailer tries to look in the alias table while it is being updated.  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.31) id AA06125; Sun, 28 Oct 84 06:13:36 pst Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA02604; Sun, 28 Oct 84 07:17:33 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA23230; Sun, 28 Oct 84 07:14:21 pst Received: from udel-relay (udel-gw.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA06117; Sun, 28 Oct 84 06:12:32 pst Received: From udel-dewey.ARPA by udel-relay.ARPA id a018166 ;28 Oct 84 10:15 EST Received: From localhost.DELAWARE by udel-dewey.DELAWARE id a026308 ;28 Oct 84 10:04 EST To: franz-friends@Berkeley Subject: Where is franz-friends-request Date: 28 Oct 84 10:04:05 EST (Sun) Message-Id: <4057.467823845@udel-dewey> From: Marshall Rose I tried to send to Franz-Friends-Request@Berkeley but got back a rejection notice from the UCB server. Could someone tell me where the -Request address for Franz-Friends is? Thanks, /mtr ps: sorry to bother the list with this.  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.31) id AA03881; Fri, 26 Oct 84 11:27:06 pdt Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA01260; Fri, 26 Oct 84 11:39:30 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA26814; Fri, 26 Oct 84 11:33:45 pdt Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA03817; Fri, 26 Oct 84 11:23:44 pdt Received: from PSUVAX1.BITNET by ucbjade.CC.Berkeley.ARPA (4.17/4.26) id AA09108; Fri, 26 Oct 84 11:31:53 pdt Date: Fri, 26 Oct 84 11:31:52 pdt Message-Id: <8410261831.AA09108@ucbjade.CC.Berkeley.ARPA> From: rznowski@PSUVAX1 To: franz-friends@Berkeley Subject: removing me from mailing lists Please remove my name from the mailing lists. Thanks, Stephen J. Roznowski Pennsylvania State University allegra, burdvax, akgua, ihnp4 !psuvax!rznowski  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.31) id AA29475; Fri, 26 Oct 84 07:40:52 pdt Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA01135; Fri, 26 Oct 84 07:53:10 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA24795; Fri, 26 Oct 84 07:49:06 pdt Received: from utah-cs.ARPA (utah-gateway.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA29434; Fri, 26 Oct 84 07:39:02 pdt Received: by utah-cs.ARPA (4.19/3.33.3) id AA10499; Fri, 26 Oct 84 08:41:07 mdt Date: Fri, 26 Oct 84 08:41:07 mdt From: shebs@utah-cs (Stanley Shebs) Message-Id: <8410261441.AA10499@utah-cs.ARPA> To: BACH@SU-SCORE.ARPA, franz-friends@Berkeley Subject: Re: A question Probably a million other people have answered this question, but here goes - the oblist function (with no args) returns a list of all interned atoms, in some random order (the natural hash order I suppose). It's very entertaining to examine in detail... stan shebs  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.31) id AA22355; Fri, 26 Oct 84 01:21:23 pdt Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA00898; Fri, 26 Oct 84 01:33:29 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA23455; Fri, 26 Oct 84 01:25:13 pdt Received: by UCB-VAX.ARPA (4.24/4.31) id AA22246; Fri, 26 Oct 84 01:15:05 pdt Date: Fri, 26 Oct 84 01:15:05 pdt From: trwrb!logico!ron@Berkeley Message-Id: <8410260815.AA22246@UCB-VAX.ARPA> To: franz Subject: Franz Lisp Acquisition I would like to acquire a copy of Franz lisp. Could you possibly send me a copy or at least send me return mail so that we can discuss the details of transfer? Ron Moore (818) 887-4950 Logicon, Operating Systems Division 6300 Variel Ave. Suite H Woodland Hills, Ca. 91367 {the.world}!trwrb!logico!ron  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.31) id AA01233; Thu, 25 Oct 84 09:44:29 pdt Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA00266; Thu, 25 Oct 84 09:55:55 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA12454; Thu, 25 Oct 84 09:43:48 pdt Received: from Ucl-Cs (900000e) by UCB-VAX.ARPA (4.24/4.31) id AA00971; Thu, 25 Oct 84 09:32:30 pdt Received: from edxa.ac.uk by 44d.Ucl-Cs.AC.UK via Janet with NIFTP id a016323; 25 Oct 84 10:55 BST From: DALTON FHL (on ERCC DEC-10) Date: Thursday, 25-Oct-84 9:53:56-BST Message-Id: <131656-323-135@EDXA> To: wah , Franz-Friends@edxa, J.Dalton%edxa@ucl-cs.ARPA Subject: User-defined Mapping Functions -------- Wilson, As I understand it, you end up with something like: (defun mapappend (func lst) (apply (function append) (mapcar func lst))) (defun anyequalp (atm lst) (mapappend (function (lambda (x) (and (equal atm x) (list x)))) lst)) And then... | Things work great. NOW, I try to compile my code and I get the following | messages (paraphased) ... | anyequalp: Warning: in line lambda (some huge number) | Warning: atm declared special by compiler. It turns out that the compiler does handle the built-in mapping functions specially: it treats them as macros that expand into do-loops. This is why no in-line-lambda is created in that case. When it *is* created, the compiler forgets most of the context from which it came and treats it as a separate function. Then, the use of 'atm' in the local function is no longer seen to refer to the 'atm' in 'anyequalp'. The compiler notices that 'atm' is used without being bound to anything (say by being a formal parameter of the function and thus bound to the corresponding argument) and, so it has some chance of referring to something, declares it special. This would work perfectly except that the 'atm' in 'anyequalp' is not special; if you were to put a (declare (special atm)) before the definition of 'anyequalp', everything would work out. It works fine in the interpreter because then all variables are essentially 'special'. (I guess I'm assuming here that you know what special variables are.) Whether this should be called a bug is not clear. In a Lisp that properly implements lexical scoping (e.g. Common Lisp, T), the "textual" context of the local lambda would make a difference and you would not need the 'special' declaration. Another approach would be to require such declarations in the interpreter as well. However, Lisp has traditionally taken a more expedient, although perhaps less correct, approach, as in Franz. If you want to avoid special declarations altogether, you could define 'mapappend' as a macro instead: (defmacro mapappend (fn &rest lists) `(apply #'append (mapcar ,fn . ,lists))) This also has the advantage of making it easy to define it so that the function can be mapped over several lists at once, as in the built-in mapping functions. Hope this is helpful, Jeff Dalton Dept. of Artificial Intelligence University of Edinburgh --------  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.31) id AA12295; Thu, 25 Oct 84 17:49:49 pdt Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA00550; Thu, 25 Oct 84 18:01:23 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA18268; Thu, 25 Oct 84 17:53:20 pdt Received: from tove.ARPA (tove.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA11490; Thu, 25 Oct 84 17:07:37 pdt Received: by tove.ARPA (4.12/4.7) id AA10909; Thu, 25 Oct 84 20:15:12 edt From: Mark Weiser Message-Id: <8410260015.AA10909@tove.ARPA> Date: 25 Oct 1984 2014-EDT (Thursday) To: Mike Caplinger Cc: info-pyramid@maryland.ARPA, franz-friends@Berkeley Subject: Re: Franz for the Pyramid? In-Reply-To: Your message of Thu, 25 Oct 84 15:10:33 CDT. Rutgers was working on this with Pyramid, and supposedly it was going to be free to Pyramid owners. We were supposed to get a Beta copy at maryland a couple months ago but nothing ever happened, supposedly because the bugs were too severe to make it past alpha, but who knows for sure. The Pyramid is a very good architecture for Franz, it ought to be fast, if and when...  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.31) id AA07178; Thu, 25 Oct 84 13:23:32 pdt Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA00412; Thu, 25 Oct 84 13:35:07 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA14938; Thu, 25 Oct 84 13:28:45 pdt Received: from rice.ARPA (rice.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA07059; Thu, 25 Oct 84 13:18:30 pdt Received: from iapetus by rice.ARPA (AA01419); Thu, 25 Oct 84 15:19:47 CDT Received: by iapetus (AA10543); Thu, 25 Oct 84 15:15:22 CDT Date: Thu, 25 Oct 84 15:10:33 CDT From: Mike Caplinger Subject: Franz for the Pyramid? To: info-pyramid@maryland.ARPA, franz-friends@Berkeley Message-Id: Does anyone know of an implementation of Franz for the Pyramid 90/X? If so, is it easily available (ie, cheap)?  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.31) id AA01070; Thu, 25 Oct 84 09:36:50 pdt Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA00255; Thu, 25 Oct 84 09:47:59 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA12433; Thu, 25 Oct 84 09:38:27 pdt Received: from SU-SCORE.ARPA (su-score.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA00848; Thu, 25 Oct 84 09:28:13 pdt Message-Id: <8410251628.AA00848@UCB-VAX.ARPA> Date: Thu 25 Oct 84 09:31:09-PDT From: Rene Bach Subject: A question To: franz-friends@Berkeley I am new on this list and haven't seen any other messages. Is there a way to find out what are all the atoms which have been defined in Franz (a la mapatoms of INterlisp) ?? Thanks Rene -------  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.31) id AA18152; Wed, 24 Oct 84 07:41:56 pdt Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA29549; Wed, 24 Oct 84 07:52:35 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA24063; Wed, 24 Oct 84 07:50:45 pdt Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA18126; Wed, 24 Oct 84 07:40:41 pdt Message-Id: <8410241440.AA18126@UCB-VAX.ARPA> Date: 24 Oct 84 10:42:57 EDT From: Wilson.Harvey@CMU-CS-IUS Subject: Franz lisp question (again) To: BBoard.Maintainer@CMU-CS-A I was wondering if someone could suggest a solution to the following problem: I want a franz lisp function to find all the occurences of an atom in a list. So, I write a function anyequalp ... (defun anyequalp (atm lst) (mapcar (function (lambda (x) (and (equal atm x) x))) lst)) This works fine. I compile the code and get no warnings or errors, and the code even works. What I really want are ONLY those elements in the list that satisfy the predicate. So, I rewrite the function this way ... (defun anyequalp (atm lst) (mapcan (function (lambda (x) (and (equal atm x) (list x)))) lst)) This works fine (even when compiled), except I really want a non-destructive version that will put the list together using "append" instead of "nconc". So, I write the function "mapappend" as ... (defun mapappend (func lst) (apply (function append) (mapcar func lst))) I substitue "mapappend" for "mapcan" in my function definition for anyequalp. Things work great. NOW, I try to compile my code and I get the following messages (paraphased) ... anyequalp: Warning: in line lambda (some huge number) Warning: atm declared special by compiler. Not suprisingly, when the code runs now, it does not work correctly. Does the compiler know about the mapping functions and take special actions with them? Is there a way I can get the compiler to accept my version of mapappend and make it behave like mapcan? Is this a bug that allows me to do something with the mapping functions that I'm not supposed to be able to do? Can 10000 angels really fit on the end of a pinpoint, or is there really only room for one? I realize all this could be avoided by writing the function iteratively, but I'd like to know why my version doesn't work before I discard the idea.  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.31) id AA15713; Thu, 18 Oct 84 10:12:19 pdt Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA21462; Thu, 18 Oct 84 10:20:52 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA10999; Thu, 18 Oct 84 10:19:51 pdt Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA15671; Thu, 18 Oct 84 10:10:00 pdt Message-Id: <8410181710.AA15671@UCB-VAX.ARPA> Date: 18 Oct 84 13:18:30 EDT From: Hans.Tallis@CMU-RI-ML Subject: to lower case To: BBoard.Maintainer@CMU-CS-A Sorry for the extra post, but I couldn't mail to jkf. --What is the function to convert to lower case? --Hans  Received: from ucbmike.arpa by UCB-VAX.ARPA (4.24/4.31) id AA13915; Thu, 18 Oct 84 08:42:12 pdt Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.arpa (4.24ucb/4.33) id AA21330; Thu, 18 Oct 84 08:50:46 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA09703; Thu, 18 Oct 84 08:50:36 pdt Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.31) id AA13896; Thu, 18 Oct 84 08:40:53 pdt Message-Id: <8410181540.AA13896@UCB-VAX.ARPA> Date: 18 Oct 84 11:45:05 EDT From: Hans.Tallis@CMU-RI-ML Subject: case conversion To: BBoard.Maintainer@CMU-CS-A Can someone tell me how to convert character cases in Franz? E.g., switching all to upper case or all to lower case. I want to do this on command, so I don't want to change the reader syntax to convert everything to upper case automatically. Franz gives a function for going one way, namely (ascii), but I'm stuck about going in the other direction. A speedy reply, either positive or negative, would be appreciated. --tallis@a or tallis@ml  Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.24/4.33) id AA01100; Fri, 17 Aug 84 16:48:52 pdt Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.ARPA (4.24ucb/3.5) id AA08513; Fri, 17 Aug 84 16:47:40 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA00202; Fri, 17 Aug 84 16:44:40 pdt Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.33) id AA01032; Fri, 17 Aug 84 16:45:24 pdt Received: From ucf.csnet by csnet-relay; 17 Aug 84 19:26 EDT Received: by ucf-cs.UUCP (4.12/4.7) id AA00852; Fri, 17 Aug 84 15:29:05 edt Date: Fri, 17 Aug 84 15:29:05 edt From: Ben Goldfarb Message-Id: <8408171929.AA00852@ucf-cs.UUCP> To: franz-friends@Berkeley Subject: ChangeLog The ReadMe file in /usr/src/cmd/ucb/lisp states that there are ChangeLog files in the subdirectories franz and liszt. We got no such files on our distribution tape (Berkeley 4.2bsd). I'd appreciate receiving copies of these files, along with any other documentation of differences between the 4.2 version and prior versions of Franz Lisp. Thanks, Ben Goldfarb University of Central Florida uucp: {duke,decvax,princeton}!ucf-cs!goldfarb ARPA: goldfarb.ucf-cs@csnet.relay csnet: goldfarb@ucf  Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.24/4.33) id AA13501; Wed, 15 Aug 84 22:54:58 pdt Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.ARPA (4.24ucb/3.5) id AA05081; Wed, 15 Aug 84 22:54:21 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA04730; Wed, 15 Aug 84 22:49:17 pdt Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33) id AA13406; Wed, 15 Aug 84 22:49:59 pdt Message-Id: <8408160549.AA13406@UCB-VAX.ARPA> Date: 16 August 1984 01:49-EDT From: Richard Mlynarik Subject: on the issue of the "ATOMness" of hunks To: PSZ@MIT-MC Cc: ALAN@MIT-MC, GSB@MIT-MC, JonL.pa@XEROX, franz-friends@Berkeley, smh@MIT-EMS In-Reply-To: Msg of 14 Aug 1984 16:37-EDT from Peter Szolovits From: Peter Szolovits I have a small quarrel with Alan Bawden's statement that "hunks never being atoms in Maclisp" is a universally-agreed bug. There are indeed useful structures that one would like to build in Lisp that act as CONS cells (i.e., CAR and CDR are applicable), but that can have further structure. I have sorely missed such objects in Lisp Machine Lisp and NIL, where flavor-instances are always atomic, when I wanted to build Brand X (interned "list structure" and universal property lists). In Maclisp, I could do this using hunks, though even that was not completely right because I wanted to be able to disallow RPLACA and RPLACD while allowing CAR and CDR, and this was hard, given the hunk abstraction. I would, however, love to have non-atomic flavor-instances The MIT lisp machine system makes some attempt to "support" this sort of thing, by sending :CAR, :CDR, etc messages to instances. The result is that you get an error about an unclaimed message, rather than one about an attempt to take the car of a non-nil atom. LISTP and CONSP both still return NIL when applied to an instance. The way to get RPLACA (or SETF of CAR), etc to not work is simply to not define methods for doing these operations... Is is not really clear to me what the value of such is, unless you get tired of typing too many "(SEND"'s.  Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.24/4.33) id AA11202; Wed, 15 Aug 84 20:00:03 pdt Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.ARPA (4.24ucb/3.5) id AA04954; Wed, 15 Aug 84 19:52:59 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA02844; Wed, 15 Aug 84 19:49:22 pdt Received: from Xerox.ARPA (xerox.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33) id AA10989; Wed, 15 Aug 84 19:50:13 pdt Message-Id: <8408160250.AA10989@UCB-VAX.ARPA> Received: from Semillon.ms by ArpaGateway.ms ; 15 AUG 84 19:48:41 PDT Date: 15 Aug 84 15:00 PDT From: JonL.pa@XEROX.ARPA Subject: Re: (atom VECTOR): franz vs liszt In-Reply-To: "smh@mit-ems"@MIT-MC.ARPA's message of 14 Aug 84 08:40:00 EDT To: "smh@mit-ems"@MIT-MC.ARPA Cc: ALAN@MIT-MC.ARPA, GSB@MIT-MC.ARPA, JonL.pa@XEROX.ARPA, franz-friends@Berkeley MacLisp indeed does have VECTORs, STRINGs, CLASSes, etc. in an extended SmallTalk-like hierarchy, but they are not in the initial system. Some of these used to have autoload properties, but I'm not sure about the state of things now. None of the extended stuff got documented in the 1983 MacLisp manual, mostly because of Pitman's personal preferences for not using the extended stuff. HUNKs are relevant, because the extended heirarchy uses the USRHUNK feature in order to cause system functions to "trap out" on hunks, thereby viewing them in an object-oriented way rather than as lists (Glaaaag!) or as mere simple vectors. -- JonL --  Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.24/4.33) id AA09735; Wed, 15 Aug 84 18:26:07 pdt Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.ARPA (4.24ucb/3.5) id AA04840; Wed, 15 Aug 84 18:25:21 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA02292; Wed, 15 Aug 84 18:21:08 pdt Received: from Xerox.ARPA (xerox.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33) id AA09647; Wed, 15 Aug 84 18:21:57 pdt Message-Id: <8408160121.AA09647@UCB-VAX.ARPA> Received: from Semillon.ms by ArpaGateway.ms ; 15 AUG 84 18:18:31 PDT Date: 15 Aug 84 18:18 PDT From: JonL.pa@XEROX.ARPA Subject: Re: bug in assoc In-Reply-To: "smh@mit-ems"@MIT-MC.ARPA's message of 14 Aug 84 17:13:29 EDT To: "smh@mit-ems"@MIT-MC.ARPA Cc: "mcgeer@ucbkim"@Berkeley, franz-friends@Berkeley, "jmiller@ct.csnet@udel-relay"@MIT-MC.ARPA, Common-Lisp@SU-AI.ARPA Common Lisp also faces the possibility of inconsistent system code due to the handling of cases marked "is an error" (see Manual, sec. 1.2.4); that is, it is undefined as to what happens if you apply CAR to a non-LISTP. All portable system code should therefore certify the type of a datum before taking car or cdr. ASSOC (and ASSQ) from the Franz sources clearly doesn't check the type of the arguments before carcdring away on them. Well, why not "all system code should certify the type before taking car/cdr . . . " -- it certainly can't hurt to "signal an error" rather than fall into some undefined morass. -- JonL --  Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.24/4.33) id AA07833; Wed, 15 Aug 84 16:45:44 pdt Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.ARPA (4.24ucb/3.5) id AA04642; Wed, 15 Aug 84 16:44:34 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA00784; Wed, 15 Aug 84 16:33:44 pdt Received: from Xerox.ARPA (xerox.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33) id AA05115; Wed, 15 Aug 84 14:20:30 pdt Message-Id: <8408152120.AA05115@UCB-VAX.ARPA> Received: from Semillon.ms by ArpaGateway.ms ; 15 AUG 84 14:19:35 PDT Date: 15 Aug 84 14:18 PDT From: JonL.pa@XEROX.ARPA Subject: Re: (atom VECTOR): franz vs liszt In-Reply-To: Alan Bawden 's message of 13 Aug 84 20:08 EDT To: ALAN@MIT-MC.ARPA Cc: JonL.pa@XEROX.ARPA, GSB@MIT-MC.ARPA, franz-friends@Berkeley, smh@MIT-EMS.ARPA [Ah, confusion with Interlisp here]. I meant to say "The resolution was some awful switch setting for whether or not to treat them as LISTs" rather than "to treat them as ATOMs". The switch name is HUNKP. Interlisp's ATOM predicate is defined simply as (NOT (LISTP x)), and LISTP is true only of cons cells [thus (LISTP NIL) is false]. -- JonL --  Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.24/4.33) id AA04411; Tue, 14 Aug 84 14:35:22 pdt Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.ARPA (4.24ucb/3.5) id AA02824; Tue, 14 Aug 84 14:33:51 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA20792; Tue, 14 Aug 84 14:28:47 pdt Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33) id AA04288; Tue, 14 Aug 84 14:29:41 pdt Message-Id: <8408142129.AA04288@UCB-VAX.ARPA> Date: 14 Aug 1984 17:13:29-EDT From: @mit-mc:smh@mit-ems To: mcgeer%ucbkim@Berkeley Subject: Re: bug in assoc Cc: franz-friends@Berkeley, @mit-mc@Berkeley, @udel-relay:jmiller@ct.csnet As McGeer@ucbkim points out, the code for assoc is (in common0.l): (def assoc (lambda (val alist) (do ((al alist (cdr al))) ((null al) nil) (cond ((null (car al))) ((not (dtpr (car al))) (error "bad arg to assoc" al)) ((equal val (caar al)) (return (car al))))))) The reason for the reported strange behavior of assoc is as simple as it is obscure! First a couple hints: - This code is inside the executable franz interpreter and therefore runs compiled. - The same strangeness is exhibited by assq, which is C-coded inside the Franz kernel. - Both the cdr of a dtpr and the value of an atom are stored at offset zero within their respective structures. The car and plist similarly share the same offset within their structures. - If you try to run the above assoc definition interpreted, it will properly fail to work, or rather, it will complain about a bad arg to car. - Of course, c[ad]r in the interpreter carfully check their arguments; In the compiler, they simple indirect through pointers for maximum speed. Finally, in case by now it isn't absolutely clear to everyone what is going on, assoc is (sort of) comparing val against the plist of bar and subsequently foo, and then each time automagically effectively doing a symeval on the atom to continue scanning down the "cdr" of the alist. Moral: Although the interpreter tries pretty hard to do the dynamic typing and implied typechecking for which lisp is famous, type checking in compiled code is often a myth. Correct code only necessarily works correctly when given corrent arguments. Steve Haflich MIT Experimental Music Studio smh%mit-ems@mit-mc {decvax!genrad, ihnp4!mit-eddie}!mit-ems!smh  Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.24/4.33) id AA03594; Tue, 14 Aug 84 13:59:26 pdt Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.ARPA (4.24ucb/3.5) id AA02770; Tue, 14 Aug 84 13:58:17 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA20310; Tue, 14 Aug 84 13:53:19 pdt Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33) id AA03508; Tue, 14 Aug 84 13:54:23 pdt Message-Id: <8408142054.AA03508@UCB-VAX.ARPA> Date: 14 August 1984 16:37-EDT From: Peter Szolovits Subject: on the issue of the "ATOMness" of hunks To: ALAN@MIT-MC Cc: GSB@MIT-MC, PSZ@MIT-MC, JonL.pa@XEROX, franz-friends@Berkeley, smh@MIT-EMS In-Reply-To: Msg of 13 Aug 1984 20:08-EDT from Alan Bawden I have a small quarrel with Alan Bawden's statement that "hunks never being atoms in Maclisp" is a universally-agreed bug. There are indeed useful structures that one would like to build in Lisp that act as CONS cells (i.e., CAR and CDR are applicable), but that can have further structure. I have sorely missed such objects in Lisp Machine Lisp and NIL, where flavor-instances are always atomic, when I wanted to build Brand X (interned "list structure" and universal property lists). In Maclisp, I could do this using hunks, though even that was not completely right because I wanted to be able to disallow RPLACA and RPLACD while allowing CAR and CDR, and this was hard, given the hunk abstraction. I would, however, love to have non-atomic flavor-instances  Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.24/4.33) id AA00236; Tue, 14 Aug 84 11:13:01 pdt Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.ARPA (4.24ucb/3.5) id AA02499; Tue, 14 Aug 84 11:11:54 pdt Received: by ucbkim.ARPA (4.24/4.27) id AA17397; Tue, 14 Aug 84 11:03:10 pdt Date: Tue, 14 Aug 84 11:03:10 pdt From: Rick McGeer (on an h19-u) Message-Id: <8408141803.AA17397@ucbkim.ARPA> Phone: (415) 236-8262 To: ALAN@MIT-MC, JonL.pa@XEROX Subject: Re: (atom VECTOR): franz vs liszt Cc: smh@MIT-EMS, franz-friends%ucbkim@Berkeley, GSB@MIT-MC In-Reply-To: Your message of 13 August 1984 20:08-EDT The predicate atom in Franz appears to be: (defun atom(foo) (if foo then (not (or (hunkp foo) (dtpr foo))) else t)) whereas a more natural implementation, it seems to me, is: (defun atom(foo) (or (symbolp foo) (numberp foo))) Since it seems to me that: (xor (vectorp foo) (hunkp foo) (dtpr foo) (atom foo) (arrayp foo)) should always be non-nil for non-nil objects. Or, better put, that vectors, hunks, dtprs, atoms, and arrays should partition the data space. No? Rick.  Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.24/4.33) id AA01255; Tue, 14 Aug 84 12:00:55 pdt Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.ARPA (4.24ucb/3.5) id AA02557; Tue, 14 Aug 84 11:59:34 pdt Received: by ucbkim.ARPA (4.24/4.27) id AA18832; Tue, 14 Aug 84 11:53:28 pdt Date: Tue, 14 Aug 84 11:53:28 pdt From: Rick McGeer (on an h19-u) Message-Id: <8408141853.AA18832@ucbkim.ARPA> Phone: (415) 236-8262 To: jmiller%ct.csnet@csnet-relay.ARPA, franz-friends%ucbkim@Berkeley Subject: Re: bug in assoc In-Reply-To: Your message of 13 Aug 1984 20:46:42-PST "'Curiouser and curiouser', said Alice". I dug out the source for assoc (38.79), and here it is: (def assoc (lambda (val alist) (do ((al alist (cdr al))) ((null al) nil) (cond ((null (car al))) ((not (dtpr (car al))) (error "bad arg to assoc" al)) ((equal val (caar al)) (return (car al))))))) So nothing particularly screwy is going on here. However, when I do the traces (after setting up stuff the way you did), I get: => (assoc 'b 'l) 1 assoc (b l) 1 assoc (b 2) (b 2) => (assoc 'b ''l) 1 assoc (b 'l) Error: bad arg to assoc (quote l) Form: (assoc 'b ''l) {1} bar foo {1} (assoc 'b 'foo) |2 assoc (b foo) |2 assoc (b 2) (b 2) {1} foo l {1} bar foo {1} (assoc 'b bar) |2 assoc (b foo) |2 assoc (b 2) (b 2) {1} (assoc 'b ''l) |2 assoc (b 'l) Error: bad arg to assoc (quote l) Form: (assoc 'b ''l) {2} Which is certainly *very* odd...  Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.24/4.33) id AA01255; Tue, 14 Aug 84 12:00:55 pdt Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.ARPA (4.24ucb/3.5) id AA02557; Tue, 14 Aug 84 11:59:34 pdt Received: by ucbkim.ARPA (4.24/4.27) id AA18832; Tue, 14 Aug 84 11:53:28 pdt Date: Tue, 14 Aug 84 11:53:28 pdt From: Rick McGeer (on an h19-u) Message-Id: <8408141853.AA18832@ucbkim.ARPA> Phone: (415) 236-8262 To: jmiller%ct.csnet@csnet-relay.ARPA, franz-friends%ucbkim@Berkeley Subject: Re: bug in assoc In-Reply-To: Your message of 13 Aug 1984 20:46:42-PST "'Curiouser and curiouser', said Alice". I dug out the source for assoc (38.79), and here it is: (def assoc (lambda (val alist) (do ((al alist (cdr al))) ((null al) nil) (cond ((null (car al))) ((not (dtpr (car al))) (error "bad arg to assoc" al)) ((equal val (caar al)) (return (car al))))))) So nothing particularly screwy is going on here. However, when I do the traces (after setting up stuff the way you did), I get: => (assoc 'b 'l) 1 assoc (b l) 1 assoc (b 2) (b 2) => (assoc 'b ''l) 1 assoc (b 'l) Error: bad arg to assoc (quote l) Form: (assoc 'b ''l) {1} bar foo {1} (assoc 'b 'foo) |2 assoc (b foo) |2 assoc (b 2) (b 2) {1} foo l {1} bar foo {1} (assoc 'b bar) |2 assoc (b foo) |2 assoc (b 2) (b 2) {1} (assoc 'b ''l) |2 assoc (b 'l) Error: bad arg to assoc (quote l) Form: (assoc 'b ''l) {2} Which is certainly *very* odd...  Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.24/4.33) id AA01497; Tue, 14 Aug 84 12:12:27 pdt Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.ARPA (4.24ucb/3.5) id AA02588; Tue, 14 Aug 84 12:11:12 pdt Received: by ucbkim.ARPA (4.24/4.27) id AA19018; Tue, 14 Aug 84 12:06:20 pdt Date: Tue, 14 Aug 84 12:06:20 pdt From: Rick McGeer (on an h19-u) Message-Id: <8408141906.AA19018@ucbkim.ARPA> Phone: (415) 236-8262 To: ALAN@MIT-MC, JonL.pa@XEROX Subject: Re: (atom VECTOR): franz vs liszt Cc: smh@MIT-EMS, franz-friends%ucbkim@Berkeley, GSB@MIT-MC Sorry to anyone who's getting this twice: I can't figure out from the mailer error message who got it and who didn't... The predicate atom in Franz appears to be: (defun atom(foo) (if foo then (not (or (hunkp foo) (dtpr foo))) else t)) whereas a more natural implementation, it seems to me, is: (defun atom(foo) (or (symbolp foo) (numberp foo))) Since it seems to me that: (xor (vectorp foo) (hunkp foo) (dtpr foo) (atom foo) (arrayp foo)) should always be non-nil for non-nil objects. Or, better put, that vectors, hunks, dtprs, atoms, and arrays should partition the data space. No? Rick.  Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.24/4.33) id AA26486; Tue, 14 Aug 84 07:38:41 pdt Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.ARPA (4.24ucb/3.5) id AA02228; Tue, 14 Aug 84 07:37:34 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA14507; Tue, 14 Aug 84 07:35:27 pdt Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33) id AA26447; Tue, 14 Aug 84 07:36:36 pdt Message-Id: <8408141436.AA26447@UCB-VAX.ARPA> Date: 14 Aug 1984 08:40:00-EDT From: @mit-mc:smh@mit-ems To: ALAN@mit-mc, GSB@mit-mc, JonL.pa@parc-maxc Subject: (atom VECTOR): franz vs liszt Cc: franz-friends@Berkeley Gentlemen, I think we are losing grasp on the original bug report. This is probably my fault for including a discourse on the philosophy of hunks (:-) in the bug report. Maclisp ain't gonna change about hunks, and it would be a poor idea for Franz to change. Anyway, the bug is with vectors. In Franz, compiled and interpreted code disagree whether a vector is an atom. Certainly no one can defend this! Maclisp doesn't *have* vectors, does it? Steve Haflich smh%mit-ems@mit-mc  Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.24/4.33) id AA23121; Tue, 14 Aug 84 01:56:37 pdt Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.ARPA (4.24ucb/3.5) id AA02114; Tue, 14 Aug 84 01:55:24 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA13476; Tue, 14 Aug 84 01:53:12 pdt Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.33) id AA23091; Tue, 14 Aug 84 01:54:22 pdt Message-Id: <8408140854.AA23091@UCB-VAX.ARPA> Received: From ct.csnet by csnet-relay; 14 Aug 84 4:31 EDT Date: 13 Aug 1984 20:46:42-PST From: jmiller%ct.csnet@csnet-relay.ARPA To: franz-friends@Berkeley Subject: bug in assoc The following illustrates a rather unpleasant bug in Franz's ASSOC (as of 38.26, anyhow). Be forewarned.... ------------------------------------------------------------------------------ 8_(setq l '((a 1) (b 2) (c 3))) ;;set up an a-list ((a 1) (b 2) (c 3)) 9_(setq foo 'l) ;;FOO points to the NAME of the a-list l 10_(setq bar 'foo) ;;BAR points to the NAME of the NAME of foo ;;the a-list 11_(assoc 'b l) ;;This does the right thing (b 2) 12_(assoc 'b foo) ;;Gag me with a mouse -- should err (b 2) ;;with "bad arg to " 13_(assoc 'b bar) ;;Double gag me with a mouse!! (b 2) ------------------------------------------------------------------------ For the record, ASSQ is flawed in the same way. Jim Miller Computer Thought, Dallas jmiller@ctvax.csnet ...!convex!ctvax!jmiller  Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.24/4.33) id AA10989; Mon, 13 Aug 84 17:32:50 pdt Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.ARPA (4.24ucb/3.5) id AA01596; Mon, 13 Aug 84 17:31:05 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA07443; Mon, 13 Aug 84 17:15:11 pdt Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33) id AA10564; Mon, 13 Aug 84 17:16:03 pdt Message-Id: <8408140016.AA10564@UCB-VAX.ARPA> Date: 13 August 1984 20:08-EDT From: Alan Bawden Subject: (atom VECTOR): franz vs liszt To: JonL.pa@XEROX Cc: GSB@MIT-MC, franz-friends@Berkeley, smh@MIT-EMS In-Reply-To: Msg of 13 Aug 84 13:24 PDT from JonL.pa at XEROX.ARPA Date: 13 Aug 84 13:24 PDT From: JonL.pa at XEROX ... The resolution was some awful switch setting for whether or not to treat them as ATOMs, but I don't remember the default setting, nor the final results. There are indeed a couple of switches that control various random aspects of hunks, but none of them have any effect on their atomic or non-atomic nature. Hunks are never atoms in MacLisp. Everybody agrees that this is a loss, but at this point it is rather deeply ingrained into things to think about changing it.  Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.24/4.33) id AA05981; Mon, 13 Aug 84 13:30:46 pdt Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.ARPA (4.24ucb/3.5) id AA01190; Mon, 13 Aug 84 13:29:24 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA03640; Mon, 13 Aug 84 13:25:44 pdt Received: from Xerox.ARPA (xerox.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33) id AA05890; Mon, 13 Aug 84 13:26:52 pdt Message-Id: <8408132026.AA05890@UCB-VAX.ARPA> Received: from Semillon.ms by ArpaGateway.ms ; 13 AUG 84 13:24:39 PDT Date: 13 Aug 84 13:24 PDT From: JonL.pa@XEROX.ARPA Subject: Re: (atom VECTOR): franz vs liszt In-Reply-To: "smh@mit-ems"@MIT-MC.ARPA's message of 10 Aug 84 16:06:48 EDT To: "smh@mit-ems"@MIT-MC.ARPA Cc: franz-friends@Berkeley, GSB@MIT-ML.ARPA, ALAN@MIT-MC.ARPA Perhaps this bug should be forwarded to BUG-LISP@MIT-MC, since the original design flaw is in MacLisp. The problem is that when Hunks were first invented, there where some who wanted them as "annotated" list cells (hence, they weren't ATOMs) while other wanted them as small VECTORs (hence there should be ATOMs). The resolution was some awful switch setting for whether or not to treat them as ATOMs, but I don't remember the default setting, nor the final results. -- JonL --  Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.24/4.33) id AA22103; Fri, 10 Aug 84 13:23:04 pdt Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.ARPA (4.24ucb/3.5) id AA05034; Fri, 10 Aug 84 13:25:23 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA01017; Fri, 10 Aug 84 13:14:44 pdt Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33) id AA21922; Fri, 10 Aug 84 13:15:43 pdt Message-Id: <8408102015.AA21922@UCB-VAX.ARPA> Date: 10 Aug 1984 16:06:48-EDT From: @mit-mc:smh@mit-ems To: franz-friends@Berkeley Subject: (atom VECTOR): franz vs liszt Versions: Franz 38.91, Liszt 8.39, and probably most others. Description: The atom predicate operates inconsistently between compiled and interpreted code when passed a vector or vectori. Repeat-by: Create and compile a file containing the following definition: (defun atum(x) (atom x)) After loading it into the interpreter the following results can be obtained: (setq v (vector 1 2 3)) (atom v) ===> t (atum v) ===> nil Discussion: According to the manual, atom returns "t iff g_arg is not a list or hunk object." By this definition, the interpreter is correct and the compiler incorrect. However, one can make a strong argument that vectors, analogously to hunks, should not be considered atoms. Therefore, the both the documentation and interpreter should be changed. (It is doubtful very much existing code depends on this.) Suggested fix: Change the definition of atom section 2 of the manual to read: "t iff g_arg is not a list, hunk, vector, or vectori object." Add the following definition to franz/h/global.h, after the existing definition of HUNKP: #define HUNKORVECP(a1) ((TYPE(a1) >= 11) & (TYPE(a1) <= 19)) Change the definition of Latom in franz/lam1.c: lispval Latom() { register struct argent *lb = lbot; chkarg(1,"atom"); ==> if(TYPE(lb->val)==DTPR || (HUNKORVECP(lb->val))) return(nil); else return(tatom); } Alternative suggested fix: If franz-composers really feel that atom ought to treat hunks and vectors differently (sigh?), then fix the compiler instead of the interpreter and documentation. The most important thing is that interpreted and compiler do the same thing! In liszt/funa.l:cc-atom, add 1_18 and 1_19 to the definition of the mask constant. Random (constructive) flame: The interpreter definition above has to lookup the type of its argument expensively in the typetable *three* times, to wit: #define ATOX(a1) ((((int)(a1)) - OFFSET) >> 9) #define TYPE(a1) ((typetable+1)[ATOX(a1)]) While compiled code is admirably streamlined, the interpreter could be made significantly faster here and elsewhere if TYPE were evaluated only once and held for examination in a temporary. This would require a bunch more type predicate DEFINEs operating on TYPE values instead of object addresses. Steve Haflich smh%mit-ems@mit-mc {decvax!genrad, ihnp4!mit-eddie}!mit-ems!smh  Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.24/4.33) id AA14570; Fri, 10 Aug 84 06:24:05 pdt Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.ARPA (4.24ucb/3.5) id AA04892; Fri, 10 Aug 84 06:25:57 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA13113; Fri, 10 Aug 84 06:18:45 pdt Received: from nrl-aic (nrl-aic.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33) id AA14441; Fri, 10 Aug 84 06:19:43 pdt Message-Id: <8408101319.AA14441@UCB-VAX.ARPA> Date: 10 Aug 1984 09:09:24-PDT From: Lashon Booker To: franz-friends@Berkeley Subject: Interlisp Compatibility Package? Has anyone written an Interlisp compatibility package for Franz? Thanks. Lashon Booker booker@nrl-aic  Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.24/4.33) id AA21207; Wed, 8 Aug 84 14:44:16 pdt Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.ARPA (4.24ucb/3.5) id AA03659; Wed, 8 Aug 84 14:45:27 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA23393; Wed, 8 Aug 84 14:39:03 pdt Received: from bbncct (bbncct.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.33) id AA21105; Wed, 8 Aug 84 14:39:58 pdt Message-Id: <8408082139.AA21105@UCB-VAX.ARPA> Date: Wed, 8 Aug 84 17:28:58 EDT From: Ira Smotroff Subject: add me to the list To: franz-friends@Berkeley please add my name to the franz-friends list smotroff at bbn  Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.28/4.33) id AA07048; Mon, 6 Aug 84 07:43:46 pdt Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.ARPA (4.24ucb/3.5) id AA01790; Mon, 6 Aug 84 07:46:23 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA16830; Mon, 6 Aug 84 07:41:41 pdt Received: from maryland.ARPA (maryland.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.33) id AA06949; Mon, 6 Aug 84 07:39:52 pdt Received: by maryland.ARPA (4.12/4.7) id AA01505; Mon, 6 Aug 84 10:40:52 edt Date: Mon, 6 Aug 84 10:40:52 edt From: liz@maryland (Liz Allen) Message-Id: <8408061440.AA01505@maryland.ARPA> To: franz-friends@Berkeley, yba%mit-heracles@csnet-relay.ARPA Subject: Re: Opus 37.79 building from source That sounds like an error I ran into recently -- only it was with Opus 38.91 and it was also because I was adding more strings to rawlisp. Anyway, the fix was easy and is probably worth trying. Go into franz/data.c and change the size of i_strbuf and make it bigger. Ours was 600, and I made it 1000. You'll also need to change the initialization for i_strbuf; I changed ours from "i_strbuf + 599" to "i_strbuf + 999". Hope this helps! -Liz  Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.28/4.33) id AA04171; Fri, 3 Aug 84 15:17:22 pdt Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.ARPA (4.24ucb/3.5) id AA02931; Fri, 3 Aug 84 15:18:57 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA26463; Fri, 3 Aug 84 15:15:44 pdt Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.33) id AA04086; Fri, 3 Aug 84 15:13:41 pdt Received: from mit-heracles (mit-heracles.ARPA) by mit-charon (4.12/4.7) id AA13781; Fri, 3 Aug 84 14:32:51 edt Received: by mit-heracles (4.12/4.7) id AA20045; Fri, 3 Aug 84 14:35:30 edt From: yba@mit-heracles (Mark H Levine) Message-Id: <8408031835.AA20045@mit-heracles> Date: 3 Aug 1984 1435-EDT (Friday) To: franz-friends@Berkeley Subject: Opus 37.79 building from source Has anyone published a fix to the bug that causes "rawlisp" to take a memory fault when built from vanilla 4.2bsd sources? It seems that the routine "getatom" in franz/alloc.c calls strcmp with "name" equal to "mod" and "aptr -> a.pname" equal to CNIL (-4). This is presumably a side effect of some other error; it still causes a memory fault in strcmp and prevents building from source. The sources have some Sept. '83 changes to the library code, but are otherwise con- sistent with all the 4.2 code I have seen. Got a fix handy?  Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.28/4.33) id AA00637; Thu, 2 Aug 84 16:16:22 pdt Received: from ucbkim.ARPA (ucbkim-ec.ARPA) by ucbmike.ARPA (4.24ucb/3.5) id AA01782; Thu, 2 Aug 84 16:17:48 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA16097; Thu, 2 Aug 84 16:10:04 pdt Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.28/4.33) id AA00501; Thu, 2 Aug 84 16:08:09 pdt Date: Thu, 2 Aug 84 16:09:45 pdt From: John Foderaro (on an sun) Message-Id: <8408022309.1757@ucbmike.ARPA> Received: by ucbmike.ARPA (4.24ucb/3.5) id AA01757; Thu, 2 Aug 84 16:09:45 pdt To: franz-friends@Berkeley Subject: repeated messages Cc: I'm sorry about the repeated messages. Our mailing machine got a bit overloaded. I've modified the organization of the list to try to fix the problem.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.28/4.33) id AA00412; Wed, 1 Aug 84 13:28:21 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA03438; Wed, 1 Aug 84 13:24:30 pdt Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.28/4.33) id AA01542; Wed, 1 Aug 84 13:06:01 pdt Received: by ucbdali.ARPA (4.24/4.27) id AA00994; Wed, 1 Aug 84 13:07:35 pdt Date: Wed, 1 Aug 84 13:07:35 pdt From: fateman%ucbdali@Berkeley (Richard Fateman) Message-Id: <8408012007.AA00994@ucbdali.ARPA> To: franz-friends@Berkeley, narain@rand-unix Subject: Re: Fast recompiling This would be an interesting feature, but it is complicated by the possibility that the compilation environment is built up in a typical large Franz system, by processing the whole file. I think that the interlisp situation is usually simpler. For example, in recompiling Macsyma, sometimes a file itself or function definitions in it do not change at all. A "macro definition" file which is included in the compilation environment can, however, change the generated code, substantially. Something like UNIX's "make" might be needed. Alternatively, you can use smaller files...  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.28/4.33) id AA00627; Wed, 1 Aug 84 12:32:44 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA00623; Wed, 1 Aug 84 12:31:21 pdt Received: from rand-unix.ARPA (rand-unix.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.33) id AA00567; Wed, 1 Aug 84 12:29:40 pdt Received: by rand-unix.ARPA; Wed, 1 Aug 84 11:04:30 pdt From: Sanjai Narain Message-Id: <8408011804.AA01076@rand-unix.ARPA> Date: 01 Aug 84 11:04:25 PDT (Wed) To: franz-friends@Berkeley Subject: Fast recompiling Often we have files consisting of large numbers of functions which are compiled. Sometimes, just one of these functions needs to be changed. It would be nice to recompile just this function, and copy already compiled functions to produce a fresh version of the compiled file. Is there any quick method of doing this in Franz Lisp i.e. is there an equivalent of Interlisp's "recompile" function. I would be grateful for your response. -- Sanjai Narain  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.28/4.33) id AA00627; Wed, 1 Aug 84 12:32:44 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA00623; Wed, 1 Aug 84 12:31:21 pdt Received: from rand-unix.ARPA (rand-unix.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.33) id AA00567; Wed, 1 Aug 84 12:29:40 pdt Received: by rand-unix.ARPA; Wed, 1 Aug 84 11:04:30 pdt From: Sanjai Narain Message-Id: <8408011804.AA01076@rand-unix.ARPA> Date: 01 Aug 84 11:04:25 PDT (Wed) To: franz-friends@Berkeley Subject: Fast recompiling Often we have files consisting of large numbers of functions which are compiled. Sometimes, just one of these functions needs to be changed. It would be nice to recompile just this function, and copy already compiled functions to produce a fresh version of the compiled file. Is there any quick method of doing this in Franz Lisp i.e. is there an equivalent of Interlisp's "recompile" function. I would be grateful for your response. -- Sanjai Narain  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.28/4.33) id AA00627; Wed, 1 Aug 84 12:32:44 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA00623; Wed, 1 Aug 84 12:31:21 pdt Received: from rand-unix.ARPA (rand-unix.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.33) id AA00567; Wed, 1 Aug 84 12:29:40 pdt Received: by rand-unix.ARPA; Wed, 1 Aug 84 11:04:30 pdt From: Sanjai Narain Message-Id: <8408011804.AA01076@rand-unix.ARPA> Date: 01 Aug 84 11:04:25 PDT (Wed) To: franz-friends@Berkeley Subject: Fast recompiling Often we have files consisting of large numbers of functions which are compiled. Sometimes, just one of these functions needs to be changed. It would be nice to recompile just this function, and copy already compiled functions to produce a fresh version of the compiled file. Is there any quick method of doing this in Franz Lisp i.e. is there an equivalent of Interlisp's "recompile" function. I would be grateful for your response. -- Sanjai Narain  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.28/4.33) id AA00412; Wed, 1 Aug 84 13:28:21 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA03438; Wed, 1 Aug 84 13:24:30 pdt Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.28/4.33) id AA01542; Wed, 1 Aug 84 13:06:01 pdt Received: by ucbdali.ARPA (4.24/4.27) id AA00994; Wed, 1 Aug 84 13:07:35 pdt Date: Wed, 1 Aug 84 13:07:35 pdt From: fateman%ucbdali@Berkeley (Richard Fateman) Message-Id: <8408012007.AA00994@ucbdali.ARPA> To: franz-friends@Berkeley, narain@rand-unix Subject: Re: Fast recompiling This would be an interesting feature, but it is complicated by the possibility that the compilation environment is built up in a typical large Franz system, by processing the whole file. I think that the interlisp situation is usually simpler. For example, in recompiling Macsyma, sometimes a file itself or function definitions in it do not change at all. A "macro definition" file which is included in the compilation environment can, however, change the generated code, substantially. Something like UNIX's "make" might be needed. Alternatively, you can use smaller files...  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.28/4.33) id AA00627; Wed, 1 Aug 84 12:32:44 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA00623; Wed, 1 Aug 84 12:31:21 pdt Received: from rand-unix.ARPA (rand-unix.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.33) id AA00567; Wed, 1 Aug 84 12:29:40 pdt Received: by rand-unix.ARPA; Wed, 1 Aug 84 11:04:30 pdt From: Sanjai Narain Message-Id: <8408011804.AA01076@rand-unix.ARPA> Date: 01 Aug 84 11:04:25 PDT (Wed) To: franz-friends@Berkeley Subject: Fast recompiling Often we have files consisting of large numbers of functions which are compiled. Sometimes, just one of these functions needs to be changed. It would be nice to recompile just this function, and copy already compiled functions to produce a fresh version of the compiled file. Is there any quick method of doing this in Franz Lisp i.e. is there an equivalent of Interlisp's "recompile" function. I would be grateful for your response. -- Sanjai Narain  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.28/4.33) id AA00627; Wed, 1 Aug 84 12:32:44 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA00623; Wed, 1 Aug 84 12:31:21 pdt Received: from rand-unix.ARPA (rand-unix.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.33) id AA00567; Wed, 1 Aug 84 12:29:40 pdt Received: by rand-unix.ARPA; Wed, 1 Aug 84 11:04:30 pdt From: Sanjai Narain Message-Id: <8408011804.AA01076@rand-unix.ARPA> Date: 01 Aug 84 11:04:25 PDT (Wed) To: franz-friends@Berkeley Subject: Fast recompiling Often we have files consisting of large numbers of functions which are compiled. Sometimes, just one of these functions needs to be changed. It would be nice to recompile just this function, and copy already compiled functions to produce a fresh version of the compiled file. Is there any quick method of doing this in Franz Lisp i.e. is there an equivalent of Interlisp's "recompile" function. I would be grateful for your response. -- Sanjai Narain  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.28/4.33) id AA02850; Tue, 31 Jul 84 20:00:53 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27) id AA21521; Tue, 31 Jul 84 20:02:20 pdt Received: from USC-ECL.ARPA (usc-ecl.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.33) id AA02839; Tue, 31 Jul 84 20:00:29 pdt Message-Id: <8408010300.AA02839@UCB-VAX.ARPA> Received: from ECLD by ECLA with ECLnet; Tue 31 Jul 84 19:56:31-PDT Date: Tue 31 Jul 84 19:33:52-PDT From: Eric Benson Subject: Re: Lisp Speed Benchmarks To: Philip.Kasprzyk@CMU-RI-ISL2.ARPA Cc: BENSON%ECLD.#ECLnet@Berkeley, Franz-Friends@Berkeley In-Reply-To: Message from "Philip.Kasprzyk@CMU-RI-ISL2" of Wed 25 Jul 84 09:30:25-PDT There is a set of benchmarks which have been run on a variety of Lisp systems which have been compiled by Richard Gabriel at Stanford. You should contact Paul Wieneke (PW@SU-AI) for more information. -------  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.28/4.33) id AA04915; Fri, 27 Jul 84 15:13:54 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27) id AA01124; Fri, 27 Jul 84 15:15:06 pdt Received: from Xerox.ARPA (xerox.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.33) id AA04900; Fri, 27 Jul 84 15:13:09 pdt Message-Id: <8407272213.AA04900@UCB-VAX.ARPA> Received: from Semillon.ms by ArpaGateway.ms ; 27 JUL 84 15:14:21 PDT Date: 27 Jul 84 15:14 PDT From: Masinter.pa@XEROX.ARPA Subject: Re: Benchmarks In-Reply-To: Mike Brzustowicz 's message of 27 Jul 84 14:23:47 PDT (Fri) To: mab@AIDS-UNIX.ARPA Cc: franz-friends@Berkeley Here's a good benchmark: (defun nilret () nil) this is a good test of how fast your lisp returns NIL. I also like (defun retjunk (x) (cond((junkp x) 'junk) ((cdr x) (retjunk (car x))) ((= (car x) 'junk) (retjunk (cons (cdr x) (cdr x)))) (t (retjunk (cons 'junk x)))) (defun junkp (x) (equal (reverse (explode x)) (reverse (explode 'junk)))) This benchmark measures how fast your lisp can return junk, executing the retjunk function. Both of the benchmarks have the adavantage that they are small and can be abused as benchmarks.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.28/4.33) id AA04915; Fri, 27 Jul 84 15:13:54 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27) id AA01124; Fri, 27 Jul 84 15:15:06 pdt Received: from Xerox.ARPA (xerox.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.33) id AA04900; Fri, 27 Jul 84 15:13:09 pdt Message-Id: <8407272213.AA04900@UCB-VAX.ARPA> Received: from Semillon.ms by ArpaGateway.ms ; 27 JUL 84 15:14:21 PDT Date: 27 Jul 84 15:14 PDT From: Masinter.pa@XEROX.ARPA Subject: Re: Benchmarks In-Reply-To: Mike Brzustowicz 's message of 27 Jul 84 14:23:47 PDT (Fri) To: mab@AIDS-UNIX.ARPA Cc: franz-friends@Berkeley Here's a good benchmark: (defun nilret () nil) this is a good test of how fast your lisp returns NIL. I also like (defun retjunk (x) (cond((junkp x) 'junk) ((cdr x) (retjunk (car x))) ((= (car x) 'junk) (retjunk (cons (cdr x) (cdr x)))) (t (retjunk (cons 'junk x)))) (defun junkp (x) (equal (reverse (explode x)) (reverse (explode 'junk)))) This benchmark measures how fast your lisp can return junk, executing the retjunk function. Both of the benchmarks have the adavantage that they are small and can be abused as benchmarks.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.28/4.33) id AA04092; Fri, 27 Jul 84 14:34:23 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27) id AA29865; Fri, 27 Jul 84 14:35:21 pdt Received: from aids-unix (aids-unix.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.33) id AA04068; Fri, 27 Jul 84 14:33:40 pdt Message-Id: <8407272133.AA04068@UCB-VAX.ARPA> Date: 27 Jul 84 14:23:47 PDT (Fri) From: Mike Brzustowicz Subject: Benchmarks To: franz-friends@Berkeley Does anyone have any small LISP programs that can be abused as benchmarks? (They need to be small is source only.) I need some very soon. Thanks! -Mike  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.28/4.33) id AA19754; Wed, 25 Jul 84 10:05:31 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27) id AA08698; Wed, 25 Jul 84 10:06:41 pdt Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.33) id AA19747; Wed, 25 Jul 84 10:05:06 pdt Message-Id: <8407251705.AA19747@UCB-VAX.ARPA> Date: 25 Jul 1984 12:30:25-EDT From: Philip.Kasprzyk@CMU-RI-ISL2 Subject: Lisp Speed Benchmarks Apparently-To: ~v I am interested in determining the absolute speed of execution of a lisp system. I realize that this is a complicated task that is application and implementation dependant. Nevertheless I am seeking the following: 1) A "gibson mix" style benchmark for lisp based systems. 2) Any data that experienced users of lisp may have regarding performance. (I don't care what machine or dialect of lisp is reported) 3) Any method or program which translates a lisp program into another target high level language with execution speed as its objective. (I don't mean a normal lisp compiler) Can anyone out there help me? If so send mail to pmk@isl2.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.28/4.31) id AA07287; Thu, 12 Jul 84 07:15:10 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27) id AA28967; Thu, 12 Jul 84 07:15:39 pdt Received: from nrl-aic (nrl-aic.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31) id AA07280; Thu, 12 Jul 84 07:14:50 pdt Date: 12 Jul 1984 10:08-EDT From: Patrick Harrison Subject: Lisp for Honeywell 6060 DPS-8 To: ailist@sri-ai Cc: franz-friends@Berkeley Message-Id: <84/07/12 1008.550@NRL-AIC> Am looking for information on current versions of LISP (FranzLisp, MacLisp) running in a Honeywell 6060, DPS-8 environment. Would also like to implement OPS5 on same. Address: Dr. Patrick Harrison Computer Science Department U.S. Naval Academy Annapolis, Maryland 21402. Responses to above address or  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.28/4.31) id AA28110; Wed, 11 Jul 84 20:29:02 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27) id AA25212; Wed, 11 Jul 84 20:29:28 pdt Received: from CMU-CS-G.ARPA (cmu-cs-g.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31) id AA28089; Wed, 11 Jul 84 20:28:27 pdt Reply-To: cadre!sm@CMU-CS-G.ARPA Received: by cadre.UUCP (4.12/3.14) id AA22394; Wed, 11 Jul 84 23:22:09 edt Date: Wed, 11 Jul 84 23:22:09 edt From: cadre!sm@Berkeley (Sean McLinden) Message-Id: <8407120322.AA22394@cadre.UUCP> To: jkf%ucbmike@Berkeley Subject: redefinition of existing flavors Cc: franz-friends@Berkeley As distributed by Berkeley, the flavors package on Opus 38.89 appears to work in all cases except when a flavor is redefined and perform-flavor-redefinition is invoked. The problem, I thought, was in copy-hunk-contents, since the default structures (and therefore flavors), in Opus 38.89, are VECTORS, not HUNKS. However, modifying copy-hunk-contents to copy VECTORS did not, completely, fix the problem (i.e, the first modification after redefinition of copy-hunk-contents caused an error, the second worked but then describe did not work for old instances of the flavor). Before delving into code with which I am unfamiliar are there any differences between Opus 38.89 and 38.91 which might explain this? Sean McLinden Decision Systems Lab University of Pittsburgh  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.28/4.31) id AA21421; Wed, 11 Jul 84 13:43:50 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27) id AA20014; Wed, 11 Jul 84 13:43:49 pdt Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.28/4.31) id AA21120; Wed, 11 Jul 84 13:32:32 pdt Date: Wed, 11 Jul 84 13:32:52 pdt From: John Foderaro (on an sun) Message-Id: <8407112032.5402@ucbmike.ARPA> Received: by ucbmike.ARPA (4.24ucb/3.5) id AA05402; Wed, 11 Jul 84 13:32:52 pdt To: franz-friends@Berkeley Subject: Re: &optional, &rest, &aux Cc: franz-composers@Berkeley In-Reply-To: Your message of 11 Jul 1984 15:12:07-EDT The problem with the &optional and &rest was due to abar using the cmufile package, which redefines 'def' and doesn't look for those keywords.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.28/4.31) id AA20018; Wed, 11 Jul 84 12:25:57 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27) id AA17391; Wed, 11 Jul 84 12:25:52 pdt Received: from bbn-vax (bbn-vax.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31) id AA19991; Wed, 11 Jul 84 12:24:54 pdt Message-Id: <8407111924.AA19991@UCB-VAX.ARPA> Date: Wed, 11 Jul 84 15:24 EDT From: Ken Anderson Subject: bugs in hash.l and array.l To: franz-friends@Berkeley Cc: lbagnall@bbn, jchung@bbn To get Flavors working in Opus 38.91 you will need to fix a bug in lisplib/hash.l. Change all occurances of "getlength" to "vsize". Although unrelated to Flavors, there are several problems with the functions, fillarray fillarrayarray and listarray in lisplib/array.l. Here is an ed script produced by diff: 285,286c (cond ((or (arrayp arr) ; KRA (and (symbolp arr) (arrayp (setq arr (getd arr)))))) , 282,283c (lexpr (n) (prog (arr size typ ret newv) , 280a ; KRA 83-11-2: Arrays need not be symbols. , 279c (replace (arrayref arrto i) (arrayref arrfrom i))) (return arrto)))) ; KRA , 270c (cond ((cdr ls) (setq ls (cdr ls))))) (return arr)))) ; KRA , 244a ; KRA 83-11-2: Fillarray and fillarrayarray should return the array! ,  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.28/4.31) id AA05942; Tue, 10 Jul 84 23:03:59 pdt Received: from ucbernie.ARPA by ucbkim.ARPA (4.28/4.27) id AA08764; Tue, 10 Jul 84 23:04:16 pdt Received: by ucbernie.ARPA (4.28/4.30) id AA06176; Tue, 10 Jul 84 23:02:56 pdt Date: Tue, 10 Jul 84 23:02:56 pdt From: abar%ucbernie@Berkeley (Robert Abarbanel) Message-Id: <8407110602.AA06176@ucbernie.ARPA> To: franz-friends%ucbernie@Berkeley Subject: &optional, &rest, &aux Any way to get these &args to work without compilation... that is, when a function is working interpreted?  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.28/4.31) id AA10930; Tue, 10 Jul 84 15:30:09 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27) id AA02481; Tue, 10 Jul 84 15:29:20 pdt Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31) id AA10890; Tue, 10 Jul 84 15:28:30 pdt Message-Id: <8407102228.AA10890@UCB-VAX.ARPA> Date: 10 Jul 1984 18:24:02-EDT From: To: franz-friends@Berkeley, kanderso@bbnvax Subject: Re: Problem compiling flavors in Opus 83.79 A very quick check reveals the following suspiciousness: The function in flavors.l being compiled when the failure occurs is apparently: (DEFUN (FLAVOR :NAMED-STRUCTURE-INVOKE) (OPERATION &OPTIONAL SELF &REST ARGS) (SELECTQ OPERATION (:WHICH-OPERATIONS '(:PRINT-SELF :DESCRIBE)) (:PRINT-SELF (SI:PRINTING-RANDOM-OBJECT (SELF (CAR ARGS)) (FORMAT (CAR ARGS) "FLAVOR ~S" (FLAVOR-NAME SELF)))) (:DESCRIBE (DESCRIBE-FLAVOR SELF)) (OTHERWISE (FERROR NIL "~S UNKNOWN OPERATION FOR FLAVOR" OPERATION)))) This is the first appearance in the file of defun with a "function spec" instead of a symbol as the first argument. This is a Lisp Machine hack which basically means to squirrel the functional object away under the :NAMED-STRUCTURE-INVOKE property of the plist of FLAVOR. (More precisely, the first arg is the Maclisp compatability syntax for (:PROPERTY FLAVOR :NAMED-STRUCTURE-INVOKE) ...) Liszt could be choking as it tries to store into the function-definition slot of something other than a symbol. Such abilities of defun are not documented in Franz, and it might be that your defun macro in common0.l has not been extended for such usage. Locally it is defined as follows: ;--- defun ; maclisp style function defintion ; (def defun (macro (l) (prog (name type arglist body specind specnam) (setq name (cadr l) l (cddr l)) (cond ((dtpr name) (cond ((memq (cadr name) '(macro expr fexpr lexpr)) (setq l (cons (cadr name) l) name (car name))) (t (setq specnam (car name) specind (cadr name) name (concat (gensym) "::" specnam)))))) (cond ((null (car l)) (setq type 'lambda)) ((eq 'fexpr (car l)) (setq type 'nlambda l (cdr l))) ((eq 'expr (car l)) (setq type 'lambda l (cdr l))) ((eq 'macro (car l)) (setq type 'macro l (cdr l))) ((atom (car l)) (setq type 'lexpr l (nconc (list (list (car l))) (cdr l)))) (t (setq type 'lambda))) (setq body (list 'def name (cons type l))) (cond (specnam (return (list 'progn ''compile body (list 'putprop (list 'quote specnam) (list 'getd (list 'quote name)) (list 'quote specind))))) (t (return body)))))) You could also check by invoking liszt without arguments and then asking it (testmac '(defun (foo bar) () (hello goodbye))) and seeing if it properly generates (progn 'compile (defun ... ) (putprop ... )) On another matter, I have recently been making a number of minor bugfixes to the flavor and various other MIT compatibility packages. These files come indirecly from Maclisp or Lisp Machines, and the ports have generally never been exercised sufficiently to check all the obscure features. These fixes postdate the versions Rich Zippel recently transmitted to Berkeley. I will shortly distribute the new versions to Berkeley. Believe it or not, the flavor system really does work under Franz. So do hash tables, defstruct, format, etc. I use them every day. Steve Haflich, MIT Experimental Music Studio smh@mit-ems@mit-mc {decvax!genrad, ihnp4}!mit-eddie!smh  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.28/4.31) id AA10930; Tue, 10 Jul 84 15:30:09 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27) id AA02481; Tue, 10 Jul 84 15:29:20 pdt Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31) id AA10890; Tue, 10 Jul 84 15:28:30 pdt Message-Id: <8407102228.AA10890@UCB-VAX.ARPA> Date: 10 Jul 1984 18:24:02-EDT From: To: franz-friends@Berkeley, kanderso@bbnvax Subject: Re: Problem compiling flavors in Opus 83.79 A very quick check reveals the following suspiciousness: The function in flavors.l being compiled when the failure occurs is apparently: (DEFUN (FLAVOR :NAMED-STRUCTURE-INVOKE) (OPERATION &OPTIONAL SELF &REST ARGS) (SELECTQ OPERATION (:WHICH-OPERATIONS '(:PRINT-SELF :DESCRIBE)) (:PRINT-SELF (SI:PRINTING-RANDOM-OBJECT (SELF (CAR ARGS)) (FORMAT (CAR ARGS) "FLAVOR ~S" (FLAVOR-NAME SELF)))) (:DESCRIBE (DESCRIBE-FLAVOR SELF)) (OTHERWISE (FERROR NIL "~S UNKNOWN OPERATION FOR FLAVOR" OPERATION)))) This is the first appearance in the file of defun with a "function spec" instead of a symbol as the first argument. This is a Lisp Machine hack which basically means to squirrel the functional object away under the :NAMED-STRUCTURE-INVOKE property of the plist of FLAVOR. (More precisely, the first arg is the Maclisp compatability syntax for (:PROPERTY FLAVOR :NAMED-STRUCTURE-INVOKE) ...) Liszt could be choking as it tries to store into the function-definition slot of something other than a symbol. Such abilities of defun are not documented in Franz, and it might be that your defun macro in common0.l has not been extended for such usage. Locally it is defined as follows: ;--- defun ; maclisp style function defintion ; (def defun (macro (l) (prog (name type arglist body specind specnam) (setq name (cadr l) l (cddr l)) (cond ((dtpr name) (cond ((memq (cadr name) '(macro expr fexpr lexpr)) (setq l (cons (cadr name) l) name (car name))) (t (setq specnam (car name) specind (cadr name) name (concat (gensym) "::" specnam)))))) (cond ((null (car l)) (setq type 'lambda)) ((eq 'fexpr (car l)) (setq type 'nlambda l (cdr l))) ((eq 'expr (car l)) (setq type 'lambda l (cdr l))) ((eq 'macro (car l)) (setq type 'macro l (cdr l))) ((atom (car l)) (setq type 'lexpr l (nconc (list (list (car l))) (cdr l)))) (t (setq type 'lambda))) (setq body (list 'def name (cons type l))) (cond (specnam (return (list 'progn ''compile body (list 'putprop (list 'quote specnam) (list 'getd (list 'quote name)) (list 'quote specind))))) (t (return body)))))) You could also check by invoking liszt without arguments and then asking it (testmac '(defun (foo bar) () (hello goodbye))) and seeing if it properly generates (progn 'compile (defun ... ) (putprop ... )) On another matter, I have recently been making a number of minor bugfixes to the flavor and various other MIT compatibility packages. These files come indirecly from Maclisp or Lisp Machines, and the ports have generally never been exercised sufficiently to check all the obscure features. These fixes postdate the versions Rich Zippel recently transmitted to Berkeley. I will shortly distribute the new versions to Berkeley. Believe it or not, the flavor system really does work under Franz. So do hash tables, defstruct, format, etc. I use them every day. Steve Haflich, MIT Experimental Music Studio smh@mit-ems@mit-mc {decvax!genrad, ihnp4}!mit-eddie!smh  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.28/4.31) id AA07378; Tue, 10 Jul 84 12:18:33 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27) id AA27111; Tue, 10 Jul 84 12:18:28 pdt Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.28/4.31) id AA07135; Tue, 10 Jul 84 12:06:28 pdt Date: Tue, 10 Jul 84 12:07:07 pdt From: John Foderaro (on an sun) Message-Id: <8407101907.3780@ucbmike.ARPA> Received: by ucbmike.ARPA (4.24ucb/3.5) id AA03780; Tue, 10 Jul 84 12:07:07 pdt To: kanderso@bbn-vax, franz-friends@Berkeley Subject: Re: Problem compiling flavors in Opus 83.79 Cc: jchung@bbn, lbagnall@bbn, franz-composers@Berkeley In-Reply-To: Your message of Tue, 10 Jul 84 14:28 EDT This bug was fixed a while back, but apparently after you got your lisp distribution. You should get the latest lisp distribution.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.28/4.31) id AA10930; Tue, 10 Jul 84 15:30:09 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27) id AA02481; Tue, 10 Jul 84 15:29:20 pdt Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31) id AA10890; Tue, 10 Jul 84 15:28:30 pdt Message-Id: <8407102228.AA10890@UCB-VAX.ARPA> Date: 10 Jul 1984 18:24:02-EDT From: To: franz-friends@Berkeley, kanderso@bbnvax Subject: Re: Problem compiling flavors in Opus 83.79 A very quick check reveals the following suspiciousness: The function in flavors.l being compiled when the failure occurs is apparently: (DEFUN (FLAVOR :NAMED-STRUCTURE-INVOKE) (OPERATION &OPTIONAL SELF &REST ARGS) (SELECTQ OPERATION (:WHICH-OPERATIONS '(:PRINT-SELF :DESCRIBE)) (:PRINT-SELF (SI:PRINTING-RANDOM-OBJECT (SELF (CAR ARGS)) (FORMAT (CAR ARGS) "FLAVOR ~S" (FLAVOR-NAME SELF)))) (:DESCRIBE (DESCRIBE-FLAVOR SELF)) (OTHERWISE (FERROR NIL "~S UNKNOWN OPERATION FOR FLAVOR" OPERATION)))) This is the first appearance in the file of defun with a "function spec" instead of a symbol as the first argument. This is a Lisp Machine hack which basically means to squirrel the functional object away under the :NAMED-STRUCTURE-INVOKE property of the plist of FLAVOR. (More precisely, the first arg is the Maclisp compatability syntax for (:PROPERTY FLAVOR :NAMED-STRUCTURE-INVOKE) ...) Liszt could be choking as it tries to store into the function-definition slot of something other than a symbol. Such abilities of defun are not documented in Franz, and it might be that your defun macro in common0.l has not been extended for such usage. Locally it is defined as follows: ;--- defun ; maclisp style function defintion ; (def defun (macro (l) (prog (name type arglist body specind specnam) (setq name (cadr l) l (cddr l)) (cond ((dtpr name) (cond ((memq (cadr name) '(macro expr fexpr lexpr)) (setq l (cons (cadr name) l) name (car name))) (t (setq specnam (car name) specind (cadr name) name (concat (gensym) "::" specnam)))))) (cond ((null (car l)) (setq type 'lambda)) ((eq 'fexpr (car l)) (setq type 'nlambda l (cdr l))) ((eq 'expr (car l)) (setq type 'lambda l (cdr l))) ((eq 'macro (car l)) (setq type 'macro l (cdr l))) ((atom (car l)) (setq type 'lexpr l (nconc (list (list (car l))) (cdr l)))) (t (setq type 'lambda))) (setq body (list 'def name (cons type l))) (cond (specnam (return (list 'progn ''compile body (list 'putprop (list 'quote specnam) (list 'getd (list 'quote name)) (list 'quote specind))))) (t (return body)))))) You could also check by invoking liszt without arguments and then asking it (testmac '(defun (foo bar) () (hello goodbye))) and seeing if it properly generates (progn 'compile (defun ... ) (putprop ... )) On another matter, I have recently been making a number of minor bugfixes to the flavor and various other MIT compatibility packages. These files come indirecly from Maclisp or Lisp Machines, and the ports have generally never been exercised sufficiently to check all the obscure features. These fixes postdate the versions Rich Zippel recently transmitted to Berkeley. I will shortly distribute the new versions to Berkeley. Believe it or not, the flavor system really does work under Franz. So do hash tables, defstruct, format, etc. I use them every day. Steve Haflich, MIT Experimental Music Studio smh@mit-ems@mit-mc {decvax!genrad, ihnp4}!mit-eddie!smh  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.28/4.31) id AA06653; Tue, 10 Jul 84 11:42:18 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27) id AA25755; Tue, 10 Jul 84 11:41:39 pdt Received: from bbn-vax (bbn-vax.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31) id AA06454; Tue, 10 Jul 84 11:29:28 pdt Message-Id: <8407101829.AA06454@UCB-VAX.ARPA> Date: Tue, 10 Jul 84 14:28 EDT From: Ken Anderson Subject: Problem compiling flavors in Opus 83.79 To: franz-friends@Berkeley Cc: franz-composers@Berkeley, lbagnall@bbn, jchung@bbn When trying to make flavors from the version in pub/lib on ucbkim, liszt complains about calling an undefined function e-sub2. Here is the output of my makefile. Any suggestions? liszt -a flavorm Compilation begins with Liszt vax version 8.36 source: flavorm.l, result: flavorm.o [fasl /usr/lib/lisp/machacks.o] [autoload /usr/lib/lisp/struct] [fasl /usr/lib/lisp/struct.o] flavor-plist flavor-init-keywords flavor-initable-instance-variables flavor-settable-instance-variables flavor-gettable-instance-variables flavor-default-handler flavor-which-operations flavor-depends-on-all flavor-includes flavor-depended-on-by flavor-depends-on flavor-method-table flavor-all-instance-variables flavor-local-instance-variables flavor-name flavor-method-hash-table flavor-bindings make-flavor alter-flavor instancep instancep::cmacro:g00079 send lexpr-send send-self lexpr-send-self g00100::send %Note: flavorm.l: Compilation complete %Note: flavorm.l: Time: Real: 0:32, CPU: 0:11.10, GC: 0:0.00 for 0 gcs %Note: flavorm.l: Assembly begins %Note: flavorm.l: Assembly completed successfully liszt -a flavors Compilation begins with Liszt vax version 8.36 source: flavors.l, result: flavors.o [fasl /usr/lib/lisp/machacks.o] [fasl /usr/lib/lisp/lmhacks.o] [fasl flavorm.o] defflavor defun-method [autoload /usr/lib/lisp/struct] [fasl /usr/lib/lisp/struct.o] instance-variable-boundp instance-flavor instance-flavor::cmacro:g00068 instance-function instance-function::cmacro:g00075 get-flavor instance-typep flavor-additional-instance-variables flavor-additional-instance-variables::cmacro:g00101 flavor-instance-variable-initializations flavor-instance-variable-initializations::cmacro:g00108 flavor-remaining-default-plist flavor-remaining-default-plist::cmacro:g00115 flavor-remaining-init-keywords flavor-remaining-init-keywords::cmacro:g00122 flavor-all-initable-instance-variables flavor-all-initable-instance-variables::cmacro:g00129 g00133::flavor Undefined function called from compiled code e-sub2 ?Error: flavors.l: : Lisp error during compilation make: *** Error code 1 ***  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.28/4.31) id AA24174; Mon, 9 Jul 84 22:06:16 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27) id AA17486; Mon, 9 Jul 84 22:06:26 pdt Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31) id AA24170; Mon, 9 Jul 84 22:05:52 pdt Message-Id: <8407100505.AA24170@UCB-VAX.ARPA> Date: 9 Jul 1984 21:10:53-EDT From: Richard.Wallace@CMU-CS-H Subject: Bell quote Apparently-To: Lisp, designed about 1960 by John McCarthy, impressed me so much that I included the critcal data access primitives in the architecture of the DEC System 10 in 1965 (still about the fastest Lisp computer). - C. Gordon Bell IEEE Computer June, 1984  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.28/4.31) id AA13758; Wed, 27 Jun 84 14:22:06 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27) id AA19372; Wed, 27 Jun 84 14:24:24 pdt Received: from nrl-aic (nrl-aic.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31) id AA13744; Wed, 27 Jun 84 14:21:16 pdt Message-Id: <8406272121.AA13744@UCB-VAX.ARPA> Date: 27 Jun 1984 16:42-EDT From: Dan Hoey Subject: Incorrect "make fromasm" in 68k franz 38.91 To: franz-friends@Berkeley Cc: dejong@nrl-aic, franz-bugs@Berkeley Problem: The "make fromasm" option for franz installation on a 68k does not work as distributed. Diagnosis: The assembler is used to convert *.s files into *.o. But the output of as defaults to "a.out" and is not overridden, so no *.o files are produced. Fixes: Specify the output file in the fromasm: option in lisplib/Makefile and liszt/68k/Makefile. In lisplib/Makefile, and (if make copylibrary has been done) in /usr/lib/lisp/Makefile, change < for i in *.s; do echo $$i; ${LibDir}/as $$i; done ---- > for i in *.s; do echo $$i; \ > ${LibDir}/as $$i -o `basename $$i .s`.o; done In liszt/68k/Makefile, change < for i in *.s; do echo $$i; as $$i; done ---- > for i in *.s; do echo $$i; \ > as $$i -o `basename $$i .s`.o; done Bugs: 1. One version specifies ${LibDir}/as, the other uses vanilla as. I didn't change it, but perhaps the liszt/68k/Makefile should also specify ${LibDir}/as. 2. Isn't there a cleaner way of doing this? Can a ".s.o:" rule be specified? Dan  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.28/4.31) id AA28000; Thu, 21 Jun 84 19:25:00 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27) id AA08546; Thu, 21 Jun 84 19:26:57 pdt Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31) id AA27996; Thu, 21 Jun 84 19:24:37 pdt Message-Id: <8406220224.AA27996@UCB-VAX.ARPA> Date: 21 June 1984 22:28-EDT From: Richard E. Zippel Subject: MIT flavors To: franz-friends@Berkeley Cc: zymelman@MITRE, smh@MIT-VAX In-Reply-To: Msg of 21 Jun 1984 9:19:16 EDT () from Ari Zymelman I am happy to report than the MIT flavor system is finally available. I won't try to correct the numerous bits of misinformation that have been spread about this other than to say that the MIT flavor system can now be freely distributed, if it is not used for profit, and the MIT copyrights are maintained in the sources. Berkeley has a copy of the most recent version of the code and should include it in their standard distributions shortly.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.28/4.31) id AA28000; Thu, 21 Jun 84 19:25:00 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27) id AA08546; Thu, 21 Jun 84 19:26:57 pdt Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31) id AA27996; Thu, 21 Jun 84 19:24:37 pdt Message-Id: <8406220224.AA27996@UCB-VAX.ARPA> Date: 21 June 1984 22:28-EDT From: Richard E. Zippel Subject: MIT flavors To: franz-friends@Berkeley Cc: zymelman@MITRE, smh@MIT-VAX In-Reply-To: Msg of 21 Jun 1984 9:19:16 EDT () from Ari Zymelman I am happy to report than the MIT flavor system is finally available. I won't try to correct the numerous bits of misinformation that have been spread about this other than to say that the MIT flavor system can now be freely distributed, if it is not used for profit, and the MIT copyrights are maintained in the sources. Berkeley has a copy of the most recent version of the code and should include it in their standard distributions shortly.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.28/4.31) id AA01767; Tue, 19 Jun 84 07:34:49 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27) id AA01983; Tue, 19 Jun 84 07:36:37 pdt Received: from ARDC (ardc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31) id AA01762; Tue, 19 Jun 84 07:34:31 pdt Message-Id: <8406191434.AA01762@UCB-VAX.ARPA> Date: Tue, 19 Jun 84 10:31:27 EDT From: William K. Cadwallender (LCWSL) To: franz-friends@Berkeley Subject: Franz for VAX730 We are about to purchase a VAX730 with BSD4.2 UNIX. Has anyone out thereheard of a port of Franz, or ANY LISP to a 730? Please reply to the net or directly to wkc@ARDC. Bill Cadwallender (wkc@ARDC)  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.28/4.31) id AA19476; Mon, 18 Jun 84 17:08:12 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27) id AA21265; Mon, 18 Jun 84 17:09:37 pdt Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.28/4.31) id AA19453; Mon, 18 Jun 84 17:07:25 pdt Message-Id: <8406190007.AA19453@UCB-VAX.ARPA> Date: 18 Jun 1984 12:48:57-EDT From: Simon.Lowenfeld@CMU-RI-ISL1 Subject: old messages Apparently-To: Is there some kind of archive for old postings? I am interested in the Franz/T argument from earlier this year.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.27) id AA27507; Sun, 3 Jun 84 23:23:27 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27) id AA09575; Sun, 3 Jun 84 23:24:19 pdt Received: from Xerox.ARPA (xerox.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.27) id AA27487; Sun, 3 Jun 84 23:22:53 pdt Message-Id: <8406040622.AA27487@UCB-VAX.ARPA> Received: from Semillon.ms by ArpaGateway.ms ; 03 JUN 84 23:22:56 PDT Date: 3 Jun 84 23:22 PDT From: Jonl.pa@XEROX.ARPA Subject: This is a test To: Franz-Friends@Berkeley Sorry to bother you -- this is only a test of correct forwarding on this mailing list.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.27) id AA27507; Sun, 3 Jun 84 23:23:27 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27) id AA09575; Sun, 3 Jun 84 23:24:19 pdt Received: from Xerox.ARPA (xerox.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.27) id AA27487; Sun, 3 Jun 84 23:22:53 pdt Message-Id: <8406040622.AA27487@UCB-VAX.ARPA> Received: from Semillon.ms by ArpaGateway.ms ; 03 JUN 84 23:22:56 PDT Date: 3 Jun 84 23:22 PDT From: Jonl.pa@XEROX.ARPA Subject: This is a test To: Franz-Friends@Berkeley Sorry to bother you -- this is only a test of correct forwarding on this mailing list.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.27) id AA24840; Sun, 3 Jun 84 19:14:05 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.28/4.27) id AA07648; Sun, 3 Jun 84 19:15:03 pdt Received: from CMU-CS-G.ARPA (cmu-cs-g.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.27) id AA24832; Sun, 3 Jun 84 19:13:42 pdt Date: 3 Jun 1984 22:02-EST From: Todd.Kueny@CMU-CS-G.ARPA Subject: Please add my name to the list To: FRANZ-FRIENDS@Berkeley Message-Id: <455162572/trk@CMU-CS-G> Please add my name to the FRANZ-FRIENDS list. -Todd K.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.27) id AA23672; Fri, 25 May 84 18:47:58 pdt Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.27) id AA20472; Fri, 25 May 84 18:47:11 pdt Received: from csnet-relay (csnet-pdn-gw.ARPA) by UCB-VAX.ARPA (4.24/4.27) id AA23631; Fri, 25 May 84 18:45:35 pdt Message-Id: <8405260145.AA23631@UCB-VAX.ARPA> Received: From colostate.csnet by csnet-relay; 25 May 84 21:17 EDT Date: Fri, 25 May 84 13:47:24 mdt From: varghese%colostate.csnet@csnet-relay.ARPA Received: by csu-cs.UUCP (4.12/3.14) id AA11606; Fri, 25 May 84 13:47:24 mdt To: FRANZ-FRIENDS.BERKELEY@csnet-relay.ARPA Subject: Addition to mailing list Please add us to the mailing list. Since there will be more than one person at this site who wants to be on the mailing list we decided to get everything mailed to one central mailbox. The mailbox address for this mailing list is frnzlist@colostate Please note that this is a CSnet address. Thank you, Joe Varghese varghese@colostate  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.27) id AA26690; Fri, 20 Apr 84 00:33:46 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.3) id AA02385; Fri, 20 Apr 84 00:27:33 pst Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.27) id AA26615; Fri, 20 Apr 84 00:26:44 pst Message-Id: <8404200826.AA26615@UCB-VAX.ARPA> Date: Fri 20 Apr 84 03:27:54-EST From: MDC.WAYNE%MIT-OZ@MIT-MC.ARPA Subject: Mailing List Request To: Franz-Friends@Berkeley Cc: MDC.WAYNE%MIT-OZ@MIT-MC.ARPA Please add my name to your mailing list. Wayne McGuire -------  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.27) id AA13847; Thu, 19 Apr 84 11:58:22 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.3) id AA23998; Thu, 19 Apr 84 11:52:57 pst Received: by UCB-VAX.ARPA (4.24/4.27) id AA13726; Thu, 19 Apr 84 11:51:53 pst Received: from jdd.UUCP by allegra.UUCP (4.12/4.7) id AA14339; Thu, 19 Apr 84 14:45:33 est Received: by jdd.UUCP (3.346/4.7) id AA02407; 19 Apr 84 14:48:12 EST (Thu) Date: 19 Apr 84 14:48:12 EST (Thu) From: allegra!jdd@Berkeley (John DeTreville) Message-Id: <8404191948.AA02407@jdd.UUCP> To: ucbvax!franz-friends@Berkeley Subject: Franz on Suns under 4.2 Cc: lindsay@Berkeley Well, I have the answer to my question. My problem, you may recall, was that the Franz on the 4.2 tapes, which worked under Sun Unix Release 0.4, no longer worked under Release 1.0. It turns out: * When Sun went from Release 0.4 to 1.0, they changed the stack frame format, and that broke Opus 38.79, which is the one on the 4.2 tapes from Berkeley. However, Berkeley fixed the problem in Opus 38.91, which is also available from Berkeley. * When Sun goes to Release 1.1, they will change the stack frame formats back (for this and other reasons), and Opus 38.79 will work again. I would presume that 38.91 will still work too. Cheers, John DeTreville Bell Labs, Murray Hill  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.27) id AA29736; Wed, 18 Apr 84 20:39:43 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.3) id AA16547; Wed, 18 Apr 84 20:37:26 pst Received: from RUTGERS.ARPA (rutgers.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.27) id AA29663; Wed, 18 Apr 84 20:36:21 pst Message-Id: <8404190436.AA29663@UCB-VAX.ARPA> Date: 18 Apr 84 23:37:14 EST From: Sean McLinden Subject: [Sean McLinden : Re: Franz on Suns under 4.2?] To: franz-friends@Berkeley Mail-From: MCLINDEN created at 18-Apr-84 23:33:56 Date: 18 Apr 84 23:33:56 EST From: Sean McLinden Subject: Re: Franz on Suns under 4.2? To: allegra!jdd@UCB-VAX.ARPA cc: MCLINDEN@RUTGERS.ARPA In-Reply-To: Message from "allegra!jdd@Berkeley (John DeTreville)" of 18 Apr 84 13:10:10 EST I must be missing something with all of this discussion of Franz Lisp on Suns. We have had no trouble at all running the current (opus 38.91?) Berkeley release on Suns and have been running Sun Franz Lisp for nearly a year now. The only serious problem that I can recall happened a few sub versions ago and was due to a logical error in the C-coded algorithm which determined when to garbage collect (as things would have it, it never did). The result was that liszt was unable to compile some of the lisp coded sources due to the 2 Meg/process limit imposed by the Sun operating system (the bug existed in the Vax version as well but one would only see it if the lisp image exceeded 6 megs which is rare for a compiler run). Perhaps you could be more explicit in describing what, exactly, the problem is. The people at Berkeley most probably have Suns and I am sure that they don't release Sun versions without testing them. Sean McLinden Decision Systems Lab University of Pittsburgh School of Medicine ------- -------  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.27) id AA20147; Wed, 18 Apr 84 12:02:44 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.3) id AA06975; Wed, 18 Apr 84 10:15:30 pst Received: by UCB-VAX.ARPA (4.24/4.27) id AA17960; Wed, 18 Apr 84 10:14:33 pst Received: by allegra.UUCP (4.12/4.7) id AA07504; Wed, 18 Apr 84 13:10:10 est Date: Wed, 18 Apr 84 13:10:10 est From: allegra!jdd@Berkeley (John DeTreville) Message-Id: <8404181810.AA07504@allegra.UUCP> To: ucbvax!franz-friends@Berkeley Subject: Franz on Suns under 4.2? Does anyone have, or know how to make, a version of Franz that runs on Suns under 4.2BSD (Release 1.0)? The version that comes on the 4.2 tapes for Vaxen only has the sun_4_1c option, and will not work on Suns on 4.2. (It almost works, but not quite). (And yes, I know I could just write a $5000.00 check to Franz, Inc., but I have better things to spend the money on.) Cheers, John ("Skinflint") DeTreville Bell Labs, Murray Hill  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.25) id AA13187; Tue, 10 Apr 84 10:04:48 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.3) id AA05285; Tue, 10 Apr 84 09:57:42 pst Received: from Ucl-Cs (ucl-cs.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.25) id AA12977; Tue, 10 Apr 84 09:56:28 pst Received: from edxa.ac.uk by 44d.Ucl-Cs.AC.UK via Sercnet with NIFTP; 10 Apr 84 17:06 GMT From: DALTON FHL (on ERCC DEC-10) Date: Tuesday, 10-Apr-84 17:56:56-BST Message-Id: <131350576724@EDXA> To: cross , franz-friends@edxa Subject: Franz on Data General -------- I don't know of any implementation of Franz on the MV-8000, but DG once had a Lisp for internal use that ran on the Eclipse under AOS (pre MV-8000) which may run on the MV-8000 as well. It was called Eclisp (naturally) and lexically scoped with optimized tail-recursion. I believe it was written largely in PL/N (is that the name?). It was a small system, with no compiler. Jeff Dalton Department Of Artificial Intelligence University of Edinburgh --------  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.25) id AA18657; Mon, 9 Apr 84 16:05:47 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.3) id AA26142; Mon, 9 Apr 84 15:56:58 pst Received: from Ucl-Cs (ucl-cs.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.25) id AA18395; Mon, 9 Apr 84 15:55:31 pst Received: from edxa.ac.uk by 44d.Ucl-Cs.AC.UK via Sercnet with NIFTP; 9 Apr 84 23:50 GMT From: DALTON FHL (on ERCC DEC-10) Date: Saturday, 7-Apr-84 20:52:41-BST Message-Id: <131345675316@EDXA> To: cross , franz-friends@edxa, me@edxa Subject: Franz on Data General d -------- I don't know of any implementation of Franz on the MV-8000, but DG once had a Lisp for internal use that ran on the Eclipse (pre MV-8000) which may run on the MV-8000 as well. It was interpreter-only and lexically scoped. Jeff Dalton Department Of Artificial Intelligence University of Edinburgh I don't know of any implementation of Franz on the MV-8000, but DG once had a Lisp for internal use that ran on the Eclipse under AOS (pre MV-8000) which may run on the MV-8000 as well. It was called Eclisp (naturally) and lexically scoped with optimized tail-recursion. I believe it was written largely in PL/N (is that the name?). It was a small system, with no compiler. Jeff Dalton Department Of Artificial Intelligence University of Edinburgh --------  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.25) id AA04801; Fri, 6 Apr 84 23:44:56 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.3) id AA23332; Fri, 6 Apr 84 23:45:07 pst Received: from csnet-relay (csnet-relay.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.25) id AA04797; Fri, 6 Apr 84 23:44:28 pst Message-Id: <8404070744.AA04797@UCB-VAX.ARPA> Received: by csnet-relay via xlsu; 7 Apr 84 2:33 EST Return-Path: Received: by lsu.CSNET ; Thu, 5 Apr 84 17:23:35 cst Date: Thu, 5 Apr 84 17:23:35 cst From: George R. Cross To: franz-friends%ucb-vax.arpa@csnet-relay.ARPA Subject: franz on dg? Does anyone know of an implementation of Franz LISP on the DG MV-8000 under AOS/VS? Or of any LISP whatsoever on the Data General? Thanks. George Cross Department of Computer Science Lousiana State University CSNET:  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.25) id AA04730; Fri, 6 Apr 84 23:38:45 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.3) id AA23287; Fri, 6 Apr 84 23:39:02 pst Received: from csnet-relay (csnet-relay.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.25) id AA04724; Fri, 6 Apr 84 23:38:25 pst Message-Id: <8404070738.AA04724@UCB-VAX.ARPA> Received: by csnet-relay via xlsu; 7 Apr 84 2:27 EST Return-Path: Received: by lsu.CSNET ; Wed, 4 Apr 84 20:44:25 cst Date: Wed, 4 Apr 84 20:44:25 cst From: George R. Cross To: FRANZ-FRIENDS%ucb-vax.arpa@csnet-relay.ARPA Subject: addname Please add the name , a CSNET address to the franz-friends mailing list. Thank you. George cross Department of Computer Science Louisiana State University Baton Rouge, LA 70803  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.25) id AA02741; Wed, 4 Apr 84 15:50:12 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.3) id AA07196; Wed, 4 Apr 84 15:44:42 pst Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.25) id AA01892; Wed, 4 Apr 84 15:14:05 pst Message-Id: <8404042314.AA01892@UCB-VAX.ARPA> Date: 4 Apr 1984 16:44:49-EST From: To: franz-friends@Berkeley Subject: Re: recent suggested fix to setf There was one mistake in my recent posting with fixes for the Franz setf function. I said that it was not necessary to remake liszt (the compiler). This was wrong: code compiled with an old copy of liszt will not use the modified setf definitions. The fix is simply to remake liszt after the new Franz interpreter has been generated. Sorry about any confusion. Steve Haflich MIT Experimental Music Studio decvax!genrad!mit-ems!smh smh@mit-ems@mit-mc  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.25) id AA22990; Thu, 29 Mar 84 12:14:00 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.3) id AA20323; Thu, 29 Mar 84 12:07:33 pst Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/4.25) id AA22790; Thu, 29 Mar 84 12:07:08 pst Received: by ucbdali.ARPA (4.24/4.22) id AA04139; Thu, 29 Mar 84 12:07:10 pst Date: Thu, 29 Mar 84 12:07:10 pst From: fateman%ucbdali@Berkeley (Richard Fateman) Message-Id: <8403292007.AA04139@ucbdali.ARPA> To: franz-friends@Berkeley Subject: commercialization of Franz Some people may have gotten the incorrect impression that the University of California will cease sending out tapes of Franz Lisp. We intend to continue distribution of the latest version which is the property of UCB. This is currently opus 38.91. This distribution works, so far as we know, on SUN releases (0.4, 1.0, 1.1) and Masscomp, and VAX 4.2BSD. Such distributions will continue, and will continue to be unsupported. Although we have made reasonable efforts to provide a useful, portable, efficient, and complete system, we have spent too much of our time and our sponsors' money in answering questions about installation-dependent difficulties or (what USUALLY turns out to be non-existent) bugs. I might point out that many of the questions come from commercial users. Franz Inc. was formed to provide a mechanism for support, transportation of Franz Lisp to new architectures, enhancements, documentation, etc. It has the (non-exclusive) right to use, distribute, (etc) Franz Lisp, and intends to produce enhancements that the University does not have funding for. I expect that if enhancements of Franz Lisp at UCB are produced, these will next be made available on 4.3 BSD tapes. Earlier distributions of contributed software or locally produced software MAY occur, but cannot be promised. I expect that there will continue to be a large number of Franz Lisp users who are satisfied with the university distribution (on 4.2BSD) or on the separate tapes (e.g. after opus 38.79) that UCB is sending out. Others will want the enhanced, supported, version from Franz Inc. The divergence of versions, some of which has already occurred with local variants of older systems being redistributed, seems inevitable regardless of Franz Inc. I hope this clarifies UCB's position.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.25) id AA23836; Wed, 28 Mar 84 06:14:04 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.3) id AA06408; Wed, 28 Mar 84 06:11:15 pst Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.25) id AA23759; Wed, 28 Mar 84 06:10:43 pst Message-Id: <8403281410.AA23759@UCB-VAX.ARPA> Date: 28 Mar 1984 09:09:38-EST From: To: franz-friends@Berkeley Subject: Fixes for setf return value problem As FranzFriends readers will know, my message several days ago generated a number of comments. The clear consensus was that setf should be fixed, not the documentation. This was obvious. The reason I didn't suggest the fix myself was that I felt it was far more important to preserve compatibility between Franz and the various other more-or-less-source-compatible Lisps (aka Common Lisps). It was my impression that code relying on the value returned by setf would not be portable. I have since learned that Common Lisp does indeed define setf to return the new value (its second argument), and that other implementations (i.e. MIT and Symbolics Lisp Machines) indeed work this way. (Mind you, I haven't checked this myself -- the information is second hand.) The fixes to setf are quite straightforward and are brief enough that I am including them below. For each case that the setf macro evaluates to a {rplaca, rplacd, rplacx} the corresponding {car, cdr, cxr} is now wrapped around it. The Liszt compiler seems smart enough to remove the extra reference if the value is ignored. The new setf functions follow. The starting version is the Opus 38.69 common2 identified by: ;; common2.l -[Fri Jul 8 17:46:13 1983 by layer]- (Although only two lines of setf-check-car+d were changed, the entire function is included because the change is difficult to locate by context.) I suggest these changes be made in the official sources. Whoever wants to install them should edit common2.l and remake the Franz interpreter. The Liszt compiler does not need to be changed. ==================== ; modified 27Mar84 SMH@MIT-EMS@MT-MC (see comment below) ; (defun setf-check-cad+r (name) (if (eq (getcharn name 1) #/c) then (let ((letters (nreverse (cdr (exploden name))))) (if (eq (car letters) #/r) then (do ((xx (cdr letters) (cdr xx))) ((null xx) ;; form is c{ad}+r, setf form is ;; (rplac (cr x)) (setq letters (nreverse letters)) (eval `(defsetf ,name (e v) ; SMH@MIT-EMS@MIT-MC ; added next line and matching rparen. (list ',(implode `(#/c ,(car letters) #/r)) (list ',(concat "rplac" (ascii (car letters))) (list ',(implode `(#/c ,@(cdr letters))) (cadr e)) v)))) ; SMH@MIT-EMS@MIT-MC t) (if (not (memq (car xx) '(#/a #/d))) then (return nil))))))) . . . ;--- other setf's for car's and cdr's are generated automatically ; ; modified 27Mar84 SMH@MIT-EMS@MIT-MC ; Now whenever setf macro expands to a rplac[adx], the corresponding c[adx]r ; is now wrapped around it so that setf consistently returns its second arg. ; The compiler is smart enough to remove the extra operation if the value ; is not used. ; (defsetf car (e v) `(car (rplaca ,(cadr e) ,v))) (defsetf caar (e v) `(car (rplaca (car ,(cadr e)) ,v))) (defsetf cadr (e v) `(car (rplaca (cdr ,(cadr e)) ,v))) (defsetf cdr (e v) `(cdr (rplacd ,(cadr e) ,v))) (defsetf cdar (e v) `(cdr (rplacd (car ,(cadr e)) ,v))) (defsetf cddr (e v) `(cdr (rplacd (cdr ,(cadr e)) ,v))) (defsetf cxr (e v) `(cxr ,(cadr e) (rplacx ,(cadr e) ,(caddr e) ,v))) . . . (defsetf nth (e v) `(car (rplaca (nthcdr ,(cadr e) ,(caddr e)) ,v))) (defsetf nthelem (e v) `(car (rplaca (nthcdr (1- ,(cadr e)) ,(caddr e)) ,v))) (defsetf nthcdr (e v) `(cdr (rplacd (nthcdr (1- ,(cadr e)) ,(caddr e)) ,v))) . . . ; (defsetf args (e v) `(args ,(cadr e) ,v)) ; no longer implemented? ==================== Steven Haflich MIT Experimental Music Studio (617)253-7441 smh@mit-ems@mit-mc decvax!genrad!mit-ems!smh  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.25) id AA15130; Tue, 27 Mar 84 18:41:12 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.3) id AA00513; Tue, 27 Mar 84 18:38:27 pst Received: from csnet-relay (csnet-relay.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.25) id AA15069; Tue, 27 Mar 84 18:38:19 pst Message-Id: <8403280238.AA15069@UCB-VAX.ARPA> Received: by csnet-relay via umcppo; 27 Mar 84 20:50 EST Date: 27 Mar 84 16:07:55 EST (Tue) From: Bruce Israel Subject: Re: bug in setf documentation To: franz-friends%ucb-vax.arpa%csnet-relay.csnet@csnet-relay.ARPA I modified 'setf' here a couple of years ago so that '(setf )' would always return . Its a fairly easy modification, but you have to make sure and avoid multiple evaluation in case creates side-effects. I'll be glad to send it out to anyone who wants it. Bruce Israel University of Maryland, Computer Science {rlgvax,seismo}!umcp-cs!israel (Usenet) israel.umcp-cs@CSNet-Relay (Arpanet)  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.25) id AA07215; Mon, 26 Mar 84 22:44:56 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.3) id AA18509; Mon, 26 Mar 84 22:39:35 pst Received: from MIT-MC (mit-mc.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.25) id AA07088; Mon, 26 Mar 84 22:39:19 pst Message-Id: <8403270639.AA07088@UCB-VAX.ARPA> Received: from SCRC-SUDBURY by SCRC-STONY-BROOK with CHAOS; Mon 26-Mar-84 16:28:29-EST Date: Mon, 26 Mar 84 16:29 EST From: "Richard L. Bryan" Subject: bug in setf documentation To: smh@mit-ems@mit-mc, franz-friends@Berkeley In-Reply-To: <8403241937.AA16797@UCB-VAX.ARPA> Date: 24 Mar 1984 14:36:31-EST From: The Franz manual carefully defines (setf g_refexpr 'g_value) to return g_value. Unfortunately, this is not true. If g_refexpr ultimately refers to the car or cdr of a list cell, the value returned will be the modified cell, not its car or cdr. Similarly, if g_refexpr is a cxr of a hunk, the entire hunk is returned. . . . The proper fix is to change the manual. If one were so bold as to plagarize a sentence from the (MIT) Lisp Machine Manual: "[T]he value produced by setf depends on the structure type and is not guaranteed; setf should be used for side effect only." Steve Haflich MIT Experimental Music Studio decvax!genrad!mit-ems!smh, smh@mit-ems@mit-mc To document such bugs is not the proper fix. The right thing is to fix the bugs: Introduce the modifier functions set-car, set-cdr, etc, supporting them (including, especially, compiler support) at the level that rplaca currently is; cause (setf (car x) y) to expand into (set-car x y) which returns y; and demote rplaca etc to become mere compatibility functions.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.25) id AA03617; Mon, 26 Mar 84 19:19:14 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.3) id AA15910; Mon, 26 Mar 84 19:15:12 pst Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.25) id AA03497; Mon, 26 Mar 84 19:15:00 pst Received: from ucbopal.CC.Berkeley.ARPA by ucbjade.CC.Berkeley.ARPA (4.14.noSUID/4.14.4) id AA12023; Mon, 26 Mar 84 19:15:36 pst Received: by ucbopal.CC.Berkeley.ARPA (4.14/4.14.1) id AA14120; Mon, 26 Mar 84 19:15:10 pst Date: Mon, 26 Mar 84 19:15:10 pst From: fkunze%ucbopal.CC@Berkeley (Fritz Kunze) Message-Id: <8403270315.AA14120@ucbopal.CC.Berkeley.ARPA> To: ucbvax!franz-friends@Berkeley, allegra!lindsay@Berkeley Subject: Re: SUNS Franz Inc has it, and will start shipping opus 40.00 on April 15, 1984. Contact: Franz Inc 6321 Thornhill Drive Oakland, CA 94611 (415) 339-1481 and ask for an order form. ---Fritz Kunze  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.25) id AA01476; Mon, 26 Mar 84 17:33:13 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.3) id AA14166; Mon, 26 Mar 84 17:22:21 pst Received: from PARC-GW.ARPA (parc-gw.ARPA.ARPA) by UCB-VAX.ARPA (4.24/4.25) id AA01296; Mon, 26 Mar 84 17:21:40 pst Message-Id: <8403270121.AA01296@UCB-VAX.ARPA> Received: from Zinfandel.ms by ArpaGateway.ms ; 26 MAR 84 13:53:52 PST Date: 26 Mar 84 13:49 PST From: Masinter.pa@PARC-GW.ARPA Subject: Re: bug in setf documentation In-Reply-To: <"smh@mit-ems"@mit-mc.ARPA>'s message of 24 Mar 84 14:36:31 EST To: "smh@mit-ems"@mit-mc.ARPA Cc: franz-friends@Berkeley in Interlisp, the thing which corresponds to SETF is "change". (change (CAR X) mumble) translates to (CAR (RPLACA X mumble)) The compiler actually optimizes away the CAR in the case that the value is not used, so this only costs if you depend on the value. One could implement this in a different way, but having SETF or change or whatever guarantee the value returned seems reasonable to me; if you can't guarantee it, then make it NIL or no value.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.25) id AA04335; Mon, 26 Mar 84 15:17:14 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.3) id AA11382; Mon, 26 Mar 84 15:10:08 pst Received: by UCB-VAX.ARPA (4.24/4.25) id AA04133; Mon, 26 Mar 84 15:09:24 pst Received: by allegra.UUCP (4.12/4.7) id AA09427; Mon, 26 Mar 84 14:49:06 est Date: Mon, 26 Mar 84 14:49:06 est From: allegra!lindsay@Berkeley (Lindsay Schachinger) Message-Id: <8403261949.AA09427@allegra.UUCP> To: ucbvax!franz-friends@Berkeley Subject: SUNS does anyone out there have franz running on a sun under 4.2?  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.25) id AA16841; Sat, 24 Mar 84 11:40:10 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.3) id AA16334; Sat, 24 Mar 84 11:37:41 pst Received: from MIT-MC (mit-mc.arpa.ARPA) by UCB-VAX.ARPA (4.24/4.25) id AA16797; Sat, 24 Mar 84 11:37:32 pst Message-Id: <8403241937.AA16797@UCB-VAX.ARPA> Date: 24 Mar 1984 14:36:31-EST From: To: franz-friends@Berkeley Subject: bug in setf documentation The Franz manual carefully defines (setf g_refexpr 'g_value) to return g_value. Unfortunately, this is not true. If g_refexpr ultimately refers to the car or cdr of a list cell, the value returned will be the modified cell, not its car or cdr. Similarly, if g_refexpr is a cxr of a hunk, the entire hunk is returned. The examples which accompany setf in the manual make clear what is happening. The returned value is the result of the rplac[adx] generated by the setf macro. Unfortunately, in Franz and most other Lisps the value returned by the rplac[adx] functions is inconsistent with that returned by the various modifier functions for symbols, arrays, and vectors. All this is unfortunate, as one of the main reasons for setf is to insulate code from the representation of an object such as might be defined, for example, by defstruct. The proper fix is to change the manual. If one were so bold as to plagarize a sentence from the (MIT) Lisp Machine Manual: "[T]he value produced by setf depends on the structure type and is not guaranteed; setf should be used for side effect only." Steve Haflich MIT Experimental Music Studio decvax!genrad!mit-ems!smh, smh@mit-ems@mit-mc  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.25) id AA16841; Sat, 24 Mar 84 11:40:10 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.3) id AA16334; Sat, 24 Mar 84 11:37:41 pst Received: from MIT-MC (mit-mc.arpa.ARPA) by UCB-VAX.ARPA (4.24/4.25) id AA16797; Sat, 24 Mar 84 11:37:32 pst Message-Id: <8403241937.AA16797@UCB-VAX.ARPA> Date: 24 Mar 1984 14:36:31-EST From: To: franz-friends@Berkeley Subject: bug in setf documentation The Franz manual carefully defines (setf g_refexpr 'g_value) to return g_value. Unfortunately, this is not true. If g_refexpr ultimately refers to the car or cdr of a list cell, the value returned will be the modified cell, not its car or cdr. Similarly, if g_refexpr is a cxr of a hunk, the entire hunk is returned. The examples which accompany setf in the manual make clear what is happening. The returned value is the result of the rplac[adx] generated by the setf macro. Unfortunately, in Franz and most other Lisps the value returned by the rplac[adx] functions is inconsistent with that returned by the various modifier functions for symbols, arrays, and vectors. All this is unfortunate, as one of the main reasons for setf is to insulate code from the representation of an object such as might be defined, for example, by defstruct. The proper fix is to change the manual. If one were so bold as to plagarize a sentence from the (MIT) Lisp Machine Manual: "[T]he value produced by setf depends on the structure type and is not guaranteed; setf should be used for side effect only." Steve Haflich MIT Experimental Music Studio decvax!genrad!mit-ems!smh, smh@mit-ems@mit-mc  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.25) id AA17828; Sat, 17 Mar 84 21:45:47 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.22) id AA12843; Sat, 17 Mar 84 21:39:13 pst Received: from CMU-CS-A (cmu-cs-a.ARPA) by UCB-VAX.ARPA (4.24/4.25) id AA17726; Sat, 17 Mar 84 21:40:46 pst Date: 18 Mar 84 0040 EST (Sunday) From: Michael.Shamos@CMU-CS-A To: franz-friends@Berkeley Subject: Copyright laws Message-Id: <18Mar84.004047.MS20@CMU-CS-A> What can I say but to remind RMS that patents and copyrights are provided for in the Constitution specifically? None of the prohibitions he despises is mandated by or mentioned in the Constitution, to wit, the draft, drug laws, laws against fornication, unrelated people sharing houses, etc. There has never been a serious constitutional challenge to the Copyright Act, even though it is one of the earliest U.S. statutes. Laws against all of the other conduct listed above have been so challenged, in some cases successfully. What is this stuff doing on Franz-Friends anyway? Let's hear it for Info-Law.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.25) id AA12519; Sat, 17 Mar 84 13:51:26 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.22) id AA05623; Sat, 17 Mar 84 13:45:58 pst Received: from SU-AI.ARPA by UCB-VAX.ARPA (4.24/4.25) id AA12441; Sat, 17 Mar 84 13:47:35 pst Message-Id: <8403172147.AA12441@UCB-VAX.ARPA> Date: 17 Mar 84 1347 PST From: Rod Brooks Subject: Don't use Franz sortcar! To: franz-friends@Berkeley Somewhat bizzarely it seems that Franz Lisp sort and sortcar have different time complexities. sort is good and sortcar is bad so I suggest you convert your sortcar's to sort's until someone sorts this out. The code and transcript below use both sort and sortcar to sort a list of length n (the list happens to start in precisely reverse order). A count of the number of calls to the comparison function is kept. The results show that sort takes n*log(n) comparisons while sortcar takes n*n. The problem should be fixable by throwing out code as there must be two sorters lurking in there! ;;;;;;;;;;;;;;; (defun gen (n) (do ((i 0 (1+ i)) (l () (cons (cons i ()) l))) ((= i n) l))) (defun compare (x y) (setq *count* (1+ *count*)) (< x y)) (defun compare-cars (x y) (compare (car x) (car y))) (defun count-sort (n) (let ((*count* 0)) (sort (gen n) #'compare-cars) *count*)) (defun count-sortcar (n) (let ((*count* 0)) (sortcar (gen n) #'compare) *count*)) (defun test (n) (let ((csort (count-sort n)) (csortcar (count-sortcar n))) (list n csort csortcar (/$ (float csort) (*$ (float n) (log n))) (/$ (float csortcar) (float (* n n)))))) ;;;;;;;;;;;;;;; Here's the transcript. The lists of 5 elements are: n compares for sort compares for sortcar compares for sort / n*log(n) compares for sortcar / n*n Franz Lisp, Opus 38 -> (load 'test) t -> (test 3) (3 3 6 0.910239226626837 0.6666666666666667) -> (test 100) (100 460 9900 0.9988773083774791 0.99) -> (test 200) (200 1020 39800 0.9625697456705496 0.995) -> (test 300) (300 1440 89700 0.8415468193831012 0.9966666666666667) -> (test 400) (400 2240 159600 0.9346629619469353 0.9975) ->  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.24/4.25) id AA20270; Fri, 16 Mar 84 08:41:47 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.24/4.22) id AA16035; Fri, 16 Mar 84 08:36:48 pst Received: from MIT-MC (mit-mc.ARPA) by UCB-VAX.ARPA (4.24/4.25) id AA20188; Fri, 16 Mar 84 08:38:13 pst Message-Id: <8403161638.AA20188@UCB-VAX.ARPA> Date: Fri 16 Mar 84 11:36:20-EST From: RMS%MIT-OZ@MIT-MC.ARPA Subject: Disgusting Copyright Laws To: franz-friends@Berkeley Another thing people can do when they see injustices and corruption supported by te copyright laws, if writing to a congressman does not seem likely to produce any noticeable result, is to treat these laws like the other laws whose consequences are wrong: draft laws, drug laws, laws against fornication, laws against three unrelated people sharing an apartment,... -------  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.25) id AA04968; Thu, 15 Mar 84 00:20:37 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA06811; Thu, 15 Mar 84 00:12:55 pst Received: from CMU-CS-A (cmu-cs-a.ARPA) by UCB-VAX.ARPA (4.22/4.25) id AA04390; Wed, 14 Mar 84 23:42:13 pst Date: 15 Mar 84 0241 EST (Thursday) From: Michael.Shamos@CMU-CS-A To: franz-friends@Berkeley Subject: Software, Scribe, Universities and Copyright Message-Id: <15Mar84.024125.MS20@CMU-CS-A> I'm not usually a reader of the Franz mailing list, but I was perusing the Franz-Lisp BBOARD at CMU and was amazed to find a recent extensive discussion of software, universities and copyrights. I was even more amazed to see my name mentioned in connection with Scribe at CMU. I know I am fated to tell and re-tell this story for the rest of my life, but here goes again: No lawsuit of any kind concerning the rights to Scribe was ever filed. A dispute arose that was settled after extensive discussions between Unilogic and CMU. The result was that CMU quite properly acknowledged in writing that Unilogic owns all rights in Scribe. Before CMU could acknowledge this, it needed to conduct a factual investigation into the circumstances of Scribe development, which partially accounted for the protracted talks. Let me emphasize that the reason Brian Reid owned Scribe and was able to transfer the rights to Unilogic is that the CMU Patent Policy specifically provides that graduate students own their patents and copyrights, even if they create works using substantial university resources. The situation is not the same at other universities. It is true that I stated on many occasions that CMU ``had no leg to stand on'' and I always believed so, because Brian was a graduate student at all relevant times and the policy provision that applied to him was clear. Everyone who says that the issue of rights to software is complex is correct. As an intellectual property attorney with academic connections, I am regularly surprised at my intelligent colleagues who are unable to distinguish between what the law is and what they feel the law ought to be. When the U.S. Government funds university research or development, it is usual for it to grant back intellectual property rights to the institution involved, reserving certain rights for itself, normally government-wide royalty-free use. The Government is NOT the same as the Public. Just because the White House is supported with public funds does not mean that I can spend the night there just because I want to. Funded research does NOT automatically become Public Domain. Nor does a statement by the Principal Investigator that he would like it to be Public Domain cause that to happen, either, since the PI is not the owner of the technology and can't give away what he doesn't own. It is possible for there to exist a contract between the university and its faculty members providing that they own all or a portion of the research they do under certain circumstances. In this case, a Government grant-back to the institution would flow back again to the individual. Thus people (and companies) can end up owning technology whose development was supported with Government funds. I know that many people are repelled by such a concept, but that doesn't make it false. You may write to your Congressmen to get the statutes changed, but it is believed as a matter of Government doctrine that business will not invest capital in technology to which it cannot obtain proprietary rights. Incidentally, ``Public Domain'' means ``free of proprietary restrictins and available for unrestricted use by anyone.'' In the absence of a declaration by the owner that a work is Public Domain, it is difficult under the present statute for the work to become so. Contrary to a statement that I saw here earlier, works created with Government funding or support are not a fuzzy area at all. The Copyright Law (17 U.S.C. 105) states that ``Copyright protection . . . is not available for any work of the United States Government.'' Because works produced under research contracts are not owned by the Government, they are not works for hire of the Government and thus do not fall under the above clause. It is not the case that Government funding requires an institution to give technology away to all who insist on a copy. Some institutions do this because they feel it is a good policy to implement, but no one is obliged to do it. Of course, this whole discussion should be moved to the INFO-LAW mailing list. Nobody has sent a message to it in about a year and a half. Mike Shamos President, Unilogic, Ltd.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.25) id AA27190; Sun, 11 Mar 84 19:39:13 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA02875; Sun, 11 Mar 84 19:28:48 pst Received: from SUMEX-AIM.ARPA by UCB-VAX.ARPA (4.22/4.25) id AA27023; Sun, 11 Mar 84 19:17:11 pst Message-Id: <8403120317.AA27023@UCB-VAX.ARPA> Date: Sun 11 Mar 84 19:16:23-PST From: Gordon Novak Subject: GLISP and GEV for FRANZ To: franz-friends@Berkeley GLISP and its window-based display editor, GEV, are now available for Franz Lisp. The files can be gotten from the directory on the Arpanet host SUMEX-AIM. (The login "anonymous guest" can be used for FTP.) The files are GLISPR.FRANZ, GLISPA.FRANZ, GLISPB.FRANZ, and GEVT.FRANZ ; a test file is GLTEST.FRANZ . The manual is GLUSER.LPT and GEV.HLP . To try the system, compile the first four files, then load in the order above, load the test file, and try (gev c 'circle) and (gev hpp 'project). Bug reports to Novak@UTEXAS-20. Enjoy... -------  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.25) id AA26699; Sun, 11 Mar 84 18:50:55 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA02286; Sun, 11 Mar 84 18:39:04 pst Received: from UTEXAS-20.ARPA by UCB-VAX.ARPA (4.22/4.25) id AA26616; Sun, 11 Mar 84 18:45:29 pst Message-Id: <8403120245.AA26616@UCB-VAX.ARPA> Date: Sun 11 Mar 84 20:45:55-CST From: Gordon Novak Jr. Subject: GLISP and GEV for FRANZ To: franz-friends@Berkeley Cc: CS.NOVAK@UTEXAS-20.ARPA GLISP and its window-based display editor, GEV, are now available for Franz Lisp. The files can be gotten from the directory on the Arpanet host SUMEX-AIM. (The login "anonymous guest" can be used for FTP.) The files are GLISPR.FRANZ, GLISPA.FRANZ, GLISPB.FRANZ, and GEVT.FRANZ ; a test file is GLTEST.FRANZ . The manual is GLUSER.LPT and GEV.HLP . To try the system, compile the first four files, then load in the order above, load the test file, and try (gev c 'circle) and (gev hpp 'project). Bug reports to Novak@UTEXAS-20. Enjoy... -------  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.25) id AA24954; Sun, 11 Mar 84 16:12:11 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA00715; Sat, 10 Mar 84 23:00:03 pst Received: from SUMEX-AIM.ARPA by UCB-VAX.ARPA (4.22/4.25) id AA14248; Sat, 10 Mar 84 23:27:04 pst Message-Id: <8403110727.AA14248@UCB-VAX.ARPA> Date: Sat 10 Mar 84 23:26:39-PST From: Bill White Subject: GLISP users? To: franz-friends@Berkeley We are currently using GLISP in Interlisp and intend to transport much of our work to GLISP in Franz. I'm interested in comparing notes or experiences with any other Franzlisp users who are also using GLISP. If you are interested, please send me your name and one or more phone numbers where I can call you. I can be reached at 415/327-6600 (day) or 415/961-4837 (eve). Thanks. Bill White -------  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.25) id AA14126; Wed, 7 Mar 84 06:00:08 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA12891; Wed, 7 Mar 84 05:57:46 pst Received: by UCB-VAX.ARPA (4.22/4.25) id AA14053; Wed, 7 Mar 84 05:56:54 pst From: ihnp4!ihdba!jdu@Berkeley Date: 7 Mar 84 07:35:49 CST (Wed) Message-Id: <8403071335.AA08469@ihnp4.ATT.UUCP> Received: by ihnp4.ATT.UUCP (sendmail 4.12/9-Jan-84) id AA08469; 7 Mar 84 07:35:49 CST (Wed) Apparently-To: !ucbvax!franz-friends Please add me to your list. I use and maintain Franz LISP on several VAX 11/780s running SYS V at AT&T Bell Laboratories, Naperville, IL. It is used for instruction in an ih-house course. Please don't ask me for the SYS V mods. I can't send them to you without going through a LOT of red tape with many approvals, including one from the lawyers and probably form the UN*X support group. I am running 38.79 which I converted from the 4.2 distribution. Thanks, John Unruh AT&T Bell Laboratories Naperville-Wheaton Rd. Room 8B-208 Naperville, IL 60566 (312)979-2012 ...ihnp4!ihdba!jdu  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.25) id AA02047; Tue, 6 Mar 84 18:54:15 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA06848; Tue, 6 Mar 84 18:44:17 pst Received: from CMU-CS-A (cmu-cs-a.ARPA) by UCB-VAX.ARPA (4.22/4.25) id AA01857; Tue, 6 Mar 84 18:43:22 pst Date: 6 Mar 84 1906 EST (Tuesday) From: Lars.Ericson@CMU-CS-A To: franz-friends@Berkeley Subject: Re: Software--Who owns it? In-Reply-To: <8403050517.AA08313@ucbdali.ARPA> Message-Id: <06Mar84.190634.LE60@CMU-CS-A> There is a simple way of dealing with universities who refuse to cough up software to the Government agency that funded it: refuse to fund subsequent projects.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.25) id AA20697; Sun, 4 Mar 84 13:57:20 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA04267; Sun, 4 Mar 84 13:54:40 pst Received: from BRL-BMD (brl-bmd.ARPA) by UCB-VAX.ARPA (4.22/4.25) id AA20630; Sun, 4 Mar 84 13:53:40 pst Message-Id: <8403042153.AA20630@UCB-VAX.ARPA> Date: Sun, 4 Mar 84 16:48:09 EST From: Paul Broome To: Franz-friends@Berkeley Cc: Brint Cooper Subject: [Brint: Software--Who owns it?] Re: the discussion about Franz flavors and copyright. Can anyone answer my friends question? ----- Forwarded message # 1: Date: Sat, 3 Mar 84 17:12:30 EST From: Brint To: broome@BRL-BMD Subject: Software--Who owns it? Paul, I've just reviewed the six (count 'em--6) packages of info you sent me on software and who owns it. All but one discuss the conflict between a professor and her university. Have you run across much about the issue of the Government's rights in the case where development was publically funded? In other words, if a contractor wants to take a 'university' owned product and market it for big bucks, I really don't care. But when one government agency has to pay for a license when it has previously paid for development, I think the taxpayers would like to know about it. -B- ----- End of forwarded messages  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.25) id AA00053; Mon, 5 Mar 84 01:40:50 pst Received: from ucbdali.ARPA by ucbkim.ARPA (4.16/4.22) id AA08207; Sun, 4 Mar 84 21:25:23 pst Received: by ucbdali.ARPA (4.22/4.22) id AA08313; Sun, 4 Mar 84 21:17:38 pst Date: Sun, 4 Mar 84 21:17:38 pst From: fateman%ucbdali@Berkeley (Richard Fateman) Message-Id: <8403050517.AA08313@ucbdali.ARPA> To: broome@brl-bmd Subject: Re: [Brint: Software--Who owns it?] Cc: franz-friends%ucbdali@Berkeley The government's rights in software is generally stated in the contract between a university and a government agency. Often it says something like the government has non-exclusive royalty free rights to use, (copy, distribute, etc), developments. If the gov't is not set up to distribute to other gov't agencies, and/or makes no effort to obtain the software in question, then the gov't ends up buying it from the marketeers. Sometimes, of course, the university refuses to cough up the software, or provides it in (say) hard-copy only form.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.25) id AA19473; Thu, 1 Mar 84 12:57:54 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA19179; Thu, 1 Mar 84 12:51:42 pst Received: from MIT-MC (mit-mc.ARPA) by UCB-VAX.ARPA (4.22/4.25) id AA19295; Thu, 1 Mar 84 12:51:02 pst Message-Id: <8403012051.AA19295@UCB-VAX.ARPA> Received: from SCRC-CHICOPEE by SCRC-QUABBIN with CHAOS; Thu 1-Mar-84 15:47:37-EST Date: Thu, 1 Mar 84 15:47 EST From: "Daniel L. Weinreb" Subject: Franz flavor package To: franz-friends@Berkeley, alan@MIT-MC.ARPA Cc: lisp-designers%SCRC-TENEX@MIT-MC.ARPA Some mail was sent around recently regarding the implementation of Flavors that Prof. Richard Zippel brought up for Franz Lisp. MIT and Symbolics have had some discussions about it, and these discussions reached a conclusion yesterday. Symbolics feels that it does not have anything to do with this -- none of the code that Zippel started with was in any way Symbolics-proprietary. MIT is free to do with this code what it wishes. We imagine that what MIT will do is to license it for free to whomever wants it. Please forward this message to anyone who may be concerned with the issue. Thank you. Dan Weinreb Director, Software Development Symbolics  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.25) id AA13465; Thu, 1 Mar 84 08:15:39 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA16399; Thu, 1 Mar 84 08:12:51 pst Received: from CMU-CS-A (cmu-cs-a.ARPA) by UCB-VAX.ARPA (4.22/4.25) id AA13396; Thu, 1 Mar 84 08:12:27 pst Date: 1 Mar 84 1102 EST (Thursday) From: Lars.Ericson@CMU-CS-A To: Mike Caplinger Subject: Re: copyrights and similar legal hogwash Cc: franz-friends@Berkeley In-Reply-To: <8402290700.AA28726@RICE> Message-Id: <01Mar84.110238.LE60@CMU-CS-A> Legal considerations are most definitely relevant to scientists, if it means that you can no longer use a piece of code that you wrote yourself, or distribute it to people freely if yu would like to do so. Free distribution is an important method for communicating research results which is peculiar to computer science, and which is relied upon often. When universities hold the profit motive foremost, the result is a prejudicial influence on our particular domain, which has come about as a result of the very unfortunate fact that what we do tends to be highly profitable.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.25) id AA04580; Tue, 28 Feb 84 23:05:23 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA26087; Tue, 28 Feb 84 23:02:28 pst Received: from RICE (rice.ARPA) by UCB-VAX.ARPA (4.22/4.25) id AA04527; Tue, 28 Feb 84 23:01:48 pst Received: by RICE (AA28726); Wed, 29 Feb 84 01:00:53 cst Date: Wed, 29 Feb 84 01:00:53 cst From: Mike Caplinger Message-Id: <8402290700.AA28726@RICE> To: franz-friends@Berkeley Subject: Re: copyrights and similar legal hogwash Can we move this discussion to a more appropriate list, like INFO-LAW, or better, into a null device somewhere? Legal considerations are NOT productive in terms of computer science research; I, and I hope most of the readers of this list, put computer science first and formost. Lawyers have never done anything for my research but gotten in my way.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.25) id AA01975; Tue, 28 Feb 84 19:33:41 pst Received: from ucbdali.ARPA by ucbkim.ARPA (4.16/4.22) id AA23477; Tue, 28 Feb 84 19:30:24 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbdali.ARPA (4.22/4.22) id AA09945; Tue, 28 Feb 84 19:30:16 pst Received: from yale (yale.ARPA) by UCB-VAX.ARPA (4.22/4.25) id AA01898; Tue, 28 Feb 84 19:29:28 pst Message-Id: <8402290329.AA01898@UCB-VAX.ARPA> Received: by YALE-BULLDOG via CHAOS; Tue, 28 Feb 84 22:24:40 EST Date: Tue, 28 Feb 84 22:20:03 EST From: John R Ellis Subject: Re: Franz Flavors & software copyright To: wilensky%ucbdali@Berkeley Cc: franz-friends%ucbdali@Berkeley, andy@AIDS-UNIX.ARPA In-Reply-To: wilensky%ucbdali@UCB-VAX.ARPA, Tue, 28 Feb 84 13:44:07 pst Of course, Yale may take any position they like on the issue, but that does not mean it makes any legal sense whatsoever. To avoid misunderstandings: Except where I explicitly stated otherwise, I was not relating Yale's interpretation of the law, but the opinion of an independent lawyer whose firm specializes in patent and copyright law. -------  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.25) id AA26151; Tue, 28 Feb 84 14:04:36 pst Received: from ucbdali.ARPA by ucbkim.ARPA (4.16/4.22) id AA18387; Tue, 28 Feb 84 13:57:23 pst Received: by ucbdali.ARPA (4.22/4.22) id AA06810; Tue, 28 Feb 84 13:44:07 pst Date: Tue, 28 Feb 84 13:44:07 pst From: wilensky%ucbdali@Berkeley (Robert Wilensky) Message-Id: <8402282144.AA06810@ucbdali.ARPA> To: Ellis@YALE.ARPA, wilensky%ucbdali@Berkeley Subject: Re: Franz Flavors & software copyright Cc: franz-friends%ucbdali@Berkeley, andy@AIDS-UNIX.ARPA I intended my comments in full awareness of the contractual aspect the copyright law. As I believe I mentioned, the University does NOT have rights to lecture notes, or videos, even though they explicitly paid you to give lectures, because they paid you to GIVE them only (this statement is based on legal precedent, not on my opinion). Of course, Yale may take any position they like on the issue, but that does not mean it makes any legal sense whatsoever. Similarly, the university suggests that you do research (i. e., they cannot fire you for not doing it (once you have tenure) as they can for not giving lectures). More specifically, they do not explicitly require that you write programs (or books) as part of this work, and thus have no rights to either. I am not aware that the university has been granted the right to copyrights on gov't-funded work. This would certainly change the picture. However, it's hard to believe, since they would then own the copyright on all the technical books we have written on sold based on this research, and as they have not claimed this right, it is hard to imagine they have it. However, as has been wisely pointed out, I am not a lawyer (and you're probably not either), and I would not advise anyone to take any of this discussion too seriously. However, if you are an author of a piece of software, you should get your own lawyer, because your university is most likely trying to bamboozle you.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.25) id AA11253; Mon, 27 Feb 84 23:06:23 pst Received: from ucbdali.ARPA by ucbkim.ARPA (4.16/4.22) id AA09593; Mon, 27 Feb 84 23:00:32 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbdali.ARPA (4.22/4.22) id AA01681; Mon, 27 Feb 84 23:00:06 pst Received: from yale (yale.ARPA) by UCB-VAX.ARPA (4.22/4.25) id AA11073; Mon, 27 Feb 84 22:59:19 pst Message-Id: <8402280659.AA11073@UCB-VAX.ARPA> Received: by YALE-BULLDOG via CHAOS; Tue, 28 Feb 84 01:56:09 EST Date: Tue, 28 Feb 84 01:53:48 EST From: John R Ellis Subject: Re: Franz Flavors & software copyright To: fateman%ucbdali@Berkeley Cc: franz-friends%ucbdali@Berkeley In-Reply-To: fateman%ucbdali@UCB-VAX.ARPA, Mon, 27 Feb 84 22:12:58 pst Because patents have been covered by explicit agreement every place I've worked (Harvard, MIT, UC Berkeley, and various industrial firms), I assume if there were no agreements of that nature that universities would NOT own patents at all. Whether or not universities own patents without a contract clause is besides the point. My lawyer's argument was that there was ample precedent in patent law that considers faculty as employees of universities and their research as a normal part of their employment (i.e. "work for hire"). Thus he considered it likely that the same definitions would apply to copyright law. I disagree: writing programs is NOT part of a computer science professor's research. It is usually quite incidental to his research: He doesn't get paid depending upon the production of a program or not. Funny, I can name at least three professors at Yale, two of them tenured, for whom writing real programs is an essential part of their research. I'm sure there are many other professors at other institutions who consider programming an integral part of their research. Whether or not a professor is paid for the production of a particular program is irrelevant: all that matters is whether the programming was part of the normal activities of his employment. -------  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.25) id AA10414; Mon, 27 Feb 84 22:14:54 pst Received: from ucbdali.ARPA by ucbkim.ARPA (4.16/4.22) id AA08818; Mon, 27 Feb 84 22:02:22 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbdali.ARPA (4.22/4.22) id AA01115; Mon, 27 Feb 84 22:02:03 pst Received: from yale (yale.ARPA) by UCB-VAX.ARPA (4.22/4.25) id AA09919; Mon, 27 Feb 84 21:43:51 pst Message-Id: <8402280543.AA09919@UCB-VAX.ARPA> Received: by YALE-BULLDOG via CHAOS; Tue, 28 Feb 84 00:40:49 EST Date: Tue, 28 Feb 84 00:39:03 EST From: John R Ellis Subject: Re: Franz Flavors & software copyright To: fateman%ucbdali@Berkeley Cc: franz-friends%ucbdali@Berkeley In-Reply-To: fateman%ucbdali@UCB-VAX.ARPA, Mon, 27 Feb 84 20:06:02 pst A professor probably doesn't think of his research, or programming as "work for hire". ... It certainly is possible for universities to make such claims, and some but not all, do. Some make distinctions between researchers and employees Some make distinctions between researchers and employees who are (for example) programmers. This does not mean that the claims will withstand legal challenges. I agree that the ultimate test will be court challenges. But the law is clearly worded -- an employer owns employees' copyrights for written material created by the employee as part of his normal job, unless their contract says differently. By all common definitions a professor is employed by the university to do research, and writing programs is part of a computer science professor's research. I've talked to a lawyer who specializes in patent and copyright law. He said there is quite a bit of overlap between the two areas; for example, in the recent videotaping/copyright infringement case, the Supreme Court referred to precedents in patent law. He said it's long been established that universities have the right to claim ownership over patents resulting from the work of employees, including faculty. The lawyer pointed out, reasonably enough, that since patent law considers faculty research as "work for hire" (work performed by employees as part of their job), it was very likely that the same concept would extend into copyright law. -------  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.25) id AA10591; Mon, 27 Feb 84 22:29:31 pst Received: from ucbdali.ARPA by ucbkim.ARPA (4.16/4.22) id AA09127; Mon, 27 Feb 84 22:22:14 pst Received: by ucbdali.ARPA (4.22/4.22) id AA01329; Mon, 27 Feb 84 22:21:48 pst Date: Mon, 27 Feb 84 22:21:48 pst From: fateman%ucbdali@Berkeley (Richard Fateman) Message-Id: <8402280621.AA01329@ucbdali.ARPA> To: Ellis@YALE.ARPA Subject: Re: Franz Flavors & software copyright Cc: franz-friends%ucbdali@Berkeley I disagree: writing programs is NOT part of a computer science professor's research. It is usually quite incidental to his research: He doesn't get paid depending upon the production of a program or not. I suspect that this is the kind of thing that courts decide. .... Because patents have been covered by explicit agreement every place I've worked (Harvard, MIT, UC Berkeley, and various industrial firms), I assume if there were no agreements of that nature that universities would NOT own patents at all.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.25) id AA08342; Mon, 27 Feb 84 20:26:49 pst Received: from ucbdali.ARPA by ucbkim.ARPA (4.16/4.22) id AA07600; Mon, 27 Feb 84 20:24:13 pst Received: by ucbdali.ARPA (4.22/4.22) id AA28291; Mon, 27 Feb 84 20:06:02 pst Date: Mon, 27 Feb 84 20:06:02 pst From: fateman%ucbdali@Berkeley (Richard Fateman) Message-Id: <8402280406.AA28291@ucbdali.ARPA> To: ellis@yale Subject: Re: Franz Flavors & software copyright Cc: franz-friends%ucbdali@Berkeley From Ellis@YALE Mon Feb 27 17:15:31 1984 ..... If a university professor writes a program as part of his research, that sure seems to be a normal part of his employment. This is, I think, arguable. A professor probably doesn't think of his research, or programming as "work for hire". Ditto for grad students, except perhaps those being paid in a non-research capacity. So it seems perfectly reasonable under the law for a university to claim ownership of a program written by its employees, including professors. It certainly is possible for universities to make such claims, and some but not all, do. Some make distinctions between researchers and employees who are (for example) programmers. This does not mean that the claims will withstand legal challenges. I think Ellis's explanation of the Yale situation is similar to Berkeley's current operation, which is, however, undergoing substantial scrutiny at this time.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.25) id AA05605; Mon, 27 Feb 84 17:19:28 pst Received: from ucbdali.ARPA by ucbkim.ARPA (4.16/4.22) id AA04716; Mon, 27 Feb 84 17:13:20 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbdali.ARPA (4.22/4.22) id AA25222; Mon, 27 Feb 84 17:13:06 pst Received: from yale (yale.ARPA) by UCB-VAX.ARPA (4.22/4.25) id AA05494; Mon, 27 Feb 84 17:12:27 pst Message-Id: <8402280112.AA05494@UCB-VAX.ARPA> Received: by YALE-BULLDOG via CHAOS; Mon, 27 Feb 84 20:07:52 EST Date: Mon, 27 Feb 84 19:57:35 EST From: John R Ellis Subject: Re: Franz Flavors & software copyright To: wilensky%ucbdali@Berkeley Cc: andy@AIDS-UNIX.ARPA, franz-friends%ucbdali@Berkeley In-Reply-To: wilensky%ucbdali@UCB-VAX.ARPA, Wed, 22 Feb 84 09:57:21 pst But I want to stress my main point. This is that the ``author'' holds the copyright. It may be unclear who the author is, but it is clearly NOT the university. The recent changes to copyright law specify that the copyrights of material created on the job as part of an employee's normal duties belong to the employer, unless explicitly stated in the employee's contract. That is, if DEC hires you as a computer science researcher, programs written as part of your research belong to DEC; but if you write an article on science fiction in your spare time, that belongs to you. If a university professor writes a program as part of his research, that sure seems to be a normal part of his employment. The law also states that unless otherwise modified by special agreement, grantees (e.g. universities) will own the copyrights and patents arising from government-funded research. (A university is always the legal grantee, not the principal investigator.) There is also something about how the government retains the right to use such copyrights and patents for their own purposes. So it seems perfectly reasonable under the law for a university to claim ownership of a program written by its employees, including professors. But what about textbooks, lecture notes, articles, etc. published by professors? Do universities own the copyrights to such material? If these things were written as a normal part of their employment, then again, it sure seems that the universities could claim ownership. Yale's position on copyright is interesting: As a matter of tradition, they automatically grant ownership of non-software material to the author. They retain software copyrights, veiwing software more as inventions than as literary works. They believe, however, they have the right to claim ownership over all copyrights if they choose to excercise that right. (One could imagine the faculty uproar if they tried that; presumably their contracts would soon be modified to explicitly grant them ownership.) What about graduate students? Are they employees performing work for hire? It's not at all clear. In most cases the IRS doesn't consider fellowships as salary -- no grad student at Yale pays income tax on his fellowship, whether it is related to a specific grant or comes from general University funds. Grad students aren't expected to perform any duties like a regular employee. Grad students generally don't sign a contract of employment. In what sense is a "student" an employee? CMU took Unilogic to court over the copyright to Scribe, which was written by Brian Ried while a grad student. I have heard that the suit was settled out of court; there was an UNSUBSTANTIATED RUMOR that Michael Shamos, president of Unilogic, said afterwards "CMU didn't have a leg to stand on." -------  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.25) id AA15994; Mon, 27 Feb 84 06:53:05 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA24295; Mon, 27 Feb 84 06:50:59 pst Received: from MIT-MC (mit-mc.ARPA) by UCB-VAX.ARPA (4.22/4.25) id AA15970; Mon, 27 Feb 84 06:50:36 pst Message-Id: <8402271450.AA15970@UCB-VAX.ARPA> Received: from DUPAGE by SCRC-QUABBIN with CHAOS; Mon 27-Feb-84 09:55:17-EST Date: Mon, 27 Feb 84 09:47 EST From: Richard Pavelle Subject: Mailing list addition To: franz-friends@Berkeley Cc: rp%SCRC-TENEX@MIT-MC.ARPA Please add me to the mailing list. Thanks.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.25) id AA01447; Fri, 24 Feb 84 17:42:28 pst Received: from ucbdali.ARPA by ucbkim.ARPA (4.16/4.22) id AA16486; Wed, 22 Feb 84 09:58:43 pst Received: by ucbdali.ARPA (4.22/4.22) id AA06784; Wed, 22 Feb 84 09:57:21 pst Date: Wed, 22 Feb 84 09:57:21 pst From: wilensky%ucbdali@Berkeley (Robert Wilensky) Message-Id: <8402221757.AA06784@ucbdali.ARPA> To: andy@aids-unix, franz-friends%ucbdali@Berkeley Subject: Re: Franz Flavors & software copyright In-Reply-To: Your message of 21 Feb 1984 16:29-PST Thanks for your clarification. Everything you said is consistent with my understanding of the situation. And you are correct in emphasizing the complexity of the issue. But I want to stress my main point. This is that the ``author'' holds the copyright. It may be unclear who the author is, but it is clearly NOT the university. In addition, many pieces of ``university-developed'' software have contributions by unfunded students, and by faculty, whose salary is not paid by the gov't (except maybe during the summer). Furthermore, it would seem to be unclear who the author is if it is, say, a student working as a gov't sponsored r. a. For example, the student's thesis is presumably his to copyright, even if the student were paid by the gov't because it was not part of what he was paid to do. One could argue that a concommitant program has the same status unless it were specifically contracted for. Let me state that my main purpose was not to promote people selling their code, but rather, to stop the universities from impeding its distribution. As far as I know, the gov't hasn't tried to prevent us from giving each other our software, but many universities have. Therefore, we are better off leaving them out of the picture entirely - legally this seems to be a sound position.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.25) id AA01447; Fri, 24 Feb 84 17:42:28 pst Received: from ucbdali.ARPA by ucbkim.ARPA (4.16/4.22) id AA16486; Wed, 22 Feb 84 09:58:43 pst Received: by ucbdali.ARPA (4.22/4.22) id AA06784; Wed, 22 Feb 84 09:57:21 pst Date: Wed, 22 Feb 84 09:57:21 pst From: wilensky%ucbdali@Berkeley (Robert Wilensky) Message-Id: <8402221757.AA06784@ucbdali.ARPA> To: andy@aids-unix, franz-friends%ucbdali@Berkeley Subject: Re: Franz Flavors & software copyright In-Reply-To: Your message of 21 Feb 1984 16:29-PST Thanks for your clarification. Everything you said is consistent with my understanding of the situation. And you are correct in emphasizing the complexity of the issue. But I want to stress my main point. This is that the ``author'' holds the copyright. It may be unclear who the author is, but it is clearly NOT the university. In addition, many pieces of ``university-developed'' software have contributions by unfunded students, and by faculty, whose salary is not paid by the gov't (except maybe during the summer). Furthermore, it would seem to be unclear who the author is if it is, say, a student working as a gov't sponsored r. a. For example, the student's thesis is presumably his to copyright, even if the student were paid by the gov't because it was not part of what he was paid to do. One could argue that a concommitant program has the same status unless it were specifically contracted for. Let me state that my main purpose was not to promote people selling their code, but rather, to stop the universities from impeding its distribution. As far as I know, the gov't hasn't tried to prevent us from giving each other our software, but many universities have. Therefore, we are better off leaving them out of the picture entirely - legally this seems to be a sound position.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.25) id AA01363; Fri, 24 Feb 84 17:39:08 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA07966; Tue, 21 Feb 84 16:18:59 pst Received: from RICE (rice.ARPA) by UCB-VAX.ARPA (4.22/4.22) id AA06013; Tue, 21 Feb 84 15:09:46 pst Received: by RICE (AA01303); Tue, 21 Feb 84 17:01:54 cst Date: Tue, 21 Feb 84 16:55:59 CST From: Mike Caplinger Subject: Re: Flavors, Symbolics, and MIT To: bobgian%PSUVAX1.BITNET@Berkeley Cc: franz-friends@Berkeley Message-Id: In-Reply-To: bobgian%PSUVAX1.BITNET's message of Wed, 15 Feb 84 09:50:58 pst If MIT decides to sell Macsyma to Symbolics (which they seem to have), then MIT can do so. When we got a notice from MIT telling us to destroy our Macsyma distribution, that notice WAS from MIT, not Symbolics. Presumably this means that MIT does not choose "to distribute it as public domain (more-or-less) software cheaply to all askers." I have heard a lot of flaming from former MIT people who seem not to believe in the legal and economic realities of software development. I wish I did not have to believe in those realities either. But the fact remains; somebody at MIT is making money selling MIT software to Symbolics and LMI and everyone else who will buy it. If those people don't own the software, then something illegal is happening, and I think everyone would like to know about it.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.25) id AA01135; Fri, 24 Feb 84 17:28:40 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA07939; Tue, 21 Feb 84 16:14:28 pst Received: from RICE (rice.ARPA) by UCB-VAX.ARPA (4.22/4.22) id AA06282; Tue, 21 Feb 84 15:25:53 pst Received: by RICE (AA01391); Tue, 21 Feb 84 17:09:14 cst Date: Tue, 21 Feb 84 17:02:55 CST From: Mike Caplinger Subject: Re: Availability of a VMS version of Franz Lisp To: fkunze%ucbdali@Berkeley (Fritz Kunze) Cc: franz-friends@Berkeley, dbj@rice Message-Id: In-Reply-To: fkunze%ucbdali's message of Sun, 19 Feb 84 14:56:41 pst Just to remind everybody; if you have a VAX and a Unix license, but are constrained for some horrible reason to run VMS, then you will soon be able to get our Unix emulator, Phoenix. This system provides a Unix 4.1 environment exact enough to run Franz almost unmolested. (We still have to use a savelisp/restorelisp scheme to simulate dumplisp; most programs require no changes at all.) If you're interested, send a message to phoenix-request@rice. Of course, this doesn't help you if you don't have and don't want a Unix license.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.25) id AA05063; Sun, 26 Feb 84 14:56:15 pst Received: by ucbkim.ARPA (4.16/4.22) id AA07810; Sun, 26 Feb 84 14:52:15 pst Date: Sun, 26 Feb 84 14:52:15 pst From: mcgeer%ucbkim@Berkeley (Rick McGeer) Message-Id: <8402262252.AA07810@ucbkim.ARPA> To: mike@rice Subject: Re: Flavors, Symbolics, and MIT Cc: franz-friends%ucbkim@Berkeley I have no wish to add fuel to these flames, but I *am* curious. It seems to me that the point of Robert Wilensky's note (and the concurring followups) was that, under law, the software was the property of the authors and/or the funders (in this case ARPA). In either case, MIT has no particular claim. If, as mike@rice claims, MIT's current charges to educational institutions merely reflect "the realities of software development" - meaning presumably restitution for the costs of such development, then it seems to me that the benefits should devolve upon those who bore the cost, namely the people of the United States. I may be missing something, but I am unaware of any costs incurred by MIT in the production of MACSYMA. In any case, I had not heard that MIT was a software house, concerned with software development or the realities thereof. Last time I looked, it was a university, concerned with research and the dissemination of knowledge.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.25) id AA25627; Sat, 25 Feb 84 23:05:34 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA01787; Sat, 25 Feb 84 23:01:43 pst Received: from MIT-MC (mit-mc.ARPA) by UCB-VAX.ARPA (4.22/4.25) id AA25542; Sat, 25 Feb 84 23:01:14 pst Message-Id: <8402260701.AA25542@UCB-VAX.ARPA> Date: Sun 26 Feb 84 01:03-EST From: Barry Shein Subject: Mailing list addition To: franz-friends@Berkeley Could someone add me, barrys%bostonu@csnet-relay, to the list. Thank you.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.25) id AA01447; Fri, 24 Feb 84 17:42:28 pst Received: from ucbdali.ARPA by ucbkim.ARPA (4.16/4.22) id AA16486; Wed, 22 Feb 84 09:58:43 pst Received: by ucbdali.ARPA (4.22/4.22) id AA06784; Wed, 22 Feb 84 09:57:21 pst Date: Wed, 22 Feb 84 09:57:21 pst From: wilensky%ucbdali@Berkeley (Robert Wilensky) Message-Id: <8402221757.AA06784@ucbdali.ARPA> To: andy@aids-unix, franz-friends%ucbdali@Berkeley Subject: Re: Franz Flavors & software copyright In-Reply-To: Your message of 21 Feb 1984 16:29-PST Thanks for your clarification. Everything you said is consistent with my understanding of the situation. And you are correct in emphasizing the complexity of the issue. But I want to stress my main point. This is that the ``author'' holds the copyright. It may be unclear who the author is, but it is clearly NOT the university. In addition, many pieces of ``university-developed'' software have contributions by unfunded students, and by faculty, whose salary is not paid by the gov't (except maybe during the summer). Furthermore, it would seem to be unclear who the author is if it is, say, a student working as a gov't sponsored r. a. For example, the student's thesis is presumably his to copyright, even if the student were paid by the gov't because it was not part of what he was paid to do. One could argue that a concommitant program has the same status unless it were specifically contracted for. Let me state that my main purpose was not to promote people selling their code, but rather, to stop the universities from impeding its distribution. As far as I know, the gov't hasn't tried to prevent us from giving each other our software, but many universities have. Therefore, we are better off leaving them out of the picture entirely - legally this seems to be a sound position.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.25) id AA01363; Fri, 24 Feb 84 17:39:08 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA07966; Tue, 21 Feb 84 16:18:59 pst Received: from RICE (rice.ARPA) by UCB-VAX.ARPA (4.22/4.22) id AA06013; Tue, 21 Feb 84 15:09:46 pst Received: by RICE (AA01303); Tue, 21 Feb 84 17:01:54 cst Date: Tue, 21 Feb 84 16:55:59 CST From: Mike Caplinger Subject: Re: Flavors, Symbolics, and MIT To: bobgian%PSUVAX1.BITNET@Berkeley Cc: franz-friends@Berkeley Message-Id: In-Reply-To: bobgian%PSUVAX1.BITNET's message of Wed, 15 Feb 84 09:50:58 pst If MIT decides to sell Macsyma to Symbolics (which they seem to have), then MIT can do so. When we got a notice from MIT telling us to destroy our Macsyma distribution, that notice WAS from MIT, not Symbolics. Presumably this means that MIT does not choose "to distribute it as public domain (more-or-less) software cheaply to all askers." I have heard a lot of flaming from former MIT people who seem not to believe in the legal and economic realities of software development. I wish I did not have to believe in those realities either. But the fact remains; somebody at MIT is making money selling MIT software to Symbolics and LMI and everyone else who will buy it. If those people don't own the software, then something illegal is happening, and I think everyone would like to know about it.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.25) id AA01135; Fri, 24 Feb 84 17:28:40 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA07939; Tue, 21 Feb 84 16:14:28 pst Received: from RICE (rice.ARPA) by UCB-VAX.ARPA (4.22/4.22) id AA06282; Tue, 21 Feb 84 15:25:53 pst Received: by RICE (AA01391); Tue, 21 Feb 84 17:09:14 cst Date: Tue, 21 Feb 84 17:02:55 CST From: Mike Caplinger Subject: Re: Availability of a VMS version of Franz Lisp To: fkunze%ucbdali@Berkeley (Fritz Kunze) Cc: franz-friends@Berkeley, dbj@rice Message-Id: In-Reply-To: fkunze%ucbdali's message of Sun, 19 Feb 84 14:56:41 pst Just to remind everybody; if you have a VAX and a Unix license, but are constrained for some horrible reason to run VMS, then you will soon be able to get our Unix emulator, Phoenix. This system provides a Unix 4.1 environment exact enough to run Franz almost unmolested. (We still have to use a savelisp/restorelisp scheme to simulate dumplisp; most programs require no changes at all.) If you're interested, send a message to phoenix-request@rice. Of course, this doesn't help you if you don't have and don't want a Unix license.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.25) id AA10968; Fri, 24 Feb 84 02:31:05 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA09319; Fri, 24 Feb 84 02:26:50 pst Received: from MIT-MC (mit-mc.ARPA) by UCB-VAX.ARPA (4.22/4.25) id AA10856; Fri, 24 Feb 84 02:26:11 pst Message-Id: <8402241026.AA10856@UCB-VAX.ARPA> Received: from DUPAGE by SCRC-QUABBIN with CHAOS; Wed 22-Feb-84 08:17:52-EST Date: Wed, 22 Feb 84 08:14 EST From: Richard Pavelle Subject: Flavors, Symbolics, and MIT To: bobgian%PSUVAX1.BITNET@Berkeley Cc: rp%SCRC-TENEX@MIT-MC.ARPA, rn%SCRC-TENEX@MIT-MC.ARPA, fateman%ucbdali@Berkeley, franz-friends@Berkeley, psuvax1.ucsfcgl!bash@bitnet, wilensky%ucbdali@Berkeley, stull%SCRC-TENEX@MIT-MC.ARPA Date: Wed, 15 Feb 84 09:50:58 pst Message-Id: <8402151751.AA13818@ucbjade.CC.Berkeley.ARPA> From: bobgian%PSUVAX1.BITNET@Berkeley To: ucsfcgl!bash@Berkeley, franz-friends@Berkeley Subject: Flavors, Symbolics, and MIT Not wishing to subject myself to a lawsuit, but here I go anyway ... Symbolics can scream all it wants about lawyers and proprietary rights, but anything developed for the Lisp Machine by MIT labor is property of MIT, which chooses to distribute it as public domain (more-or-less) software cheaply to all askers. An example is MACSYMA, developed by MIT and then "pirated" for commercial sale by Symbolics. Maybe Symbolics has enhanced MACSYMA, but they sure as h*ll don't OWN MACSYMA. This statement not true. Arthur D. Little Inc (licensing agent for MACSYMA) and MIT approached Symbolics with the proposal of marketing and enhancing MACSYMA and Symbolics accepted. Symbolics does not claim ownership of MACSYMA and never has. I don't know the detailed contractual arrangements between Rich Zippel, MIT, Symbolics, and Flavors, but before giving up I would call MIT's lawyers, not Symbolics' lawyers. RMS (Rich Stallman), where are you when we need you?? :-) - Bob (who was at MIT during the birth of both the LispMs and Symbolics) --- Bob Giansiracusa (Dept of Computer Science, Penn State Univ, 814-865-9507) Arpa: bobgian%PSUVAX1.BITNET@Berkeley Bitnet: bobgian@PSUVAX1.BITNET CSnet: bobgian@penn-state.CSNET UUCP: bobgian@psuvax.UUCP -or- allegra!psuvax!bobgian USnail: 333 Whitmore Lab, Penn State Univ, University Park, PA 16802 --------------------  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.25) id AA19293; Fri, 24 Feb 84 08:45:28 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA11239; Fri, 24 Feb 84 08:43:04 pst Received: from CMU-CS-A (cmu-cs-a.ARPA) by UCB-VAX.ARPA (4.22/4.25) id AA19255; Fri, 24 Feb 84 08:42:36 pst Date: 24 Feb 84 1103 EST (Friday) From: Lars.Ericson@CMU-CS-A To: Richard Pavelle Subject: Re: Flavors, Symbolics, and MIT Cc: Dave.Touretzky@CMU-CS-A, Jeff.Shrager@CMU-CS-A, franz-friends@Berkeley In-Reply-To: <8402241026.AA10856@UCB-VAX.ARPA> Message-Id: <24Feb84.110319.LE60@CMU-CS-A> Macsyma was funded by public money throughout its entire development. Macsyma services were provided free to all takers, as long as MIT was getting money from Uncle Sam to do so, and as long as a PDP-10 running ITS was the only machine which could provide such service. During this period of time, anybody could FTP Macsyma to their site, and no one was hassled for doing so (why bother? it wouldn't run...). With the advent of a DECSYSTEM-20 implementation, and Fateman's VAX/Franz version, and with the consequent decline in the rationale of funding the MC machine as the sole provider of Macsyma services, MIT decided unilaterally and post-facto to license Macsyma. There are two schools of thought on this issue. One is that the Government should encourage such licensing and enterprenuerial development, because it ultimately results in the spread of the product to a larger industrial community than is usually the case with an academically-maintained product. The other school says that what is paid for by the people should be the property of the people, and not the property of MIT, Symbolics, or Arthur D. Little, Inc. (inventor, by the way, of Cap'N Crunch and artificial bannana flavoring). It is clear that the licensing act was for commercial advantage, and not to maintain control over the sources for, say, further academic refinement, because it seems fairly clear that the original impetus of the Macsyma development qua Macsyma is over with. There is a positive side to all this, which is that it may cause people to look more seriously at things other-than-MIT, such as REDUCE, SMP, whatever Fateman will cook up, and, yes Virginia, even Franz LISP. The controversy and sharply reduced academic availability ($500/CPU is simply an obnoxious hassle for people who would like to try something out occasionally, but do not have a continuous need for something), combined with the increased availability at low cost of machines equal in power to a PDP-10 running ITS, will stimulate further research outside of MIT. Furthermore, it will now become routine for people doing research who would like their results to be available to the public at no cost, to carefully stipulate in their grant and contract proposals that that be the ultimate disposition of the research product. -- Lars Ericson  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.25) id AA08419; Fri, 24 Feb 84 00:03:23 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA08632; Thu, 23 Feb 84 23:58:22 pst Received: by UCB-VAX.ARPA (4.22/4.25) id AA08331; Thu, 23 Feb 84 23:58:00 pst Received: by decvax.UUCP (4.12/4.13) id AA06226; Fri, 24 Feb 84 02:35:47 est Received: by dartvax.UUCP (4.12/4.7) id AA18853; Fri, 24 Feb 84 01:34:36 est Received: by dalcs.UUCP (4.12/4.7) id AA00642; Fri, 24 Feb 84 00:44:50 ast From: decvax!dartvax!dalcs!y5120@Berkeley (Neil S. Erskine) Date: 24 Feb 1984 0044-AST (Friday) Message-Id: <496.205.446445879@dalcs> To: dartvax!decvax!ucbvax!franz-friends@Berkeley Cc: franz@Berkeley Subject: Has any one the missing function from pp.l (franz opus 38.79) I posted this request to the net on net.lang.lisp some time ago, but got no response. I hope that this will generate the required results. -------- Does anyone out there have the function , which is called by in franz opus 38.79 (came with 4.2 BSD)? The absence of this is not normally a problem, since who comments their code? Me. I have been using the CMU file package, and find it extremely convenient, except that use of the function causes it to fail due to the absence of the function from pp.l . If no-one has the actual pp-comment function, does anyone have a description of the exact format in which expects to see comments? Thank you. Neil S. Erskine ...decvax!dartvax!dalcs!z005  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.22) id AA21300; Thu, 23 Feb 84 08:28:27 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA27734; Thu, 23 Feb 84 08:26:28 pst Received: from MIT-MC (mit-mc.ARPA) by UCB-VAX.ARPA (4.22/4.22) id AA21257; Thu, 23 Feb 84 08:26:15 pst Message-Id: <8402231626.AA21257@UCB-VAX.ARPA> Date: Mon 20 Feb 84 21:10:03-EST From: RMS%MIT-OZ@MIT-MC.ARPA To: franz-friends@Berkeley The moral is, "The only good Symbolics is a dead Symbolics." If someone else wants to hack up winning flavors for Franz, I'm willing to offer some help. -------  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.22) id AA13880; Tue, 21 Feb 84 22:02:26 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA11731; Tue, 21 Feb 84 21:55:21 pst Received: from aids-unix (aids-unix.ARPA) by UCB-VAX.ARPA (4.22/4.22) id AA08425; Tue, 21 Feb 84 17:22:53 pst Message-Id: <8402220122.AA08425@UCB-VAX.ARPA> Date: 21 Feb 1984 16:29-PST From: Andy Cromarty Subject: Franz Flavors & software copyright To: franz-friends@Berkeley [Usual disclaimer: I am not a lawyer and this is not legal counsel. I have simply bothered to read a lot of the law, including the case law, regarding copyright in general and software copyright in particular.] Bob Wilensky's note is not too far off the mark, but there are some important complications and exceptions programmers should aware of befored they assume that whatever they write is theirs. In particular, the statement that "Software is governed by copyright law, which means that it is owned by the AUTHOR, period" is technically correct but misleading, since the legal interpretation of "author" is unintuitive: if you do programming for a company for a living, for example, and you write a program as a part of your normal duties in fulfilling that job's requirements, then according to the law the *company* is the "author" of that program, not you. The rationale for this appears in Wilensky's note, in fact: it is considered that you contracted away your right of copy over the works you produce when you took that job. It is true that all recent attempts on the part of universities to claim copyright over, for example, professors' lectures, have failed. If you are employed by your university to write programs, however, things are not so convenient. Further, while the law specifically states that works written by U.S. government-funded employees are in the public domain and thus not copyrightable, Federal funding is common for universities, which makes things interestingly fuzzy. I know of no case law deciding the issue of copyright ownership for, say, NSF-funded works. Universities having been ignoring this as much as possible for the last several years, and to my knowledge they have been entirely successful (that is, there have been no court challenges of the obvious sort). I expect this sort of case to appear in the courts within the next couple of years. (Incidentally, a couple times a year I hear some cretin claim that "public domain is an obsolete idea". Don't you bet on it. It's right there in the latest copyright law.) There are numerous further complexities and subtleties that should be understood by anyone who intends to copyright their work. (Things that deserve more detailed treatment include "works made for hire", implied vs. express contractual arrangements when you are "commissioned" for a work, "derivative works", and "utilitarian works", which may turn out to be an especially interesting area of case law regarding software over the next couple years.) If you want more information and can't afford a lawyer, I would recommend that you at least read one of the copyright books now available. NOTE: It should be post-1978, since the "1976" copyright law changed a lot of important things, especially concerning computer software. asc p.s. I copyright everything I write that isn't written directly for my employer in the normal course of my duties at work. You can always change your mind later. All you have to do to copyright a program is put the line at the top: Copyright (C) 1984 You CAN, but NEED NOT, register it with the government; it is covered by the law the moment you write the above line into it.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.22) id AA04411; Tue, 21 Feb 84 13:39:05 pst Received: from ucbdali.ARPA by ucbkim.ARPA (4.16/4.22) id AA05442; Tue, 21 Feb 84 13:31:50 pst Received: by ucbdali.ARPA (4.22/4.22) id AA00440; Tue, 21 Feb 84 13:30:24 pst Date: Tue, 21 Feb 84 13:30:24 pst From: wilensky%ucbdali@Berkeley (Robert Wilensky) Message-Id: <8402212130.AA00440@ucbdali.ARPA> To: fateman%ucbdali@Berkeley, bobgian%PSUVAX1.BITNET@Berkeley, franz-friends%ucbdali@Berkeley Subject: Re: Flavors, Symbolics, and MIT In-Reply-To: Your message of Tue, 21 Feb 84 07:51:56 pst I have been informed by well-known computer scientist who has had some legal dealings that the following is true of the legal status of software (I have no legal expertise myself, nor does my informant for that matter; I would not advise anyone to go to court based on the following, although it personally makes sense to me): Software is governed by copyright law, which means that it is owned by the AUTHOR, period (This precedent is almost universally recognized internationally, with the possible exception of Australia and a few other countries. The Japanese are considering legislation that would result in not recognizing such protection - American trade negotiators consider this scandalous. Tell that to your university lawyer who thinks he can make up his own rules on the matter). Of course, it is possible for an author to sign away rights to copyrightable material on a contractual basis. For example, you can contract with a publisher to reproduce and sell your book. In addition, you can make an explicit contract with an organization to give them rights to something you are going to produce. For example, it is possible that both the federal government and a university may require researchers to sign an agreement explicitly giving them rights to all products of that research (such an agreement might have been in the small print of the contract that the principal investigator signed for the university to process the contract, or in the work agreement between a student r.a. and the university, etc.). However, it is NOT the case that a university (or anyone else) can make you sign away copyrights in a blanket manner (i. e., such agreements are illegal and non-binding). In particular, the University definitely CANNOT rightfully claim ownership to a piece of software by virtue of the fact that you produced it using their facilities. They might just as well claim that they are entitled to the royalties from your books, which were written in their offices and using their typewriters, etc. (Needless to say, they are very clearly not entitled to such royalties). Universities do indeed make such (legally absurd) claims to software. They talk about ``university policy'' on these matters. Fortunately, universities are not free to make ``policy'' on murder, rape, property or taxation, or other matters governed by our criminal and civil legal system. Anyone who has let a university ``share'' the product of his or her mind has therefore given away property that is rightfully theirs, whether they did so voluntarily, or under duress. A corrollary to all this is that you should stick your own name and copyright on the software you write. If a university complains, you are free to suggest that they stick their head where the sun don't shine. Of course, they may harass you, for example, by suing you, in spite of the ridiculousness of their complaint. As for MACSYMA, if the various researchers and employees who worked on MACSYMA signed explicit agreements giving away their copyrights of products they were going to produce on a particular contract, then the product may indeed belong to someone other than them. If not, then it's theirs.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.22) id AA13287; Tue, 21 Feb 84 07:59:04 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA01635; Tue, 21 Feb 84 07:54:29 pst Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.22/4.22) id AA13202; Tue, 21 Feb 84 07:51:49 pst Received: by ucbdali.ARPA (4.22/4.22) id AA27588; Tue, 21 Feb 84 07:51:56 pst Date: Tue, 21 Feb 84 07:51:56 pst From: fateman%ucbdali@Berkeley (Richard Fateman) Message-Id: <8402211551.AA27588@ucbdali.ARPA> To: franz-friends@Berkeley, bobgian%PSUVAX1.BITNET@Berkeley, psuvax1.ucsfcgl!bash@bitnet Subject: Re: Flavors, Symbolics, and MIT I believe Bob Giansiracusa is mistaken about the ownership of software developed (under gov't contract) by MIT employees. The possibilities are approximately: 1. the authors own it and/or 2. mit and the gov't jointly own it 3. the gov't owns it 4. mit owns it 5. the software is owned, but distributed at low cost 6. the software is owned, but distributed at high cost 7. the software is "public domain". Inquiries to MIT concerning Macsyma, at least, reveal that their patent office thinks 4 and 6, with perhaps 2. There have been some changes to Macsyma by Symbolics.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.22) id AA06488; Tue, 21 Feb 84 00:59:12 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA02595; Fri, 17 Feb 84 16:19:40 pst Received: from ucbarpa.ARPA by UCB-VAX.ARPA (4.22/4.22) id AA04144; Wed, 15 Feb 84 15:56:32 pst Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by ucbarpa.ARPA (4.22/4.22) id AA00311; Wed, 15 Feb 84 14:45:56 pst Received: from PSUVAX1.BITNET by ucbjade.CC.Berkeley.ARPA (4.14/4.13.1) id AA13818; Wed, 15 Feb 84 09:51:02 pst Date: Wed, 15 Feb 84 09:50:58 pst Message-Id: <8402151751.AA13818@ucbjade.CC.Berkeley.ARPA> From: bobgian%PSUVAX1.BITNET@Berkeley To: ucsfcgl!bash@Berkeley, franz-friends@Berkeley Subject: Flavors, Symbolics, and MIT Not wishing to subject myself to a lawsuit, but here I go anyway ... Symbolics can scream all it wants about lawyers and proprietary rights, but anything developed for the Lisp Machine by MIT labor is property of MIT, which chooses to distribute it as public domain (more-or-less) software cheaply to all askers. An example is MACSYMA, developed by MIT and then "pirated" for commercial sale by Symbolics. Maybe Symbolics has enhanced MACSYMA, but they sure as h*ll don't OWN MACSYMA. I don't know the detailed contractual arrangements between Rich Zippel, MIT, Symbolics, and Flavors, but before giving up I would call MIT's lawyers, not Symbolics' lawyers. RMS (Rich Stallman), where are you when we need you?? :-) - Bob (who was at MIT during the birth of both the LispMs and Symbolics) --- Bob Giansiracusa (Dept of Computer Science, Penn State Univ, 814-865-9507) Arpa: bobgian%PSUVAX1.BITNET@Berkeley Bitnet: bobgian@PSUVAX1.BITNET CSnet: bobgian@penn-state.CSNET UUCP: bobgian@psuvax.UUCP -or- allegra!psuvax!bobgian USnail: 333 Whitmore Lab, Penn State Univ, University Park, PA 16802  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.22) id AA02706; Fri, 17 Feb 84 17:04:34 pst Received: from ucbdali.ARPA by ucbkim.ARPA (4.16/4.22) id AA00419; Fri, 17 Feb 84 10:29:53 pst Received: by ucbdali.ARPA (4.22/4.22) id AA27291; Fri, 17 Feb 84 09:19:06 pst Date: Fri, 17 Feb 84 09:19:06 pst From: fkunze%ucbdali@Berkeley (Fritz Kunze) Message-Id: <8402171719.AA27291@ucbdali.ARPA> To: franz-friends%ucbdali@Berkeley Subject: VMS version of Franz Lisp A number of people have inquired about the availability of Franz Lisp under VMS. Robert Lynch, a DEC representative, has asked that inquiries be directed to him. DEC is trying to gauge customer interest in Franz Lisp; and will support a Franz Lisp port to VMS only if there is sufficient interest. You may reach him at: DEC Attn: Robert Lynch Contential Blvd mail stop mk02-1/h10 Meramac NH 0354 603 884 2932 ---Fritz Kunze  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.22) id AA06316; Tue, 21 Feb 84 00:47:15 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA24051; Sun, 19 Feb 84 14:57:02 pst Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.22/4.22) id AA02063; Sun, 19 Feb 84 14:56:46 pst Received: by ucbdali.ARPA (4.22/4.22) id AA14687; Sun, 19 Feb 84 14:56:41 pst Date: Sun, 19 Feb 84 14:56:41 pst From: fkunze%ucbdali@Berkeley (Fritz Kunze) Message-Id: <8402192256.AA14687@ucbdali.ARPA> To: franz-friends@Berkeley -------- From TIKIT@USC-ECLB.ARPA Sun Feb 19 14:12:09 1984 Date: 19 Feb 1984 1323-PST From: TIKIT Subject: Wanted: VMS 3.4 FranzLisp I am interested in obtaining information about FranzLisp running under VAX/VMS Version 3.4. Do you know who I can order it from, or how much it might cost? Thanks, Tom Piotrowski Artificial Intelligence Lab Tech Support TIKIT @ USC-ECLB ------- To: franz-friends Subject: Availability of a VMS version of Franz Lisp A number of people have inquired about the availability of Franz Lisp under VMS. Robert Lynch, a DEC representative, has asked that such inquiries be directed to him. DEC is trying to gauge customer interest in Franz Lisp; and will support a Franz Lisp port to VMS (by the authors of Franz Lisp) only if there is sufficient interest. You may reach him at: DEC Attn: Robert Lynch Contential Blvd mail stop mk02-1/h10 Meramac NH 0354 603 884 2932 ---Fritz Kunze 32 ---Fritz Kunze  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.22) id AA02706; Fri, 17 Feb 84 17:04:34 pst Received: from ucbdali.ARPA by ucbkim.ARPA (4.16/4.22) id AA00419; Fri, 17 Feb 84 10:29:53 pst Received: by ucbdali.ARPA (4.22/4.22) id AA27291; Fri, 17 Feb 84 09:19:06 pst Date: Fri, 17 Feb 84 09:19:06 pst From: fkunze%ucbdali@Berkeley (Fritz Kunze) Message-Id: <8402171719.AA27291@ucbdali.ARPA> To: franz-friends%ucbdali@Berkeley Subject: VMS version of Franz Lisp A number of people have inquired about the availability of Franz Lisp under VMS. Robert Lynch, a DEC representative, has asked that inquiries be directed to him. DEC is trying to gauge customer interest in Franz Lisp; and will support a Franz Lisp port to VMS only if there is sufficient interest. You may reach him at: DEC Attn: Robert Lynch Contential Blvd mail stop mk02-1/h10 Meramac NH 0354 603 884 2932 ---Fritz Kunze  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.22) id AA04405; Sun, 19 Feb 84 17:07:28 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA25218; Sun, 19 Feb 84 17:02:46 pst Received: from MIT-MC (mit-mc.ARPA) by UCB-VAX.ARPA (4.22/4.22) id AA04270; Sun, 19 Feb 84 17:01:55 pst Message-Id: <8402200101.AA04270@UCB-VAX.ARPA> Date: 15 February 1984 19:45 EST From: Richard E. Zippel Subject: flavors like a 3600 To: jkf%ucbmike@Berkeley Cc: franz-friends@Berkeley, ucsfcgl!bash@Berkeley In-Reply-To: Msg of Wed 15 Feb 84 08:47:28 pst from John Foderaro (on an h19-u) Date: Wed, 15 Feb 84 08:47:28 pst From: John Foderaro (on an h19-u) To: franz-friends at Berkeley, ucsfcgl!bash at Berkeley Re: flavors like a 3600 Richard Zippel, an MIT prof working for Symbolics at the time rewrote flavors.l from scratch using fclosures and passed it on to us. Just to clarify this a bit, I didn't rewrite it from scratch, I took the Lisp machine's flavor code and forced it to run within Franz. This was not trivial and in doing it I lobotomized the code slightly by making it use fclosures. (Flavors used to use closures but this replaced by mapping table magic after a while to speed things up. I just took a step backwards.) To use my flavor code in a performance critical situation, I would put the mapping table stuff back in, but that would take a few weeks of work, it is quite hairy.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.22) id AA00777; Sun, 19 Feb 84 13:34:46 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA23103; Sun, 19 Feb 84 13:28:30 pst Received: from USC-ECLB.ARPA by UCB-VAX.ARPA (4.22/4.22) id AA00600; Sun, 19 Feb 84 13:28:06 pst Message-Id: <8402192128.AA00600@UCB-VAX.ARPA> Date: 19 Feb 1984 1323-PST From: TIKIT Subject: Wanted: VMS 3.4 FranzLisp To: franz-friends@Berkeley I am interested in obtaining information about FranzLisp running under VAX/VMS Version 3.4. Do you know who I can order it from, or how much it might cost? Thanks, Tom Piotrowski Artificial Intelligence Lab Tech Support TIKIT @ USC-ECLB -------  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.22) id AA08510; Wed, 15 Feb 84 08:53:12 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA03141; Wed, 15 Feb 84 08:45:49 pst Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.22/4.22) id AA08393; Wed, 15 Feb 84 08:45:14 pst Date: Wed, 15 Feb 84 08:47:28 pst From: John Foderaro (on an h19-u) Message-Id: <8402151647.453@ucbmike.ARPA> Received: by ucbmike.ARPA (4.17/3.5) id AA00453; Wed, 15 Feb 84 08:47:28 pst To: franz-friends@Berkeley, ucsfcgl!bash@Berkeley Subject: flavors like a 3600 In-Reply-To: Your message of 14 Feb 1984 1504-PST (Tuesday) The flavors story: There are two versions of Flavors that work on Franz. One you can get, one you can't. The one you can get comes from Liz Allen at the University of Maryland (liz.umcp-cs@csnet-relay). It is well documented but its syntax is not exactly like you would find on a 3600. The alternative is one written by someone with access to a 3600, and which is thus pretty close to what you would find on a 3600 (as far as the syntax goes). It has a very long and unfinished story: The 4.1bsd version of flavors.l was written by a student at MIT. It did a less than adequate implementation of flavors because franz didn't have a 'closure' feature. We added 'fclosure's to franz, which are as close to closures as we could get. Richard Zippel, an MIT prof working for Symbolics at the time rewrote flavors.l from scratch using fclosures and passed it on to us. We replaced our old flavors.l with Zippel's. We then learned that we couldn't distribute flavors.l for a short while until a deal was worked with Symbolics' lawyers. Years have passed and Symbolics has yet to permit us to distribute flavors.l . Sorry, there is no happy ending to the story. There is a moral: "If you do something of value, don't ever ever let the lawyers find out about it". john foderaro  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.22) id AA08730; Thu, 16 Feb 84 19:28:25 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA02533; Thu, 16 Feb 84 19:17:49 pst Received: from csnet-cic.ARPA by UCB-VAX.ARPA (4.22/4.22) id AA07675; Thu, 16 Feb 84 18:28:19 pst Message-Id: <8402170228.AA07675@UCB-VAX.ARPA> Date: 16 Feb 84 17:04:49 EST (Thu) From: Liz Allen Return-Path: Subject: Re: Flavors To: (Paul Bash) ucsfcgl!bash@Berkeley, franz-friends@Berkeley Via: UMCP-CS; 16 Feb 84 20:02-EST The Maryland flavors package currently runs under 4.1 bsd. We have not yet gotten 4.2 bsd; when we do, we will bring it up under 4.2. I don't know how long it will be before we get 4.2; nor do I know how long it will take to bring up our lisp packages under 4.2. I will make an announcement when we have it up. The packages under 4.1 are currently available for a $100 tape fee. If you're interested, let me know. -Liz -- Univ of Maryland, College Park MD Usenet: ...!seismo!umcp-cs!liz Arpanet: liz%umcp-cs@CSNet-Relay  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.22) id AA18335; Tue, 14 Feb 84 10:20:45 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA06984; Tue, 14 Feb 84 10:14:13 pst Received: by UCB-VAX.ARPA (4.22/4.22) id AA18230; Tue, 14 Feb 84 10:14:52 pst Received: by ucsfcgl.UCSF (4.12/4.3) id AA12323; Tue, 14 Feb 84 08:47:30 pst Date: Tue, 14 Feb 84 08:47:30 pst From: ucsfcgl!bash@Berkeley (Paul Bash) Message-Id: <8402141647.AA12323@ucsfcgl.UCSF> To: franz-friends@Berkeley Subject: Flavors Is there a flavors package that runs in franz with Unix 4.2BSD and is also compatible with flavors running on the Symbolics 3600 lisp machine? The last time I checked, the MIT flavors that worked under 4.1BSD wasn't working under 4.2BSD. Has there been any change?? Paul Bash  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.22) id AA08189; Fri, 10 Feb 84 18:06:31 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA23093; Fri, 10 Feb 84 17:58:56 pst Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.22/4.22) id AA08059; Fri, 10 Feb 84 17:59:09 pst Received: by ucbdali.ARPA (4.22/4.22) id AA17751; Fri, 10 Feb 84 17:58:31 pst Date: Fri, 10 Feb 84 17:58:31 pst From: fateman%ucbdali@Berkeley (Richard Fateman) Message-Id: <8402110158.AA17751@ucbdali.ARPA> To: franz-friends@Berkeley Subject: how fast is T? Jonathan Rees has challenged me to find the factor-of-40 in print, or in electrons, and I have failed to find it. I apologize to both Jonathan, and anyone else who felt I had accused him/her of outrageous claims. I believe that Jonathan and I agree that there was, in an initial draft of one paper, an unsupported claim of "favorable" speed comparison, but which (so far as I can tell) was removed by the authors. (before publication).  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.22) id AA19904; Fri, 10 Feb 84 05:32:58 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA13987; Fri, 10 Feb 84 05:27:30 pst Received: from PARC-MAXC.ARPA by UCB-VAX.ARPA (4.22/4.22) id AA18991; Fri, 10 Feb 84 04:46:27 pst Message-Id: <8402101246.AA18991@UCB-VAX.ARPA> Date: 10 Feb 84 04:44 PST From: JonL.pa@PARC-MAXC.ARPA Subject: More on "Correct" Lisp Interpreters To: Robert.Cartwright@cmu-cs-cad.ARPA Cc: Franz-Friends@Berkeley, Guy.Steele@CMUA.ARPA, JonL.pa@PARC-MAXC.ARPA In-Reply-To: your message of 9 Feb 84 15:41:26 EST Hmmm, yes, it looks like we're talking about slightly different things here. I take back my charge of "misconception", in favor of "not-yet-reached-mutual-understanding-of-problem". Let me try to clarify. "Constant time" in my paper refers to the access time for a variable during the interpretation phase; as such, the time is constant regardless of the number of variables present, and regardless of the declarations present. As I mention in the paper, the "usual" approach involves some kind of alist like mechanism and this would entail an access time linear in the number of variables in the function being interpreted [Lisp/370's interpreter, while keeping the variables only in the stack frame, still had to search the frames one slot at a time; the "consy" model of course searches the true alist one entry at a time] I'm not sure where Baker's "Shallow Binding" paper finally got published, but I have a preliminary version dated January, 1977, numbered "AI Working Paper 138" from the MIT AI Lab. This re-rooting scheme is a generalization of what happens on the Lisp Machine when a context switch occurs -- the currently running stack group has to be "unwound" upwards, and the new one has to be "unwound" downwards [because of the potentially unbounded time cost for these "unwindings", Interlisp-D adopted the deep bound model]. **** But Baker's "re-rooting" scheme would be "constant time" in exactly the same sense as I used the term in my 1982 Lisp Conference paper. **** On the other hand, I don't think it will be as easy as you suggest to fix his scheme to do mixed local and special declarations right. The major problem for these "value cell" schemes is not how to "shield" one lexical environment from another, but how to decide whether a particular occurence of a variable to be interpreted should be treated as a "local" variable, or as a "special" variable. That's the reason for the DLINTZ table mentioned in the "Constant time" paper. I don't know what transpired verbally between you and Guy (Steele) about interpreter timings, so I'm not sure just exactly what his comment applies to. But let me assume that he was comparing a Lisp interpreter design that does lexical binding "right" with one that doesn't attempt to do it at all. Then I'd have to concur that the latter would be faster. [It would also be "wrong" in the sense that got this discussion started in the first place.] What I meant to convey by my former note was that an interpreter design and implementation exists (the "Constant time" paper) which 1) does both lexical and dynamic bindings correctly 2) costs no more for lexical variables than for dynamic ones 3) is "constant time" for variable access. As you might imagine, I would loathe a sloution that changed the names of my program variables. Even more so than the bugs in the existing interpreters, which ignore declarations, and have no provisions for lexical variables. But I think we have two main points of mutual understanding here: one, that a "correct" Lisp-semantics interpreter will be slower than the existing "wrong" ones, and two, that *** given that one will do a "correct" interpreter, then a constant-access-time one exists in which there is no time penalty for using lexical variables as opposed to dynamic variables ***. What we really don't know is just how much slower a "correct" interpreter will be, nor how much of the slowdown is attributable to retention of Lisp semantics (rather than adopting Scheme semantics). The comparison here is not "Scheme against Lisp", but "Correct against wrong". ------------------------------------------------------------------------------- Additional comments: (yea, this note is getting long!) How Slow? Suppose the "Constant time" interpreter runs more slowly than the "wrong" one mentioned above (and I'm sure it does!). It would be very difficult to assess, without some serious experimentation and research, just how much of the time slowdown is due to the extra instructions required at access time (remember: the "constant" in the paper isn't 1, whereas for a "wrong" implementation like Interlisp-10, which is shallow-bound, it really could be 1 instruction), how much is due to the maintenance of the BLINTZ and DLINTZ tables, and how much is due to the generous provisions which make debugging easier. The question we need to address is: assuming we like Lisp semantics, how much slowdown are we willing to pay to fix the abominable situation that now exists? Let me toss out the number 50%. Experience has shown that pdp10 MacLisp users were willing to pay a slowdown cost of 200% to 300% for the debugging facilities provided by *RSET mode. That surprised me. I used to keep *RSET mode off, in order to keep up the speed, but finally decided that that was a counter productive mode. Ultimately I decided that 5 minutes of my debugging time was more valuable that millions of pdp 10 instructions. Especially when one works at night a lot, and literally trillions of machine cycles are going to waste! What about FUNARGS? The "Constant time" paper only addresses the linear stack model; Baker addresses the full tree-environment model. Multiple stack groups such as the Lisp Machine has permit multiprocessing, but are still only a multiple set of linear stacks. Consequently, I suspect Baker's scheme does FUNARGs right, whereas the Lisp Machine, and the scheme in "Constant time", only permit what I'd call "limited" FUNARGS -- the closures only "close" over explicitly named variables (the "Constant time" paper, however, permits the implicit capture into funargs of all the lexically-apparent variables too). But, the application of a "limited" FUNARG only costs a time linear in the number of variables captured by the "limited closure", whereas the application of a true FUNARG as in Baker's scheme is essentialy equivalent to a context switch, and thus would be unbounded time. Finally, I'm enjoying this interchange with you, and hope the other members of Franz-Friends aren't unduly upset at being cc'd with all these deep technical discussions. Cheers, JonL  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.22) id AA00828; Thu, 9 Feb 84 10:55:04 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA10594; Thu, 9 Feb 84 08:06:45 pst Received: from PARC-MAXC.ARPA by UCB-VAX.ARPA (4.22/4.22) id AA07477; Thu, 9 Feb 84 07:17:25 pst Message-Id: <8402091517.AA07477@UCB-VAX.ARPA> Date: 9 Feb 84 05:38 PST From: JonL.pa@PARC-MAXC.ARPA Subject: "Correct" Lisp Interpreters To: mike@Rice.ARPA Cc: Robert.Cartwright@cmu-cs-cad.ARPA, Franz-Friends@Berkeley In-Reply-To: Your message of 8 Feb 84 10:03:08 CST (and also Corky's note of 8 Feb 84 13:29:12 EST) After reading your note, it doesn't appear that we disagree at all; I'll take the "tone" of your first sentence to be merely "first impluse". But you ask a very good question -- why is it so hard to write a correct interpreter for Lisps? ("correct" means one that obeys local declarations, and implements local, or "lexical", variables correctly, whether explicitly or implicitly declared so) The first answer is that most Lisps were "bootstrapped" from some machine-language program that implemented the interpreter, and writing a "correct" interpreter is hard to do in anything other than Lisp (notice how many Lisp compilers you find written in anything other than Lisp!) The second answer is that after the bug is noted, there are two easy "cop outs": (1) In the MacLisp world, we just spread the word that the interpreter had a bug and we darnd well weren't going to fix it! [I was partially responsible for this state of affairs during the early 70's at MIT, but was also buoyed along by the general ambiance of arrogance for which the MIT AI Lab was so justly infamous]. (2) In the InterLisp world, following standard practice there, whenever a bug was discovered that was too troublesome to fix, it was merely declared a "feature", and documented as such! That explains why MacLisp defaults to lexical variables, and Interlisp defaults to dynamic variables. Often, one's first thought about doing a "correct" interpreter is simply to resort to alists for the lexical variables, pushing and popping the variable holding that alist on each new "application" of a Symbol that has a lambda definition. This works. Several people I know have written such interpreters, and they do work. But indeed consing, *** just to interpret some piece of Lisp code ***, is anathema to most of us. Fortunately, there exist completely stack-bound solutions. As I mentioned before, Lisp/370 has a most elegant solution (and probably the first correctly working implementation of spaghetti stacks). The interpreter works by "compiling up on the fly" a stack frame exactly like the one that would exist if the code were to be run compiled; function boundaries are marked in the frame so that a PROG within a PROG [which produces two different frames -- one an extension of the other -- in the spaghetti model] will not signal the end of the lexical context. All variable lookups are done by a stack-searching primitive. But the Interpreter was itself written in Lisp (Ha, Ha!) Now, "Corky" Cartwright is caught in a misconception which suggests that he either hasn't seen, or perhaps didn't fully understand, my paper in the 1982 Lisp conference titled "Constant Time Interpretation for Shallow-Bound Variables in the Presence of Mixed SPECIAL/LOCAL Declarations". [I don't mean any offense here. I only know of 5 people besides myself who were interested enought to try to understand the algorithm]. In particular, his claim "The explanation for this difference is that in a conventional shallow binding implementation of lexical LISP, updating and restoring the shallow binding table on a function call requires about twice the computation (on the average) as it does in its dynamically scoped counterpart." would seem to be belied by the actual implementation mentioned in the paper. The trick was that each Symbol has an independent cell for the shallow binding of local bindings and another for the shallow binding of special bindings. The code which implements "binding" is essentially the same, regardless of whether it is "lexical" or "dynamic", since the data structures are homologous. Yet, interpreters may be slow for a variety of reasons; often it's the tremendous number of "hooks" and kludges needed to make debugging easier. I don't know why T's interpreter is so slow; I don't even know how to evaluate the relative cost of the modules needed to support the interpreter described in "Constant Time . . . " mentioned above. In the end, I agree totally with your exclamation: there is no excuse at all for a situation like this being allowed to exist. In the aggregate, a correct interpreter can *** at most *** cost a few billion machine cycles more; a buggy interpreter will certainly cost thousands of man-hours of wasted time. Do you know what a "cycle" on a modern Lisp machine costs? How about the 8 hours per year you spend "in a black hole" because of a mismatch between the Interpreter and Compiler; what is that worth to you? What is it worth to a $30,000/year programmer? What is it worth to a $60,000/year research scientist?  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.22) id AA00530; Thu, 9 Feb 84 10:37:52 pst Received: by ucbkim.ARPA (4.16/4.22) id AA23800; Mon, 6 Feb 84 10:43:45 pst Date: Mon, 6 Feb 84 10:43:45 pst From: baden%ucbkim@Berkeley (Scott B. Baden) Message-Id: <8402061843.AA23800@ucbkim.ARPA> To: franz-friends%ucbkim@Berkeley Subject: T vs. franz From HGA@MIT-MC Mon Feb 6 05:59:06 1984 Subject: T vs. franz To: franz-friends@BERKELEY . . . A dynamically scoped lisp violates referential transparency . . . And what about 'rplaca', 'rplacd' and 'setq'?  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.22) id AA03202; Thu, 9 Feb 84 13:04:22 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA03115; Thu, 9 Feb 84 12:57:09 pst Received: from COLUMBIA-20.ARPA by UCB-VAX.ARPA (4.22/4.22) id AA02821; Thu, 9 Feb 84 12:47:19 pst Message-Id: <8402092047.AA02821@UCB-VAX.ARPA> Received: from CU20B by CUCS20 with DECnet; 9 Feb 84 15:41:50 EST Date: Thu 9 Feb 84 15:40:04-EST From: Travis Lee Winfrey Subject: Franz and T To: franz-friends%berkeley@CUCS20 Cc: Ui.Travis@CU20B, fateman%ucbdali%berkeley@CUCS20 Can we change the subject? Some people like Franz, others like T. "Let's call the whole things off" - Sammy Kahn, et al. Travis -------  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.22) id AA04688; Thu, 9 Feb 84 04:46:25 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA09934; Thu, 9 Feb 84 04:48:14 pst Received: from yale (yale.ARPA) by UCB-VAX.ARPA (4.22/4.22) id AA04588; Thu, 9 Feb 84 04:41:50 pst Message-Id: <8402091241.AA04588@UCB-VAX.ARPA> Received: by YALE-BULLDOG via CHAOS; Wed, 8 Feb 84 14:35:44 EST Received: from YALE-RING by YALE-CS via CHAOS; Wed, 8 Feb 84 14:24:22 EST Subject: Factor of 40? Date: Wed, 8 Feb 84 14:24:32 EST From: Jonathan Rees To: fateman%ucbdali@Berkeley Cc: franz-friends@Berkeley, Rees@YALE.ARPA From: Richard Fateman You can provide some evidence that the T system is faster. Of course it could be. Early papers on T claimed it was 40 times faster than Franz, but this is absurd, overall, since it would mean that T (on a VAX 780) would have to run about 10 times faster than a KL-10 Maclisp system. It is not clear what you mean about termination. ... Having read the first version as a member of the program committee, and hence a referee, I asked that the statement be supported or removed. It was removed. As principle author of the paper alluded to, and on reviewing my early drafts and correspondence with the program committee, I happen to know that: 1. No "early papers" by anyone directly associated with T, nor any later papers or other communications, including the initial or final drafts of the Lisp and FP Symposium paper, made any definite claims about T's speed. (Therefore there could have been no such statements to remove.) 2. The Symposium program committee never requested that any changes be made to the T paper. If you have evidence to the contrary then I would like to hear about it. (Perhaps you are thinking of something said by someone not affiliated with the project.) If not, then I request that you distribute a message retracting your statements. Your intent seems to be to discredit the T project by attributing to it claims which are obviously ridiculous to anyone trained in computer science.