Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.22) id AA24131; Wed, 8 Feb 84 11:12:26 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA25408; Wed, 8 Feb 84 11:11:59 pst Received: from CMU-CS-CAD (cmu-cs-cad.ARPA) by UCB-VAX.ARPA (4.22/4.22) id AA23330; Wed, 8 Feb 84 10:29:48 pst Date: Wednesday, 8 February 1984 13:29:12 EST From: Robert.Cartwright@cmu-cs-cad To: franz-friends@Berkeley Subject: Lexical scoping in LISP Message-Id: <1984.2.6.15.31.57.Robert.Cartwright@cmu-cs-cad> There is an interesting technical question connected with the religious debate over Franz vs. T: does lexical scoping force slow interpretation? My biggest complaint about T (and presumably Common LISP) is that interpretation is significantly slower than it is dynamically scoped LISPs like Franz. 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. On an intuitive level, the source of the extra cost is that the set of variables accessible in the calling environment but not in the called environment (e.g., local variables in the calling environment) must be removed from the shallow binding table; otherwise an occurrence of a free variable with the same name in the called function will be incorrectly interpreted. The most attractive solution to this problem that I have been able to devise is to modify the abstract syntax of the language (a heresy in the eyes of most LISPers) so that variables with same name declared at different lexical levels are represented by distinct atoms. Hence, the name X declared at level 1 is not EQ to the name X declared at level 2. The most obvious way to implement this constraint is to concatenate the lexical level of a variable onto its name to form the name of the atom representing the variable. Given this modification to the abstract syntax for Lexical LISP, the semantics of lexical and dynamic scoping are identical (assuming that all function data objects are closures -- the appropriate convention in a lexically scoped language). Hence, the same shallow binding implementation of function calls used in conventional LISP works for Lexical LISP as well. Although modifying the abstract syntax of LISP is incompatible with the goals of the Common LISP effort (where the proponents of lexical scoping will presumably have to accept slow interpretation), it does not appear to conflict with the objectives of new (incompatible) LISP dialects like T. Corky Cartwright  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.22) id AA15781; Wed, 8 Feb 84 01:37:15 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA20969; Wed, 8 Feb 84 01:39:44 pst Received: from PARC-MAXC.ARPA by UCB-VAX.ARPA (4.22/4.22) id AA15700; Wed, 8 Feb 84 01:33:08 pst Message-Id: <8402080933.AA15700@UCB-VAX.ARPA> Date: 8 Feb 84 01:38 PST From: JonL.pa@PARC-MAXC.ARPA Subject: T and Franz and the "Lexical" question To: Olin.Shivers@CMU-CS-H.ARPA Cc: Franz-Friends@Berkeley Re your message of 4 Feb 84 04:18:13 EST My apologies for what seems like a late entry in this discussion; but my original reply to you was sent shortly after receipt of your note on Saturday, and doesn't seem to have made it through the various mail forwardings. I rather concur with the insightful comments about the place of T "under the Lisp sun" made during this interval by Fateman and Fahlman, but you may find the additional comments herein enlightening. ------------------------------------------------------------------------- Your most recent comparison of T and Franz was so non-objective that it shouldn't require serious comment (even by your own admission, you were "beginning to froth at the mouth"). But you implied a certain familiarity with "lexical scoping", and those allegations arising therefrom deserve rebuttal (precisely because so many newcomers to the Lisp field seem to share the same misconceptions). 1) Lexical scoping and compatibility between the Interpreter/Compiler are totally independent dimensions. Lisp/370, done at IBM Research Labs in the mid 70's had dynamic scoping, *** but default lexical scoping ***, with a perfectly harmonious interpreter; Lisp/370 was a "deep bound" implementation, but see my paper in the 1982 Lisp Conference concerning an interpreter for a shallow-bound Lisp which achieves similar harmony (again - a Lisp that admits dynamic scoping). 2) Lexical scoping and compiler optimization have, again, almost nothing to do with each other. The T compiler is a derivative of the early S1 Lisp compiler by Guy Steele, which introduced the TN-packing ideas into Lisp compilers for the first time I know of. Needless to say, that Lisp permits dynamic scoping. 3) You praise T's "naming conventions [which] were reworked without worrying about compatibility with previous Lisps ...". Most AI researchers are concerned about sharing code, as well as ideas; there's every good reason for them to view this gratuitous renaming of the 25-year old Lisp primitives as a bothersome self-indulgence on the part of the authors. At least the changes made in Common Lisp were sanctioned by nearly a dozen different, independent, implementation groups. In fact, both the subject of the paper mentioned in (1), and the Lisp mentioned in (2) were versions of NIL -- which has dynamic scoping, despite your comparison of it to T. It also has lexical scoping. Where you, and so many others, appear to be confused is in the belief that having any lexical scoping rules out dynamic scoping *** in the same system ***. This exclusive nature -- no dynamic scoping allowed -- is the rule for SCHEME (and I dare say T, if it is a true "son of SCHEME"). When the mixed implementations are correctly done, there is no interference between the declared, implicitly or otherwise, lexical variables and the dynamic ones. [some writers use "fluid" or "special" for dynamic; some also use "local" for lexical"]. In fact, most programs written in MacLisp and Franz are lexically scoped. Some aren't. But the lexically-scoped ones are indeed compiled by the MacLisp compiler (at least -- and I think the later varieties of Franz compiler too) in essentially the same way as any restrictive lexically-scoped language would have them compiled. The signal difference is the treatment of FUNARGs, and a careful reading of the Sussman/Steele papers will reveal that. The reason why so many other Lispers do not share your enthusiasm for the SCHEME approach is that they have dropped FUNARGS as an interesting thing to worry about; hence there isn't much enthusiasm for a scheme (pun intended) that "does them right". On the other hand, I'll admit that the functional programming types are more enthused [note well: "functional programming" does *** not *** mean merely that the basic module is a function. Regarding the "globality" of function names in Lisp, a long discussion ensued last fall on the distribution list LISP-FORUM@MIT-MC, and the net upshot was that it was a trivial matter of style preference for most Lisp users.] Rather, modern directions for Lisp have been inspired by SmallTalk, in which "smart" objects are first-class citizens; and a plethora of primitives have been added to make using them fun and easy [ Flavors in the Lisp Machine, EXTENDs in MacLisp, and LOOPS in Interlisp-D]. While one can emulate "objects" with FUNARGs, so too he can emulate FUNARGs with "objects" and this latter approach is surely more general. A modest amount of compiler development and systems support work would probably put both emulations in the same ball park as far as speed goes; but the syntax for using FUNARGS as "objects" is too restrictive [there's a long history in the MIT LispMachine project about the first implementations of "flavors" as funargs, and how it wasn't quite right that way.]. If it's not too much to ask, I'd be curious to know just which of your professors at CMU declined to consider AI projects written in Franz. Although I've heard a lot of complaints against Franz's lack of a good debugging environment, I've never heard any reports that it was significantly slower than the other VAX alternatives.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.21) id AA19510; Tue, 7 Feb 84 07:51:23 pst Received: from utah-cs.ARPA (utah-gateway.ARPA) by ucbkim.ARPA (4.16/4.22) id AA08372; Tue, 7 Feb 84 07:55:18 pst Received: by utah-cs.ARPA (4.19/3.33.3) id AA27511; Tue, 7 Feb 84 08:49:38 mst Date: Tue, 7 Feb 84 08:49:38 mst From: shebs@utah-cs (Stanley Shebs) Message-Id: <8402071549.AA27511@utah-cs.ARPA> To: franz-friends%kim@Berkeley, norvig%ucbdali@Berkeley Subject: Re: Franz errors... Hey, what's lisp without a little bizarreness? (Try banging certain property lists in PSL - very entertaining!)  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.21) id AA02632; Mon, 6 Feb 84 15:56:18 pst Received: from ucbdali.ARPA by ucbkim.ARPA (4.16/4.22) id AA00445; Mon, 6 Feb 84 15:54:34 pst Received: by ucbdali.ARPA (4.22/4.22) id AA15168; Mon, 6 Feb 84 15:54:10 pst Date: Mon, 6 Feb 84 15:54:10 pst From: jacobs%ucbdali@Berkeley (Paul Jacobs) Message-Id: <8402062354.AA15168@ucbdali.ARPA> To: franz-friends%ucbdali@Berkeley Subject: getting compiled franz to run faster Cc: wilensky%ucbdali@Berkeley Part of the reason why many have not had much success writing franz programs which run at a reasonable speed is the lack of knowledge about some important features. Most important is to avoid expensive time in function calls. Below is a list of some suggestions for achieving significant speedups: (1) Don't use the interpreter unless you really have to. It's not that difficult to get programs to compile in franz. If you do use the interpreter, make sure displace-macros is set to t. Otherwise macros will be expanded each time they are called, causing horrendous slowdowns. (2) Run programs with (sstatus translink on). This can give up to a 50% speedup. Tracing automatically turns translink off, and you should turn it off manually, (sstatus translink nil), when using the debugger. (3) When running debugged programs, you can get a large speedup by declaring most of your functions to be local: (declare (localf ...)) . This avoids any time in the transfer table. Of course, calls to these functions will no longer appear on the stack, so it's not advisable while debugging. In the Berkeley AI research group, we have production-mode versions of our programs which declare all possible functions local and use ``include'' to contain the non-production version. (4) Use open-coded functions. The following is a list of some commonly- used functions and their open-coded versions (many franz users have other versions of common functions which are also not open-coded): Function Open-coded version ________ __________________ lessp, greaterp >&, <& add1, sub1 1+, 1- plus, minus +, - . . . . . . (5) Compile macros. Write cmacros or declare ``macros'' to be t while compiling. (6) Allocate sufficient storage space while compiling and running programs. The garbage collector will get around to establishing more space, but it is better to start with a lot of space for a large program. paul (jacobs@berkeley)  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.21) id AA00275; Mon, 6 Feb 84 14:03:40 pst Received: from ucbdali.ARPA by ucbkim.ARPA (4.16/4.22) id AA27075; Mon, 6 Feb 84 13:53:08 pst Received: by ucbdali.ARPA (4.22/4.22) id AA13706; Mon, 6 Feb 84 13:52:18 pst Date: Mon, 6 Feb 84 13:52:18 pst From: norvig%ucbdali@Berkeley (Peter Norvig) Message-Id: <8402062152.AA13706@ucbdali.ARPA> To: franz-friends%kim@Berkeley Subject: Franz errors... My favorite: -> (member 'a 'b) ... never returns (infinite loops). On the other hand, -> (member nil 'a) a ... is not quite what you'd expect. I realize the manual says the second arg must be a list, but this is still rather bizarre behaviour.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.21) id AA06373; Mon, 6 Feb 84 19:08:28 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA03560; Mon, 6 Feb 84 19:07:01 pst Received: from PARC-MAXC.ARPA by UCB-VAX.ARPA (4.22/4.21) id AA06193; Mon, 6 Feb 84 19:00:07 pst Message-Id: <8402070300.AA06193@UCB-VAX.ARPA> Date: 6 Feb 84 13:12 PST From: masinter.pa@PARC-MAXC.ARPA Subject: Re: T vs. franz In-Reply-To: Harold G. Ancell 's message of 6 Feb 84 08:59 EST To: HGA@MIT-MC.ARPA Cc: franz-friends@Berkeley "I can't understand how anyone can defend a defaultly dynamically scoped Lisp except on the grounds of tradition. A dynamically scoped lisp violates referential transparency: i.e. merely by chosing a variable name unwisely and using it as a free variable you can get screwed if someone else's function you call temporally binds the variable." It is possible that you don't understand how dynamic scoping works. Dynamic scoping does not violate referential transparency. If a function call another which binds a variable, the callee's actions on its temporary variable does not affect the value as seen by the caller. Did you mean something else? "Big packages written in dynamically scoped lisps tend to consist of lots of top level functions, and to avoid naming conflicts people tend to use very long variable names like subprogram-name-do-the-right-thing. Lexically scoped lisps allow the use of Algol style block structure; you can hide functions that are used only by one superior function." The question only has to do with dynamic scoping of VARIABLES: the issue of the name scope of FUNCTIONS can be separated and is in most commonly used Lisp dialects. While function-name scope is an important issue, it is partially orthogonal to the lexical vs. dynamic scoping debate. "Another important point is that in lexically scoped lisps the semantics of the interpreter and the compiler are the same." One way to avoid the problem in dynamically scoped lisps is to fix the compiler to preserve the interpreters symantics (all variables are "special" by default.) (This is done in Interlisp.) That is to say, it is quite possible to have a dynamicly scoped lisp where the semantics interpreted and compiled code is the same. "Elegance" and "cleanliness" may argue for lexical scoping, but these are terms which do not have objective metrics. (One judges them by personal appreciation.) "Referential transparency" and "consistent semantics of interpreted and compiled code" are better criteria, but lexical scoping does not clearly dominate dynamic scoping using those criteria.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.21) id AA29756; Mon, 6 Feb 84 13:38:31 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA26692; Mon, 6 Feb 84 13:37:19 pst Received: from nrl-aic (nrl-aic.ARPA) by UCB-VAX.ARPA (4.22/4.21) id AA29555; Mon, 6 Feb 84 13:30:24 pst Message-Id: <8402062130.AA29555@UCB-VAX.ARPA> Date: 6 Feb 1984 16:26-EST From: Dan Hoey Subject: Franz core dumps To: franz-friends@Berkeley In Opi 38.06 and 38.26: (let ((x '(())) (y '(()))) (rplaca x x) (rplaca y y) (equal x y)) Illegal instruction (core dumped) equal should check for stack overflow.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.21) id AA24465; Mon, 6 Feb 84 08:41:00 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA21857; Mon, 6 Feb 84 08:42:25 pst Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.22/4.21) id AA24376; Mon, 6 Feb 84 08:35:43 pst Received: by ucbdali.ARPA (4.22/4.22) id AA10308; Mon, 6 Feb 84 08:42:06 pst Date: Mon, 6 Feb 84 08:42:06 pst From: fateman%ucbdali@Berkeley (Richard Fateman) Message-Id: <8402061642.AA10308@ucbdali.ARPA> To: Olin.Shivers@CMU-CS-H Subject: Re: T and franz Cc: franz-friends@Berkeley Subject: T and franz Hmm. It strikes me that there have been a good many wild claims made on both side of this argument. Maybe I can clear a few up. Ditto, otherwise I'd just keep my mouth shut... The professor that announced we shouldn't use franz was Geoff Hinton. Of course Geoff might have provided evidence of slowness. You still haven't. There has only been one paper published on T ("T: a Dialect of Lisp" in the Conference Record of the '82 Symposium on LISP and Functional Programming, August 1982). I just read through it again; it makes no claims at all about speedup factors over franz. 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. The only fast lisps I know of are Maclisp, Zetalisp, and T. Don't you yet understand that your OPINION is not being questioned. I know what you THINK is true. You don't want to be confused by the facts. I truly do not know how fast T is in comparison to Franz, but I can tell you that there are benchmarks illustrating that Franz on a vax 780 is faster than a Symbolics 3600, for some purposes. Perhaps RPG@SU-AI will have some information, someday. Too bad Barry had such a rough time getting T up at Harvard. I had no problems here at CMU. Are you using 4.2BSD UNIX on a VAX? If so I would think you'd do us all a favor and make it available. Because we haven't been able to get it to work here. He's designed a language so clean, elegant and powerful it brings tears to your eyes. Yes, but why call it Lisp? How about ONION (Onion's Not it's Original Name ?) (Sorry Jon..) I look forward to a working 4.2BSD T (at a price I can afford), and some benchmark data.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.21) id AA22257; Mon, 6 Feb 84 05:53:50 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA20754; Mon, 6 Feb 84 05:58:25 pst Received: from MIT-MC (mit-mc.ARPA) by UCB-VAX.ARPA (4.22/4.21) id AA22234; Mon, 6 Feb 84 05:51:44 pst Message-Id: <8402061351.AA22234@UCB-VAX.ARPA> Date: 6 February 1984 08:59 EST From: Harold G. Ancell Subject: T vs. franz To: franz-friends@Berkeley I can't understand how anyone can defend a defaultly dynamically scoped Lisp except on the grounds of tradition. A dynamically scoped lisp violates referential transparency: you can not guarantee that a equivalent texual substitution of one variable name with another doesn't change the semantics of your code. i.e. merely by chosing a variable name unwisely and using it as a free variable you can get screwed if someone else's function you call temporally binds the variable. Package systems help this problem with large different systems, like avoiding conflicts between a editor and a window system, but you still have to be careful when you're writing code with someone else. And I personally think package systems are a gross and inelegant kludge. Scott Falhman is of course correct that you have to have dynamic scoping avaliable. Big packages written in dynamically scoped lisps tend to consist of lots of top level functions, and to avoid naming conflicts people tend to use very long variable names like subprogram-name-do-the-right- thing. Lexically scoped lisps allow the use of Algol style block structure; you can hide functions that are used only by one superior function. Another important point is that in lexically scoped lisps the semantics of the interpreter and the compiler are the same. In systems where arranging incremental compilation is not completely trivial (i.e. anything other than a lisp machine where you can invoke the compiler on a function in the editor with a keystroke) you tend to debug you code in the interpreter and then debug it again when you compile it. All the lisp machine users I've worked with only use interpreted functions when they are tracking down subtle bugs and don't want to deal with assembly code. The bottom line for me is that after doing lots of system work and maintaince on the lisp machine elegance and cleanliness assume value beyond aesthestics. - Harold  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.21) id AA20635; Mon, 6 Feb 84 04:03:17 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA20206; Mon, 6 Feb 84 04:06:20 pst Received: from MIT-MC (mit-mc.ARPA) by UCB-VAX.ARPA (4.22/4.21) id AA20352; Mon, 6 Feb 84 03:59:39 pst Message-Id: <8402061159.AA20352@UCB-VAX.ARPA> Date: 6 Feb 1984 07:05:53-EST From: Olin.Shivers@CMU-CS-H Subject: T and franz Apparently-To: Hmm. It strikes me that there have been a good many wild claims made on both side of this argument. Maybe I can clear a few up. The professor that announced we shouldn't use franz was Geoff Hinton. As you will note, he also warned against using Common Lisp. 04-Feb-84 16:13 Geoff Hinton at CMU-CS-A AI qual task As I announced in the last lecture, the programming task will involve writing a search program that runs fast. We have decided NOT to test your common-sense in choosing a language, and so you are hereby warned that Franz Lisp and common lisp on the vaxes are rather slow and you will be at a big disadvantage if you use them... Mr. Fateman says that "early papers on T claimed it was 40 times faster than Franz." I've never heard such a claim. There has only been one paper published on T ("T: a Dialect of Lisp" in the Conference Record of the '82 Symposium on LISP and Functional Programming, August 1982). I just read through it again; it makes no claims at all about speedup factors over franz. Fateman certainly has one point to be reckoned with: if you want to run any number of the large, useful programs that haven't been written in T, (Macsyma, for instance) you can't use T. There are plans to implement Common Lisp, et al. in T, but they are pretty far down on the queue from what I hear. Of course, the reverse is true, although the crying need to import software written in T has yet to be established. In general, I don't think much of compatibility issues with respect to evaluating languages. People who tell me that T is bad because it isn't compatible with older lisps sound like people who tell me that Fortan and Cobol are great languages because there is so much code written in them. It reminds me of Steele's comment in a Common Lisp draft to the effect that "yesterday's radicals are today's conservatives." There is a certain point in language design beyond which you cannot go if you are going to limit yourself to compatible designs. I can't claim that T is trivially portable in franz or Interlisp, but I do think it is what lisp ought to be. If you need to port software written in brand X lisp, then run brand X lisp. If you are writing new software, I bet you'd be a lot happier doing it in an efficient, lexically scoped lisp. Like T. Mr. Fateman apparently thinks I claim that "(3) CMU professors like it [T] and hate the sight of franz." Not at all. *I* like T and hate the sight of franz; the professors will have to speak for themselves. I have to disagree with Fahlman, who says that franz "doesn't have a reputation for slowness, except among those people who think all Lisps are slow." He's the first I've heard at CMU defend franz's speed. Most of the lispers I know -- people who think lisps don't have to be slow, if done right -- hold franz to be at the slow end of the spectrum. The only fast lisps I know of are Maclisp, Zetalisp, and T. Barry Shein claimed that "tons of it [T] is written in LAP (i.e. assembler)." I just went and checked through the sources here at CMU. T T&LAP C Vax Assembler #Files 79 2 1 1 #Lines 13,000 1,500 314 50 Among the stuff written in T I found the code for the evaluator, the garbage collector, the reader, and the bignum package. So to reiterate my claim, T is written in T. 90%, anyway. Those statistics don't include the moby compiler or the 3,000 T lines of utilities (loop packages, hash tables, etc) many people use. They also don't include the lap code used for the Apollo and VMS kernels -- I only counted Unix lap code. It was also a quick check, and it was an old T (2.6). The new T (2.7) could have different numbers. The implementors are always trying to shrink the non-T kernel. But you get the idea. Too bad Barry had such a rough time getting T up at Harvard. I had no problems here at CMU. I'm currently writing a large 3D hidden-surface graphics system, and having a very pleasant time. Maybe he had an old, not-very-portable version? Why do I think T is so great? Two major reasons. The first is all the wins you inherit when your default scoping is lexical: correct procedure open-coding, compiler optimisations, modularity, tight control over the environment that any function executes in, and compiled semantics equal to interpreted semantics. Second, over and above the scoping issue, I think Rees has done a brilliant job of language design. He's designed a language so clean, elegant and powerful it brings tears to your eyes. Razor's edge semantics. The right stuff. For instance, Fateman points out that franz has good data types for systems programming because one can generate C-like declarations. But T goes beyond integers, characters, structures, floating point numbers, etc and gives you wild things like pools, populations, and weak pointers. Just the thing for systems hacking. Of course, as Mr. Fateman would be the first to point out, the last half of that previous paragraph is unsupported opinion. My advice is: get a copy of the T2.7 manual and generate your own opinion. So, the points about T: -Great language, considered in isolation -Fast -Elegant -But not compatible with franz, interlisp, etc, etc. It's difficult to explain in a bboard post why lexical lisps win, so in closing I will once again urge people who want to know what all the shooting is about to read the Sussman&Steele papers. -Olin  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.21) id AA17904; Sun, 5 Feb 84 23:00:24 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA18426; Sun, 5 Feb 84 23:01:37 pst Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.22/4.21) id AA17785; Sun, 5 Feb 84 22:54:57 pst Received: by ucbdali.ARPA (4.22/4.22) id AA08027; Sun, 5 Feb 84 23:01:24 pst Date: Sun, 5 Feb 84 23:01:24 pst From: mcgeer%ucbdali@Berkeley (Rick McGeer) Message-Id: <8402060701.AA08027@ucbdali.ARPA> To: franz-friends@Berkeley By the way, I am NOT an author of Franz, wrote none of that code myself...  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.21) id AA17819; Sun, 5 Feb 84 22:56:57 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA18400; Sun, 5 Feb 84 23:00:39 pst Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.22/4.21) id AA17775; Sun, 5 Feb 84 22:53:28 pst Received: by ucbdali.ARPA (4.22/4.22) id AA08002; Sun, 5 Feb 84 22:59:50 pst Date: Sun, 5 Feb 84 22:59:50 pst From: mcgeer%ucbdali@Berkeley (Rick McGeer) Message-Id: <8402060659.AA08002@ucbdali.ARPA> To: franz-friends@Berkeley, mike@rice Subject: Re: T in reality Well, I just glanced over some Franz source, both C and Lisp, and, for those of you that care, it looks like pretty good code to me...certainly better than any I didn't write myself...  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.21) id AA12635; Sun, 5 Feb 84 15:15:46 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA12547; Sun, 5 Feb 84 15:19:48 pst Received: from RICE (rice.ARPA) by UCB-VAX.ARPA (4.22/4.21) id AA12611; Sun, 5 Feb 84 15:13:02 pst Received: by RICE (AA25576); Sun, 5 Feb 84 13:48:13 cst Date: Sun, 5 Feb 84 13:38:59 CST From: Mike Caplinger Subject: Re: T in reality To: franz-friends@Berkeley Message-Id: This is degenerating into a real religious argument. I think Richard Fateman's message says all that needs to be said on this subject. T and Franz both have their strengths and weaknesses, as do all the other Lisps that run on the VAX, and everywhere else. Yale is primarily targeting T for the Apollo, which may explain their reported lack of enthusiasm for supporting 4.2. But perhaps you should blaim the 4.2 people for their half-hearted, inadequate "compatibility" option, rather than the T people. People who are interested in T may wish to contact Rees@Yale (sorry, Jonathan...) Also, in all honesty, isn't a lot of the Franz code pretty unreasonably written, too?  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.21) id AA02132; Sat, 4 Feb 84 22:45:40 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA06068; Sat, 4 Feb 84 22:49:40 pst Received: from MIT-MC (mit-mc.ARPA) by UCB-VAX.ARPA (4.22/4.21) id AA02107; Sat, 4 Feb 84 22:43:00 pst Message-Id: <8402050643.AA02107@UCB-VAX.ARPA> Date: Sun 5 Feb 84 01:49-EST From: Barry Shein Subject: T in reality To: franz-friends@Berkeley I hate to inject a strong dose of reality into this discussion but I feel obligated to share my recent experience with T with this community: We recently (Jan) went from 4.1 to 4.2bsd. I gen'd in the 4.1 compatibility mode. One of the few programs that would not run was T. I sat down, looked at the sources and prepared to maybe make a few small fixes and recompile. It is not 'written in T' nearly to the degree claimed, tons of it is written in LAP (ie. assembler with parens around it.) Worse, we couldn't recompile it on a 4.1 system (Harvard's VAX.) Worse, when we called YALE they seemed disinterested. For example, the makefile provided refers to TWENEX files and (mostly) unix stuff. Result, a graduate student with lots of beached code. He finally got it to work by some obscure patch but I would think twice before relying on T, the software engineering behind Franz make it MUCH more reasonable to use in my opinion. The comparisons pale against this kind of lossage. PostScript: If, for some reason, I was working with some totally unrepresentative version of T, my apologies. It is possible (I relied on the grad student to get me the necessary code) but I doubt that is the case.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.21) id AA22242; Sat, 4 Feb 84 11:13:41 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA00626; Sat, 4 Feb 84 11:16:45 pst Received: from CMU-CS-C.ARPA by UCB-VAX.ARPA (4.22/4.21) id AA22191; Sat, 4 Feb 84 11:10:00 pst Message-Id: <8402041910.AA22191@UCB-VAX.ARPA> Received: ID ; Sat 4 Feb 84 14:16:19-EST Date: Sat, 4 Feb 1984 14:16 EST From: Scott E. Fahlman To: franz-friends@Berkeley Cc: fahlman@CMU-CS-C.ARPA Subject: T and franz In-Reply-To: Msg of 4 Feb 1984 12:50-EST from Richard Fateman Well, I wanted to sit this one out, but feel I must respond to a few of the points that were made. Just to expose my biases, I've been rather heavily involved in the Common Lisp specification effort and have been more or less in charge of the Common Lisp implementation efforts for Perq and Vax. I've studied both Franz and T and have played with them, but have not written large amounts of code in either. I'm sort of on the fence about lexical scoping. We used it in Common Lisp as the default, though dynamic scoping is available via declarations. Lexical scoping makes things like closures a bit cleaner and enables the compiler to produce better code in some places because it can see all of the relevant context surrounding a form. It also slows down the interpreter a good deal. I think I'd stay with lexical scoping if we had it to do over again, but it's not a big deal. The average programmer will hardly never notice the difference, except when he gets into closures. I would not use a Lisp that didn't provide some sort of dynamic scoping. There are times when you need that and nothing else will do. I'm not sure which CMU professor forbade his students to use Franz. It wasn't me. A lot of people here consider Franz a bit flaky -- there are still some bugs and there is not as much runtime checking as in Common Lisp -- but it doesn't have a reputation for slowness, except among those people who think all Lisps are slow. Of course, any large Lisp program will seem slow on a crowded Vax with insufficient memory for everyone's working sets. The limited benchmarks we have run seem to put Vax Common Lisp and Franz at about the same speed right now. People at DEC are working hard to speed up the Common Lisp; presumably there are some people working on the speed of Franz as well. My guess is that for real work T is somewhat faster, maybe by as much as a factor of two. T is a simpler language and can therefore be compiled more tensely, making better use of registers for argument-passing. Unfortunately, the wild claims that the Yale people initially made about the speed of T tend to cast serious doubt on any further benchmarks they might provide. I don't know of any independent studies of T's speed. DEC never abandoned Steele's Rabbit compiler because they never considered using it in the first place. They are using my compiler, originally developed for the Perq, with a different code-generator and post-optimizer. This is not a super-optimizing compiler, but it is not pessimizing either. Its main drawback is that it uses the stack a lot and does not make optimal use of the registers for argument passing. Its main advantage is that it has been available and working for some time. A super-optimizing Common Lisp compiler is being written for the S1 by Dick Gabriel, Rod Brooks, and (in earlier times) Guy Steele. Whenever this is done, it will probably replace my compiler as the portable core for other Common Lisp compilers. DEC will probably adopt this technology whenever it is ready. The delays seem to be more a matter of personnel and support than technical problems. I must agree with Fateman that T is considerably less interesting than it might be because of the large differences between it and earlier Lisps. Maclisp, Franz, PSL, Zetalisp, and Common Lisp are all pretty close together, and the prospects for large-scale migration of code among these languages are excellent. Interlisp -- the programming language, not the total programming environment -- is also an easy port away. T and Scheme are different enough that they will have to thrive on the basis of home-grown users and applications and not on immigrants and foreign trade. Maybe they're superior enough (and the Yalies are energetic enough) to pull that off -- I don't know. In the end, I think that the attractiveness and value of any Lisp environment is going to depend almost exclusively on the number of active researchers using it (and using closely-related dialects). The inherent quality of the Lisp is a second-order effect. -- Scott Fahlman, CMU  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.21) id AA20906; Sat, 4 Feb 84 09:48:14 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.22) id AA00216; Sat, 4 Feb 84 09:50:44 pst Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.22/4.21) id AA20821; Sat, 4 Feb 84 09:43:56 pst Received: by ucbdali.ARPA (4.22/4.22) id AA25060; Sat, 4 Feb 84 09:50:20 pst Date: Sat, 4 Feb 84 09:50:20 pst From: fateman%ucbdali@Berkeley (Richard Fateman) Message-Id: <8402041750.AA25060@ucbdali.ARPA> To: Olin.Shivers@CMU-CS-H Subject: Re: T and franz Cc: franz-friends@Berkeley From @MIT-MC:shivers@cmu-cs-h Sat Feb 4 01:21:34 1984 Subject: T and franz Apparently-To: T is one of the new lexically-scoped lisps. That is, T is a new language which doesn't use the same semantics as Lisp, but rather different semantics currently in vogue. I can't argue against this because my current work is in a lexically scoped and strongly typed language. It is implemented on top of Franz Lisp at the moment. I do not see any advantage, linguistically, in building such systems on top of T or Franz. I've written large systems, AI, and 3D graphics programs in both franz and T. I haven't seen any that you've written in Fran. Were they any good? I prefer T to franz hands down. The question of "why" can be broken up into (1) franz is the pits and (2) T is good stuff. In other words, you find it difficult to be objective, and prefer to give us your subjective impression. Without knowing your qualifications to judge, this is hard to evaluate. Here at CMU, our professors told us last week that anyone writing AI qualifier programming tasks in franz wouldn't be likely to get a good grade. I find that rather hard to believe. They didn't have the patience to wait around for the programs to terminate. What can I say? 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. Just the fact that T is lexically scoped gives you tremendous power and cleanliness in your code. One of the advantages of a lexically scoped lisp like T is that the semantics of code is the same interpreted and compiled. Lexical scoping also provides opportunities for compiler optimizations not available to dynamically scoped lisps. While franz is known for its pessimizing compiler, T uses an optimizing compiler based on Bliss tn packing techniques. As I said earlier, evidence would be of interest. I heard, for example, that the very highly optimizing Common Lisp compiler based on Guy Steele's Rabbit design was abandoned by DEC. Maybe some reader could confirm this. Aside from efficiency issues, T is a pleasant language to write in. The whole concept is just very clean. The entire system -- compiler, interpreter, gc, loader -- is written in T. This is certainly a fine prospect. Though if it doesn't run Lisp programs (e.g. Macsyma, Boyer-Moore Theorem Prover, PAM, PEARL, SLANG) then it becomes less interesting to me. I guess we have different objectives. The language has great data types for systems hacking. The naming conventions were reworked without worrying about compatibility with previous lisps, with the result that the syntax was cleaned up considerably. Etc, etc.. I could go on, but I'm beginning to froth at the mouth. Have you looked at "C"? Someone here wrote a package for Franz to make available the same data types and structuring as available in "C". I already knew that T had strong advocates (I wonder, are they the same Yalies who thought APL was the cat's meow a few years back?) But as for the following statements (1) T is fast. (2) T is a good language design, even if it is not Lisp. (3) CMU professors like it and hate the sight of Franz. (4) Olin Shivers likes T better than Franz. I am aware of evidence supporting only (2) and (4).  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.21) id AA15349; Sat, 4 Feb 84 01:16:10 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.13) id AA02462; Sat, 4 Feb 84 01:19:46 pst Received: from MIT-MC (mit-mc.ARPA) by UCB-VAX.ARPA (4.22/4.21) id AA15311; Sat, 4 Feb 84 01:13:36 pst Message-Id: <8402040913.AA15311@UCB-VAX.ARPA> Date: 4 Feb 1984 04:18:13-EST From: Olin.Shivers@CMU-CS-H Subject: T and franz Apparently-To: I stand corrected by Mr. Fateman. Perhaps I should have said: If one is interested in running lisp on an Apollo, I recommend looking into T. It is a lisp very well supported on Apollo workstations, and has many advantages over franz. From: mcgeer%ucbdali@Berkeley (Rick McGeer) Pardon my ignorance, but why (exactly) is T much nicer than Franz? T is one of the new lexically-scoped lisps. The advantages of a lexically scoped lisp were explored in detail in a series of papers published at MIT by Gerald Sussman and Guy Steele. Their lexically-scoped dialect was called Scheme. I emphatically recommend these papers to anyone interested in these issues; they are jewels of scholarly writing. Most of the new lisps (Common Lisp, T, and NIL for example) are lexically scoped; it appears to be the direction that lisp is moving in. I've written large systems, AI, and 3D graphics programs in both franz and T. I prefer T to franz hands down. The question of "why" can be broken up into (1) franz is the pits and (2) T is good stuff. Here at CMU, our professors told us last week that anyone writing AI qualifier programming tasks in franz wouldn't be likely to get a good grade. They didn't have the patience to wait around for the programs to terminate. What can I say? Just the fact that T is lexically scoped gives you tremendous power and cleanliness in your code. One of the advantages of a lexically scoped lisp like T is that the semantics of code is the same interpreted and compiled. Lexical scoping also provides opportunities for compiler optimizations not available to dynamically scoped lisps. While franz is known for its pessimizing compiler, T uses an optimizing compiler based on Bliss tn packing techniques. Aside from efficiency issues, T is a pleasant language to write in. The whole concept is just very clean. The entire system -- compiler, interpreter, gc, loader -- is written in T. The language has great data types for systems hacking. The naming conventions were reworked without worrying about compatibility with previous lisps, with the result that the syntax was cleaned up considerably. Etc, etc.. I could go on, but I'm beginning to froth at the mouth. Check it out. Why use a Maclisp knockoff when you can be state-of-the-art? And remenber, T is the language recommended by four out of five dentists for their patients who choose to hack lisp. -Olin Shivers  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.21) id AA12850; Fri, 3 Feb 84 22:37:46 pst Received: from ucbdali.ARPA by ucbkim.ARPA (4.16/4.13) id AA00857; Fri, 3 Feb 84 22:36:37 pst Received: by ucbdali.ARPA (4.22/4.22) id AA22988; Fri, 3 Feb 84 22:36:28 pst Date: Fri, 3 Feb 84 22:36:28 pst From: mcgeer%ucbdali@Berkeley (Rick McGeer) Message-Id: <8402040636.AA22988@ucbdali.ARPA> To: Olin.Shivers@CMU-CS-H, fateman%ucbdali@Berkeley Subject: Re: porting franz to an Apollo Cc: franz-friends%kim@Berkeley Pardon my ignorance, but why (exactly) is T much nicer than Franz?  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.21) id AA12452; Fri, 3 Feb 84 22:06:39 pst Received: from ucbdali.ARPA by ucbkim.ARPA (4.16/4.13) id AA00616; Fri, 3 Feb 84 22:09:24 pst Received: by ucbdali.ARPA (4.22/4.22) id AA22635; Fri, 3 Feb 84 21:57:09 pst Date: Fri, 3 Feb 84 21:57:09 pst From: fateman%ucbdali@Berkeley (Richard Fateman) Message-Id: <8402040557.AA22635@ucbdali.ARPA> To: Olin.Shivers@CMU-CS-H Subject: Re: porting franz to an Apollo Cc: franz-friends%kim@Berkeley From @MIT-MC:shivers@cmu-cs-h Fri Feb 3 21:03:46 1984 Subject: porting franz to an Apollo Why would anybody want to port franz to an Apollo when there is already a much nicer lisp implemented for Apollos: T. I hope the original inquirer gives his/her reasons. The question is reasonable since Franz runs on so many other 68000 systems, Apollo would seem to be a good prospect. (At Berkeley we haven't heard of any port to Apollo.) T runs on Apollos, Berkeley Unix vaxen, and VMS vaxen. There are at least 7 Lisps on VAXes: NIL, PSL, T, YLISP, Interlisp, Common Lisp and Franz.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.21) id AA11076; Fri, 3 Feb 84 20:58:16 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.13) id AA29852; Fri, 3 Feb 84 21:00:18 pst Received: from MIT-MC (mit-mc.ARPA) by UCB-VAX.ARPA (4.22/4.21) id AA11005; Fri, 3 Feb 84 20:54:01 pst Message-Id: <8402040454.AA11005@UCB-VAX.ARPA> Date: 3 Feb 1984 23:58:19-EST From: Olin.Shivers@CMU-CS-H Subject: porting franz to an Apollo Apparently-To: Why would anybody want to port franz to an Apollo when there is already a much nicer lisp implemented for Apollos: T. T runs on Apollos, Berkeley Unix vaxen, and VMS vaxen. Its cost for non-profit types is between $0 and $75, and for real companies, $500. For more information, you'd want to contact Jonathan Rees (rees@yale). -Olin Shivers  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.21) id AA04764; Fri, 3 Feb 84 14:07:54 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.13) id AA24792; Fri, 3 Feb 84 14:07:39 pst Received: by UCB-VAX.ARPA (4.22/4.21) id AA04617; Fri, 3 Feb 84 14:01:26 pst Received: by decvax.UUCP (4.12/4.13) id AA06056; Fri, 3 Feb 84 16:01:44 est Received: by clan.UUCP (4.12/4.7) id AA05362; Wed, 1 Feb 84 13:03:01 est Date: Wed, 1 Feb 84 13:03:01 est From: decvax!clan!holtz@Berkeley (Neal Holtz) Message-Id: <8402011803.AA05362@clan.UUCP> To: nrcaero!dciem!utzoo!decvax!ucbvax!franz-friends@Berkeley Subject: Porting franz to Apollo? Does anyone have any experience with porting to Apollo Domain? Any estimates in man hours/days/months/years for how long it might take a sharpie?  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.21) id AA12418; Tue, 31 Jan 84 10:59:13 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.13) id AA20759; Tue, 31 Jan 84 10:55:51 pst Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.22/4.21) id AA12296; Tue, 31 Jan 84 10:51:34 pst Date: Tue, 31 Jan 84 10:51:33 pst From: John Foderaro (on an sun-e) Message-Id: <8401311851.1218@ucbmike.ARPA> Received: by ucbmike.ARPA (4.17/3.5) id AA01218; Tue, 31 Jan 84 10:51:33 pst To: franz-friends@Berkeley Subject: LISPcraft, a book on Lisp and Franz. Cc: A new Lisp book is due out March 23rd which may be especially interesting to Franz Lisp users or potential Franz Lisp users. The title is `LISPcraft' and it was written by Robert Wilensky, a Computer Science professor at Berkeley who teaches AI programming courses. The book starts at first principles and teaches Lisp programming, and then goes on to Franz-specific topics such as debugging, read macros, error handling, and compilation. Then there are chapters on Lisp applications: pattern matching and databases. Finally it contains a complete description of all Franz functions. details: LISPcraft, by Robert Wilensky 385 pages, $19.95 publisher: W. W. Norton, 500 5th Avenue, N.Y. N.Y. 10110 800-223-2584  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.21) id AA20583; Sat, 28 Jan 84 08:05:41 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.13) id AA28171; Sat, 28 Jan 84 08:03:56 pst Received: from ucbmike.ARPA by UCB-VAX.ARPA (4.22/4.21) id AA20518; Sat, 28 Jan 84 08:03:21 pst Date: Sat, 28 Jan 84 08:03:40 pst From: John Foderaro (on an h19-u) Message-Id: <8401281603.3747@ucbmike.ARPA> Received: by ucbmike.ARPA (4.17/3.5) id AA03747; Sat, 28 Jan 84 08:03:40 pst To: COLBY@SUMEX-AIM.ARPA Subject: Re: mailing list Cc: franz-friends@Berkeley In-Reply-To: Your message of Fri 27 Jan 84 17:37:18-PST I've removed you from franz-friends. note: requests to be added or deleted from this mailing list should go to franz-friends-request@berkeley, not franz-friends.  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.21) id AA13906; Sat, 28 Jan 84 02:19:33 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.13) id AA26588; Sat, 28 Jan 84 02:17:04 pst Received: from SUMEX-AIM.ARPA by UCB-VAX.ARPA (4.22/4.21) id AA03873; Fri, 27 Jan 84 17:35:34 pst Message-Id: <8401280135.AA03873@UCB-VAX.ARPA> Date: Fri 27 Jan 84 17:37:18-PST From: Kenneth Colby Subject: mailing list To: franz-friends@Berkeley How can I get off of the franz-friends mailing list? I assume dozens of people will receive my question. If anyone knows how to do it, please remove my name from the mailing list. Thank You -------  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.19) id AA06541; Thu, 26 Jan 84 22:01:14 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.13) id AA10074; Thu, 26 Jan 84 17:44:03 pst Received: from aids-unix (aids-unix.ARPA) by UCB-VAX.ARPA (4.22/4.19) id AA02121; Thu, 26 Jan 84 17:01:25 pst Message-Id: <8401270101.AA02121@UCB-VAX.ARPA> Date: 26 Jan 1984 16:25:55-PST From: Tod Levitt To: franz-friends@Berkeley Subject: report PAM 124, "Parlez vous Franz..." by James Larus Cc: levitt@aids-unix I am trying to obtain a copy of PAM report 124 which discusses interfacing foreign functions to Franzlisp. Can someone please point me at a source for this document? Thanks... Tod Levitt (levitt@aids-unix)  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.19) id AA02789; Thu, 19 Jan 84 10:00:32 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.13) id AA14836; Thu, 19 Jan 84 09:56:25 pst Received: from aerospace.ARPA by UCB-VAX.ARPA (4.22/4.19) id AA02684; Thu, 19 Jan 84 09:55:33 pst Message-Id: <8401191755.AA02684@UCB-VAX.ARPA> Date: Thu, 19 Jan 84 09:55:01 PST From: Ric Cowan To: franz-friends@Berkeley Subject: Help Hi, I'm starting a new project and would like to use Franz lisp. It is a large application that needs to: (1) Run on a VAX 11/780 under VMS. (2) Interface with INGRESS. (3) Support a menu driven interface with VT100 type terminals. Is Franz lisp a viable language to use? Thanks in advance, Ric Cowan  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.19) id AA22213; Sun, 15 Jan 84 15:02:00 pst Received: from ucbdali.ARPA by ucbkim.ARPA (4.16/4.13) id AA00458; Sun, 15 Jan 84 14:58:17 pst Received: by ucbdali.ARPA (4.22/4.18) id AA02865; Sun, 15 Jan 84 14:58:51 pst Date: Sun, 15 Jan 84 14:58:51 pst From: fateman%ucbdali@Berkeley (Richard Fateman) Message-Id: <8401152258.AA02865@ucbdali.ARPA> To: franz-friends%ucbdali@Berkeley Subject: FUGUE.3 FUGUE Notes An occasional publication of the Franz Lisp User Group under Unix and Eunice (FUGUE) Number 3 (January, 1984) edited by Richard J. Fateman University of California Berkeley CA 94720 USA fateman@berkeley _1. _W_e_l_c_o_m_e! It seems about time to publish the third of these newsletters, since we have accumulated a number of new items. We would also like to relay to others such informa- tion as has been forwarded to us. The reports of projects at Berkeley (and elsewhere) may strike sympathetic chords with other research. _2. _N_e_w _i_m_p_l_e_m_e_n_t_a_t_i_o_n_s Franz now runs on a number of Motorola 68000 and 68010 systems, including DUAL, PIXEL, Apple-LISA (UNIX), and undoubtedly a large number of other UNISOFT Inc. UNIX ports. (The LISA has only a 1 megabyte address space, and hence cannot run the compiler. It can load cross-compiled pro- grams.) Non-UNISOFT UNIX systems we have Franz running on include the 4.2BSD" Sun Microsystems operating system. Some work is beginning on high-speed VLSI chips for Lisp, using the reduced instruction set technology which has been successfully used at UCB in the past. More information on this will be available in the near future. _3. _N_e_w _p_r_o_g_r_a_m_s _3._1. _V_a_x_i_m_a _a_n_d _A_l_g_e_b_r_a_i_c _M_a_n_i_p_u_l_a_t_i_o_n Macsyma runs on the 68000 workstations with sufficient memory both virtual and real. At least 4 megabytes of vir- tual is needed, but benchmarks suggest that anything less than 2 megabytes of real memory is painful. We recommend 4 or more real megabytes. The PIXEL machine with 6 megabytes (unpaged) is our fastest real-time Macsyma system, (CPU-time is about 25% longer than reported VAX-780 CPU time, but more to the point, CPU-time is equal to real-time). Distribution ____________________ 9 UNIX, Eunice, Franz Lisp, may be trademarks of Bell Labs, SRI Int'l, and Univ. of Calif. 9 of 68000 Macsyma will presumably be done by Symbolics, (con- tact RP@mit-mc, with a cc to fateman@berkeley if you are interested). Development of a new algebra system and user applica- tion modules is proceeding, and a programming language called Newspeak, initially implemented on top of Franz, is the principal vehicle. This is described in John Foderaro's PhD dissertation, available from the CS Division at UCB. (Newspeak is hierarchical, object-oriented, and strongly typed; is compiler-based, and should provide efficient access to machine resources). While the algebra code is progressing well, we are not yet ready to set a release date for the user-end of the system, tentatively named Xi. _4. _N_e_w _f_e_a_t_u_r_e_s As usual, various performance enhancements and bug fixes have been incorporated in versions of Franz (now on Opus 38.87 and the compiler, Liszt 8.39) Most changes made it into the recent Berkeley 4.2BSD UNIX distribution, and reported alterations will not be repeated here. _5. _O_t_h_e_r _L_i_s_p_s We understand that a version of PSL will be supported by Hewlett Packard, on its workstations, and that Common Lisp, from DEC will have initial field-test in January, 1984. We believe PSL should be available from Utah in a form for running on 4.2BSD VAX UNIX; similarly for "T" from Cognitive Systems. We believe that a Common-Lisp support package for Franz may be constructed, but probably not at UC under current funding. (see Business news below, though). _6. _W_o_r_k _i_n _P_r_o_g_r_e_s_s _6._1. _G_r_a_p_h_i_c_s Gregg Foster has constructed a graphics Franz Lisp which includes the full Sun Microsystems Graphics package for Sun-2 systems, and Keith Sklower has constructed a C- structure package in Franz to enable programmers to more easily construct arbitrary C-structures in Lisp, to pass to C. Various demonstration programs have been written to access the smooth-curve plotting capabilities, variable-size fonts, etc. _6._2. _I_B_M _F_r_a_n_z Still more nibbles on this one, but not yet. We heard a rumor of work at Columbia University. (also see the next item.) 9 9 _7. _B_u_s_i_n_e_s_s _N_e_w_s _7._1. _F_r_a_n_z _I_n_c A new software company has been formed to support Franz and application programs, and is seeking customers in 3 categories: (a) manufacturers of hardware wishing to obtain a Lisp system and/or Lisp support; (b) software producers who wish to have reliable access to experts in Franz, for enhancement, support, training or porting of existing code. (c) end-users who are using Franz or applications written in Franz and need help in customizing, debugging, conversion to or from other dialects, etc. The University of California will continue to distri- bute Franz Lisp on its current basis, but your questions about support in any of these categories, or about future plans, can be directed to Franz Inc. Most of the principals at UC will be participating in this venture. Contact Franz Inc. via fkunze@berkeley, or (to avoid abuse of various net- work privileges), Fritz Kunze, President, Franz Inc., 6321 Thornhill Drive, Oakland, Ca 94611 (415) 339-1481. 9 9  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.19) id AA06716; Wed, 11 Jan 84 16:27:26 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.13) id AA06395; Wed, 11 Jan 84 12:58:53 pst Received: from nrl-aic (nrl-aic.ARPA) by UCB-VAX.ARPA (4.22/4.19) id AA03955; Wed, 11 Jan 84 12:58:55 pst Message-Id: <8401112058.AA03955@UCB-VAX.ARPA> Date: 11 Jan 1984 14:43-EST From: Dan Hoey Subject: Problems with arrays in Franz Apparently-To:  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.19) id AA04330; Wed, 11 Jan 84 13:19:55 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.13) id AA06529; Wed, 11 Jan 84 13:10:01 pst Received: from nrl-aic (nrl-aic.ARPA) by UCB-VAX.ARPA (4.22/4.19) id AA04150; Wed, 11 Jan 84 13:09:46 pst Message-Id: <8401112109.AA04150@UCB-VAX.ARPA> Date: 11 Jan 1984 14:43-EST From: Dan Hoey Subject: Problems with arrays in Franz To: FRANZ-FRIENDS@Berkeley Hard to believe but it was less than two and a half years ago that someone was having trouble using Franz arrays... Date: 17 Jul 1981 17:06:22-PDT From: CSVAX.jkf at Berkeley To: FININ@WHARTON-10 cc: franz-friends at MIT-MC Subject: Re: ... the maclisp-style array package. In-reply-to: Your message of 17 Jul 1981 1347-PDT (Friday). From: FININ@WHARTON-10 Subject: ... the maclisp-style array package. ... [3] We've been having problems with the MacLisp compatable array package - it doesn't work! Does anyone have a debugged version? Can you be more specific? We use it in Vax Macsyma without any problems. Personally I feel that Maclisp arrays were invented by a madman and no new code should be written using them. -- john foderaro Well, I used the Maclisp array package because I didn't want to waste time writing my own. Instead I spent hours looking for the bug in this code: -> (let ((factorial (*array () () 100.))) (store (factorial 0) 1) (do ((i 1 (1+ i))) ((= i 100.)) (store (factorial i) (times i (factorial (1- i))))) (factorial 10.)) 285656 To make a long story short, this lossage is because the second argument to *array being nil tells the garbage collector not to scan the array. The factorial of ten gets tossed in the bit bucket, where it unfortunately looks like a fixnum. To fix the example, change the first line of the example to -> (let ((factorial (*array () t 100.))) To save someone else from excruciatingly wrong answers, change the documentation in Section 2. (*array 's_name 's_type 'x_dim1 ... 'x_dimn) (array s_name s_type x_dim1 ... x_dimn) WHERE: s_type may be one of t, nil, fixnum, flonum, fixnum-block and flonum-block. ... < In FRANZ LISP arrays of type t, nil, fix- < num and flonum are equivalent and the elements of < these arrays can be any type of lisp object. --- > In FRANZ LISP arrays of type t, fixnum, > and flonum are equivalent and the elements of > these arrays can be any type of lisp object. > Type nil arrays may also contain any type of lisp > object, but they are not marked by the garbage > collector (see 9.2.2) and can lose data if used > incorrectly. Fixnum-block and flonum-block arrays are res- tricted to fixnums and flonums respectively and are used mainly to communicate with foreign func- tions (see 8.4). Dan  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.22/4.16) id AA07672; Sat, 3 Dec 83 22:48:10 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.13) id AA12594; Sat, 3 Dec 83 22:40:07 pst Received: from rand-relay.ARPA by UCB-VAX.ARPA (4.22/4.16) id AA06631; Sat, 3 Dec 83 21:43:27 pst Message-Id: <8312040543.AA06631@UCB-VAX.ARPA> Date: 3 Dec 1983 11:58:11-PST From: alfred.ct@Rand-Relay Return-Path: Subject: Deficiency in Franz GC To: franz-friends@Berkeley Via: ct; 3 Dec 83 12:46-PST This really isn't a bug so much as a deficiency in the code. We are running Opus 38.26 and recently had need to increase the constant TTSIZE (in config.h) above the default 10216. It turns out that this breaks the garbage collector which will fail to completely clear the array bitmapi if given a TTSIZE greater 10216 (during the clearing out of bit maps). The offending code is in Talloc.c (or alloc.c, depending on your Opus). The old code is: /* try the movc5 to clear the bit maps */ /* the maximum number of bytes we can clear in one sweep is * 2^16 (or 1<<16 in the C lingo) */ bytestoclear = ((((int)datalim)-((int)beginsweep)) >> 9) * 16; if(bytestoclear > MAXCLEAR) { blzero(((int) &bitmapi[((int)beginsweep>>7)]) + MAXCLEAR, bytestoclear - MAXCLEAR); bytestoclear = MAXCLEAR; } blzero((int)&bitmapi[((int)beginsweep)>>7],bytestoclear); and the fixed version that we have been running for several weeks now is: /* try the movc5 to clear the bit maps */ /* the maximum number of bytes we can clear in one sweep is * 2^16 (or 1<<16 in the C lingo) */ bytestoclear = ((((int)datalim)-((int)beginsweep)) >> 9) * 16; {int count = 0; while (bytestoclear > 0) { if(bytestoclear > MAXCLEAR) { blzero(((int) &bitmapi[((int)beginsweep>>7)])+count*MAXCLEAR, MAXCLEAR); ++count; } else blzero(((int)&bitmapi[((int)beginsweep)>>7]+count*MAXCLEAR), bytestoclear); bytestoclear -= MAXCLEAR; } } The old code is still present in Opus 38.56. Alfred Correira Paul Robertson ...ucbvax!nbires!ctvax!alfred (UUCP) alfred.ct@Rand-Relay (CSNET)  Received: from ucbkim.ARPA by UCB-VAX.ARPA (4.21/4.15) id AA06888; Tue, 22 Nov 83 17:23:27 pst Received: from UCB-VAX.ARPA (ucbvax.ARPA) by ucbkim.ARPA (4.16/4.13) id AA23508; Tue, 22 Nov 83 17:14:09 pst Received: from csnet-cic.ARPA by UCB-VAX.ARPA (4.21/4.15) id AA06655; Tue, 22 Nov 83 17:13:29 pst Message-Id: <8311230113.AA06655@UCB-VAX.ARPA> Date: 22 Nov 83 12:48:01 EST (Tue) From: Barry Perricone Return-Path: Subject: Franz for VMS To: franz-friends@Berkeley Via: UMCP-CS; 22 Nov 83 19:25-EST I need to know if anybody has a version of Franz for the Vax series under VMS which includes 'liszt'. Also one which when a 'dumplisp' is performed will output a file which can execute as a stand-alone (i.e., does not need to be "restored"). I would appreciate any information on this matter, and if one exists information on how I could obtain a copy of it. Thanks in advance, Barry P.  Received: from ucbkim.ARPA by ucbvax.ARPA (4.16/4.13) id AA03798; Fri, 4 Nov 83 19:58:47 pst Received: from ucbvax.ARPA by ucbkim.ARPA (4.16/4.13) id AA26540; Fri, 4 Nov 83 19:55:59 pst Received: from bbn-vax (bbn-vax.ARPA) by ucbvax.ARPA (4.16/4.13) id AA03738; Fri, 4 Nov 83 19:55:52 pst Message-Id: <8311050355.AA03738@ucbvax.ARPA> Date: Fri, 4 Nov 83 22:55 EST From: Ken Anderson Subject: Why no &keywords in local functions? To: franz-friends@Berkeley With liszt version 8.29 (Opus 38.66 of Franz) I get the following message: ?Error: save.l: save-install: local functions can't use &keyword's save-install When compiling the function (declared as a localf): (defun save-install (thing table &aux type handler) ; Install thing in hash table, and recursively install its parts. (cond ((memq (setq type (save-type thing)) '(symbol number))) ; Needn't install (t (cond ((zerop (save-count++ thing)) ; Increment access count, and install parts of thing if it ; is being installe (cond ((setq handler (get type 'save-install-parts)) (funcall handler thing table)) (t (ferror "Don't Know how to save ~S~%" thing)))))))) This used to work in earlier Opuses (like 38.44). Can you explain the change.  Received: from ucbkim.ARPA by ucbvax.ARPA (4.16/4.13) id AA01180; Tue, 1 Nov 83 06:54:03 pst Received: from ucbvax.ARPA by ucbkim.ARPA (4.16/4.13) id AA03145; Tue, 1 Nov 83 06:52:11 pst Received: from BRL-VOC (brl-voc.ARPA) by ucbvax.ARPA (4.16/4.13) id AA01150; Tue, 1 Nov 83 06:51:14 pst Message-Id: <8311011451.AA01150@ucbvax.ARPA> Date: Tue, 1 Nov 83 9:44:54 EST From: Paul Tanenbaum To: Ailist-requests@sri-ai, Franz-Friends@Berkeley Cc: pjt@brl-voc Subject: mailing list Please cons me onto your mailing list Thanks, paul  Received: from ucbkim.ARPA by ucbvax.ARPA (4.12/4.7) id AA00721; Fri, 14 Oct 83 09:49:53 PDT Received: by ucbkim.ARPA (4.6/4.2) id AA14694; Fri, 14 Oct 83 09:45:15 PDT Date: Fri, 14 Oct 83 09:45:15 PDT From: sklower%ucbkim@Berkeley (Keith Sklower) Message-Id: <8310141645.AA14694@ucbkim.ARPA> To: franz-friends%ucbkim@Berkeley Subject: eunice version of franz We have opus38.79 working on David Kashtan's machine. The source is integrated with the vax-unix and 68000 versions, all available by anonymous ftp, or as the regular tape distribution. I have had one report from a eunice user that the installation didn't get past construction the kernel, but it could be due to insufficient quota.  Received: from ucbkim.ARPA by ucbvax.ARPA (4.12/4.7) id AA00721; Fri, 14 Oct 83 09:49:53 PDT Received: by ucbkim.ARPA (4.6/4.2) id AA14694; Fri, 14 Oct 83 09:45:15 PDT Date: Fri, 14 Oct 83 09:45:15 PDT From: sklower%ucbkim@Berkeley (Keith Sklower) Message-Id: <8310141645.AA14694@ucbkim.ARPA> To: franz-friends%ucbkim@Berkeley Subject: eunice version of franz We have opus38.79 working on David Kashtan's machine. The source is integrated with the vax-unix and 68000 versions, all available by anonymous ftp, or as the regular tape distribution. I have had one report from a eunice user that the installation didn't get past construction the kernel, but it could be due to insufficient quota.  Received: from ucbkim.ARPA by ucbvax.ARPA (4.12/4.7) id AA00721; Fri, 14 Oct 83 09:49:53 PDT Received: by ucbkim.ARPA (4.6/4.2) id AA14694; Fri, 14 Oct 83 09:45:15 PDT Date: Fri, 14 Oct 83 09:45:15 PDT From: sklower%ucbkim@Berkeley (Keith Sklower) Message-Id: <8310141645.AA14694@ucbkim.ARPA> To: franz-friends%ucbkim@Berkeley Subject: eunice version of franz We have opus38.79 working on David Kashtan's machine. The source is integrated with the vax-unix and 68000 versions, all available by anonymous ftp, or as the regular tape distribution. I have had one report from a eunice user that the installation didn't get past construction the kernel, but it could be due to insufficient quota.  Received: from ucbkim.ARPA by ucbvax.ARPA (4.12/4.7) id AB00324; Fri, 14 Oct 83 09:31:39 PDT Received: from ucbvax.ARPA by ucbkim.ARPA (4.6/4.2) id AA14501; Fri, 14 Oct 83 09:27:56 PDT Received: from MIT-MC (mit-mc.ARPA) by ucbvax.ARPA (4.12/4.7) id AA00195; Fri, 14 Oct 83 09:26:15 PDT Message-Id: <8310141626.AA00195@ucbvax.ARPA> Date: 14 Oct 1983 12:22:28-EDT From: Andrew.Mendler@CMU-RI-ISL1 Subject: eunice version of franz Apparently-To: What is the most recent version of franz lisp that is available under eunice? In particular is opus38.55 available? Thanks in advance.  Received: from ucbkim.ARPA by ucbvax.ARPA (4.12/4.7) id AA08404; Thu, 29 Sep 83 18:38:00 PDT Received: by ucbkim.ARPA (4.6/4.2) id AA10806; Thu, 29 Sep 83 14:50:17 PDT Date: Thu, 29 Sep 83 14:50:17 PDT From: fateman%ucbkim@Berkeley (Richard Fateman) Message-Id: <8309292150.AA10806@ucbkim.ARPA> To: franz-friends%ucbkim@Berkeley Subject: survey Cc: fateman%ucbkim@Berkeley I am trying to collect some statistics on usage of Franz. I would like to get answers to these questions: (1) Your location: (2) The number of computers at your location (actively) running Franz: (3) Have you produced a locally modified manual? (y/n) (4) Are other Lisps in use there? (names?) (5) Do you use Franz for instruction? research? (6) Are you distributing or selling packages "on top of" Franz? (You may also send comments you wish; I will compile results and redistribute, so please do not respond to "franz-friends", but to me.) Thanks.  Received: from ucbkim.ARPA by ucbvax.ARPA (4.12/4.7) id AA10920; Mon, 26 Sep 83 19:46:39 PDT Received: from ucbvax.ARPA by ucbkim.ARPA (4.6/4.2) id AA24055; Mon, 26 Sep 83 19:41:37 PDT Received: from udel-relay.ARPA by ucbvax.ARPA (4.12/4.7) id AA07367; Mon, 26 Sep 83 16:28:58 PDT Message-Id: <8309262328.AA07367@ucbvax.ARPA> Date: 26 Sep 83 15:22:00 EDT (Mon) From: Liz Allen Return-Path: Subject: Maryland software distribution To: franz-friends@Berkeley Via: UMCP-CS; 26 Sep 83 17:46-EDT This is to announce the availability of the Univ of Maryland software distribution. This includes source code for the following: 1. The flavors package written in Franz Lisp. This package has been used successfully in a number of large systems at Maryland, and while it does not implement all the features of Lisp Machine Flavors, the features present are as close to the Lisp Machine version as possible within the constraints of Franz Lisp. (Note that Maryland flavors code *can* be compiled.) 2. Other Maryland Franz hacks including the INTERLISP-like top level, the lispbreak error handling package, the for macro and the new loader package. 3. The YAPS production system written in Franz Lisp. This is similar to OPS5 but more flexible in the kinds of lisp expressions that may appear as facts and patterns (sublists are allowed and flavor objects are treated atomically), the variety of tests that may appear in the left hand sides of rules and the kinds of actions may appear in the right hand sides of rules. In addition, YAPS allows multiple data bases which are flavor objects and may be sent messages such as "fact" and "goal". 4. The windows package in the form of a C loadable library. This flexible package allows convenient management of multiple contexts on the screen and runs on ordinary character display terminals as well as bit-mapped displays. Included is a Franz lisp interface to the window library, a window shell for executing shell processes in windows, and a menu package (also a C loadable library). You should be aware of the fact that the lisp software is based on Franz Opus 38.26 and that we will be switching to the newer version of lisp that comes with Berkeley 4.2 whenever that comes out. --------------------------------------------------------------------- To obtain the Univ of Maryland distribution tape: 1. Fill in the form below, make a hard copy of it and sign it. 2. Make out a check to University of Maryland Foundation for $100, mail it and the form to: Liz Allen Univ of Maryland Dept of Computer Science College Park MD 20742 3. If you need an invoice, send me mail, and I will get one to you. Don't forget to include your US Mail address. Upon receipt of the money, we will mail you a tape containing our software and the technical reports describing the software. We will also keep you informed of bug fixes via electronic mail. --------------------------------------------------------------------- The form to mail to us is: In exchange for the Maryland software tape, I certify to the following: a. I will not use any of the Maryland software distribution in a commercial product without obtaining permission from Maryland first. b. I will keep the Maryland copyright notices in the source code, and acknowledge the source of the software in any use I make of it. c. I will not redistribute this software to anyone without permission from Maryland first. d. I will keep Maryland informed of any bug fixes. e. I am the appropriate person at my site who can make guarantees a-d. Your signature, name, position, phone number, U.S. and electronic mail addresses. --------------------------------------------------------------------- If you have any questions, etc, send mail to me: -Liz Allen, U of Maryland, College Park MD Usenet: ...!seismo!umcp-cs!liz Arpanet: liz%umcp-cs@Udel-Relay  Received: from ucbkim.ARPA by ucbvax.ARPA (4.8/4.4) id AA06231; Tue, 30 Aug 83 21:52:04 PDT Received: from ucbvax.ARPA by ucbkim.ARPA (4.6/4.2) id AA29417; Tue, 30 Aug 83 21:58:38 PDT Received: from ucla-locus (ucla-locus.ARPA) by ucbvax.ARPA (4.8/4.4) id AA06203; Tue, 30 Aug 83 21:50:26 PDT Message-Id: <8308310450.AA06203@ucbvax.ARPA> Date: Tue, 30 Aug 83 21:44:13 PDT From: Dorab Patel To: franz-friends@Berkeley Subject: bug fix for 'insert' in opus 38.50 The function 'insert' in Opus 38.50 does not perform as advertised in the manual if the last argument is non-nil (i.e. if no duplicates are allowed. It still insists on putting the duplicate element into the list. The fix is in /usr/lib/lisp/common2.l. Just change the default setting of the 'comparefn' to that given below instead of (function alphalessp). Here is an excerpt from the modified file. [.....] (def insert (lambda (x l comparefn nodups) (cond ((null l) (list x)) ((atom l) (error "an atom, can't be inserted into" l)) (t (cond ((null comparefn) (setq comparefn (function (lambda (x y) (or (alphalessp x y) (equal x y))))))) (prog (l1 n n1 y) (setq l1 l) (setq n (length l)) a (setq n1 (/ (add1 n) 2)) (setq y (Cnth l1 n1)) [..........]  Received: from ucbkim.ARPA by UCBVAX.ARPA (3.347/3.35) id AA13559; Sat, 6 Aug 83 09:40:45 PDT Received: from UCBVAX.ARPA by ucbkim.ARPA (4.2/4.2) id AA21229; Sat, 6 Aug 83 09:49:57 PDT Received: by UCBVAX.ARPA (3.347/3.35) id AA13549; Sat, 6 Aug 83 09:40:11 PDT Message-Id: <8308061640.AA13549@UCBVAX.ARPA> From: ogcvax!metheus!tombl@Berkeley To: ogcvax!tektronix!ucbvax!franz-friends@Berkeley Cc: ogcvax!tektronix!ucbvax!sklower@Berkeley Received: from ogcvax.uucp by tektronix ; 5 Aug 83 20:51:03 PDT Subject: bug in Opus 38.66 Date: Fri Aug 5 20:46:56 1983 A bug present in previous versions is also present in 38.66 of Franz. cfasl fails (in most cases) to close the file it reads from. Consequently, mysterious events occur when the maximum number of open file descriptors is reached. The fix is made in the file ffasl.c. "close(fildes)" should be prepended to the two return sequences from (the Unix code for) Lcfasl: ------------------------------------------------------------------ Old: 146c146 < {Restorestack(); return(nil);} --- Fixed: > {close(fildes); Restorestack(); return(nil);} 149a150 > close(fildes); ------------------------------------------------------------------ Tom Blenko Metheus Corp. ucbvax!tektronix!ogcvax!metheus!tombl allegra!ogcvax!metheus!tombl  Received: from ucbkim.ARPA by UCBVAX.ARPA (3.347/3.35) id AA10467; Fri, 5 Aug 83 15:59:28 PDT Received: from UCBVAX.ARPA by ucbkim.ARPA (4.2/4.2) id AA10610; Fri, 5 Aug 83 15:57:17 PDT Received: from SU-AI.ARPA by UCBVAX.ARPA (3.347/3.35) id AA10357; Fri, 5 Aug 83 15:54:22 PDT Message-Id: <8308052254.AA10357@UCBVAX.ARPA> Date: 05 Aug 83 1353 PDT From: Fred Lakin Subject: Franz & SUNs To: franz-friends@Berkeley I am interested in connectons between Franz and SUN workstations. Like how far along is Franz on the SUN? Is there some package which allows Franz on a VAX to use a SUN as a display device? Any info on this matter would be appreciated. Thnaks, Fred Lakin  Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.347/3.35) id AA06941; Thu, 14 Jul 83 12:49:56 PDT Date: 14 Jul 1983 15:47:19 EDT (Thursday) From: Ken Anderson Subject: Random numbers Message-Id: <8307141948.AA06936@UCBVAX.ARPA> Received: from bbn-vax (bbn-vax.ARPA) by UCBVAX.ARPA (3.347/3.35) id AA06936; Thu, 14 Jul 83 12:48:49 PDT Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5) id AA15607; 14 Jul 83 12:49:58 PDT (Thu) To: franz-friends@Berkeley Cc: Malcolm.McRoberts@CMU-RI-ISL Here is a random number generator i use. It seems to work fairly well, but i have not looked to closely at the statistics. Since it will occasionally require bignums, it is probably not the fastest either. I was just looking for something that was likely to be portable between LISP's. I would be very interested in hearing your evaluation of it. k ;;; RANDOM NUMBERS (declare (macros t)) (include math.h) (defvar $uniform-a 16807) ; = 7^5 (defvar $mersenne-prime 2147483647) ; = 2^31 - 1 (defvar $mersenne-prime-1 (- $mersenne-prime 1)) (defmacro with-seed (s-newseed . body) ; evaluates body with the seed of the random numbers set to s-newseed. ; the value of s-newseed is updated. Thus this is a way of ; Keepining several sequences of random numbers with their own seeds `(let (($uniform-seed ,s-newseed)) (prog1 (progn ,@body) (setq ,s-newseed $uniform-seed)))) (defun uniform-basic (previous-fixnum) ; -> a fixnum 0 < fixnum < 2^31 - 1 ; Repeated calls will generate fixnums in the range ; 1 -> 2^31 - 2. ; The basic idea is new = A^k * old (mod p) ; where A is a primitive root of p, k is not a factor of p-1 ; and p is a large prime. ; This is a good random number generator but is not be the fastest! ; On FRANZ LISP, and LISP MACHINE it will require bignums since ; (* $uniform-a previous-fixnum) can have 46 bits in it. Also the remainder ; can be done more efficiently. ; See: Linus Schrage, A More Portable Fortran Random Number Generator, ; ACM Trans. Math. Soft., V5, No. 2, p 132-138, 1979. (remainder (*$ $uniform-a previous-fixnum) $mersenne-prime)) (defvar $uniform-seed 53) ; 0 < fixnum < $mersenne-prime-1 (defun uniform () ; -> the next uniform random number in the sequence ; To have your own sequence, rebind $uniform-seed. (setq $uniform-seed (uniform-basic $uniform-seed))) (defun uniform-between (low-num high-num) ; -> a uniform random number, x, low-num <= x <= high-num ; If low-num and high-num are fixnums, a fixnum is returned. (cond ((not (and (fixp low-num) (fixp high-num))) (+$ low-num (*$ (//$ (uniform) (float $mersenne-prime-1)) (-$ high-num low-num)))) (t (+ low-num (// (uniform) (// $mersenne-prime-1 (max 1 (- high-num low-num -1)))))))) (defun gaussian-random-1 () ; -> a gaussian random variable with mean 0.0 and ; standard deviation 1.0. ; Good tails. (*$ (sqrt (*$ -2.0 (log (uniform-between 0.0 1.0)))) (sin (*$ $2pi (uniform-between 0.0 1.0))))) (defun gaussian-random (mean standard-deviation) (+$ mean (*$ (gaussian-random-1) standard-deviation))) ;;(defun gaussian (x) ;; (* (sqrt $2pi) ;; (exp (minus (// (square x) 2.0))))) (defun random-yes-no (fraction-yes) (<= (uniform-between 0.0 1.0) fraction-yes))  Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.347/3.35) id AA05758; Thu, 14 Jul 83 11:08:12 PDT Date: 14 Jul 1983 14:03:01-EDT From: Malcolm.McRoberts@CMU-RI-ISL Subject: random numbers Message-Id: <8307141806.AA05735@UCBVAX.ARPA> Received: from MIT-MC (mit-mc.ARPA) by UCBVAX.ARPA (3.347/3.35) id AA05735; Thu, 14 Jul 83 11:06:45 PDT Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5) id AA13687; 14 Jul 83 11:07:57 PDT (Thu) Apparently-To: I am interested in obtaining a GOOD random number generator that is callable from Franz. My only real requirements are that it accept a seed (so that I can duplicate the same series), is fairly good (try doing several (random 4)'s in Franz and see what you get), and is of intermediate speed. If you know of such an animal please send me mail telling me how to get it. thanks  Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.346/3.33) id AA10380; 13 Jul 83 00:55:57 PDT (Wed) Date: 13 Jul 83 03:09:39 EDT (Wed) From: Liz Allen Subject: Re: Franz flavors? Return-Path: Message-Id: <8307130754.AA10367@UCBVAX.ARPA> Received: from udel-relay.ARPA by UCBVAX.ARPA (3.346/3.33) id AA10367; 13 Jul 83 00:54:32 PDT (Wed) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5) id AA24477; 13 Jul 83 00:55:26 PDT (Wed) To: pwh.gatech@UDel-Relay, franz-friends@Berkeley Cc: jlk.Gatech@UDel-Relay Via: UMCP-CS; 13 Jul 83 3:23-EDT Here at the Univ of Maryland, we do have an implementation of flavors in Franz Lisp and have used it successfully in several large systems. It doesn't contain all the features of the Lisp Machine Flavors, but it does implement all the major ones. It is also different in a few ways that are necessitated by the limitations of Franz Lisp (shallow binding without invisible pointers or true closures -- though closures may be in the very newest versions of Franz -- we have opus 38.26). The package uses a hashing scheme for looking up methods, and the function <- which is used to send a message to an object is written in C. Together, this makes it an efficient implementation. We are currently working on a new policy for distributing flavors, our other lisp packages and our window package. When we have worked it out, I will announce the details here. -Liz  Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.346/3.33) id AA05936; 12 Jul 83 20:10:42 PDT (Tue) Date: Tuesday, 12 Jul 1983 19:49-PDT From: narain@rand-unix Subject: Re: Franz flavors? Message-Id: <8307130309.AA05908@UCBVAX.ARPA> Received: from rand-unix (rand-unix.ARPA) by UCBVAX.ARPA (3.346/3.33) id AA05908; 12 Jul 83 20:09:41 PDT (Tue) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5) id AA21387; 12 Jul 83 20:10:42 PDT (Tue) To: Cc: franz-friends@Berkeley, jlk.Gatech@UDEL-RELAY In-Reply-To: Your message of 11 Jul 83 20:36:32-EDT (Mon). <8307130107.AA03336@UCBVAX.ARPA> We at Rand are interested in developing a set of guidelines for writing code that will be compatible with each of Zeta- Franz- and PSL Lisps. I would be grateful if you could tell us of what your experiences have been with making Franzlisp code work on the Symbolics machine. We would gladly share our own with you if you wish; incidentally we also have an IJCAI paper on a related issue. -- Sanjai Narain  Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.346/3.33) id AA03396; 12 Jul 83 18:10:41 PDT (Tue) Date: 11 Jul 83 20:36:32-EDT (Mon) From: Subject: Franz flavors? Return-Path: Message-Id: <8307130107.AA03336@UCBVAX.ARPA> Received: from udel-relay.ARPA by UCBVAX.ARPA (3.346/3.33) id AA03336; 12 Jul 83 18:07:40 PDT (Tue) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5) id AA20140; 12 Jul 83 18:08:46 PDT (Tue) To: franz-friends@Berkeley Cc: jlk.Gatech@UDel-Relay Via: GATech; 12 Jul 83 2:43-EDT We at Ga Tech (ai group working under prof Janet Kolodner) have just gotten our long awaited Symbolics Lisp Machine up and running and are trying to establish some measure of compatability between Franz and Zeta Lisp (as appropriate). Janet seems to recall some mention of a flavor package for Franz. Is this Berkley based or can anyone provide some clues as to where to check next? Also, when is the next release of Franz scheduled and what features will it incorporate? If the flavor package is non-existent, we will probably be forced to develop one here and will, of course, be glad to pass anything useful along. phil hutto  Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.346/3.33) id AA16301; 8 Jul 83 01:46:21 PDT (Fri) Date: Thu, 7 Jul 83 22:13 EDT From: Ira Winston Subject: Eliza Return-Path: Message-Id: <8307080845.AA16294@UCBVAX.ARPA> Received: from udel-relay.ARPA by UCBVAX.ARPA (3.346/3.33) id AA16294; 8 Jul 83 01:45:43 PDT (Fri) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5) id AA01687; 8 Jul 83 01:46:25 PDT (Fri) To: franz-friends@Berkeley Via: UPenn; 8 Jul 83 3:07-EDT Does anyone have a version of Eliza that runs under Franz Lisp?  Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.346/3.33) id AA13769; 21 Jun 83 15:37:46 PDT (Tue) Date: Tue, 21 Jun 83 10:33 EDT From: Tim Finin Subject: interrupting Franz Return-Path: Message-Id: <8306212152.AA12930@UCBVAX.ARPA> Received: from udel-relay.ARPA by UCBVAX.ARPA (3.346/3.33) id AA12930; 21 Jun 83 14:52:36 PDT (Tue) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5) id AA21097; 21 Jun 83 14:52:53 PDT (Tue) To: franz-friends@Berkeley Via: UPenn; 21 Jun 83 17:40-EDT Under VMS, one should type a ^C (control-C) rather than DEL to interrupt Franz.  Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.346/3.33) id AA00297; 20 Jun 83 22:10:13 PDT (Mon) Date: Monday, 20 Jun 1983 22:00-PDT From: narain@rand-unix Subject: Re: Interrrupt question Message-Id: <8306210509.AA00276@UCBVAX.ARPA> Received: from rand-unix (rand-unix.ARPA) by UCBVAX.ARPA (3.346/3.33) id AA00276; 20 Jun 83 22:09:20 PDT (Mon) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5) id AA09633; 20 Jun 83 22:09:31 PDT (Mon) To: franz-friends@Berkeley Cc: narain@rand-unix TWIMC ----- Here is the equivalent of Interlisp's control-H followed by OK in Franzlisp: i.e. if you wish to interrupt a Franzlisp computation, browse around the state and resume computation: Hit DEL; Browse; (return t) This answer was given by Liz Allen at Maryland (liz.umcp-cs@udel-relay). -- Sanjai  Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.346/3.33) id AA25503; 16 Jun 83 09:47:33 PDT (Thu) Date: 16 Jun 1983 1243-EDT From: Travis Lee Winfrey Subject: Porting Franz lisp to Amdahl Unix Message-Id: <8306161646.AA25470@UCBVAX.ARPA> Received: from CMU-CS-C (cmu-cs-c.ARPA) by UCBVAX.ARPA (3.346/3.33) id AA25470; 16 Jun 83 09:46:15 PDT (Thu) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5) id AA06352; 16 Jun 83 09:47:39 PDT (Thu) To: sklower%berkeley@CMCSC, kim.layer%berkeley@CMCSC Cc: franz-friends%berkeley@CMCSC, ui.tyj@CU20D, Ui.Travis@CU20D, kim.fateman%berkeley@CMCSC Hi, Tai Jin and I are currently attemping to bring up Franz lisp on Amdahl's Unix running on a IBM 4341. We are working from a copy that runs on the VAX. We would be very interested in seeing any versions that runs both on the VAX and some other machine, such as the 68000. We are also interested in seeing any documentation on other porting efforts, regardless of what machine. Thanks, Tai Jin Travis Winfrey -------  Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.346/3.33) id AA10027; 15 Jun 83 18:42:48 PDT (Wed) Date: 14 Jun 1983 1812-EDT From: Tai Jin Subject: franz mailing liszt Message-Id: <8306142214.AA16599@UCBVAX.ARPA> Received: from CMU-CS-C (cmu-cs-c.ARPA) by UCBVAX.ARPA (3.346/3.33) id AA16599; 14 Jun 83 15:14:36 PDT (Tue) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5) id AA28806; 15 Jun 83 18:22:55 PDT (Wed) To: franz-friends%berkeley@CMCSC Cc: ui.travis%cu20d@CMCSC, ui.tyj%cu20d@CMCSC Hi, we would like to be added to your mailing list. We are currently attempting to install FRANZ Lisp on Amdahl's Unix (UTS) running under VM/CMS on an IBM 4341 here at CUCCA (Columbia University Center for Computing Activities). Is anyone out there working on an UTS/IBM implementation? Any information will be greatly appreciated. Thanks, Tai Jin Travis Winfrey -------  Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.346/3.33) id AA13792; 14 Jun 83 11:48:57 PDT (Tue) Date: 14 Jun 83 11:48:32 PDT (Tue) From: fateman%UCBKIM@Berkeley (Richard Fateman) Subject: "macsyma on a chip?" Message-Id: <8306141848.6756@UCBKIM.ARPA> Received: by UCBKIM.ARPA (3.340/3.5) id AA06756; 14 Jun 83 11:48:32 PDT (Tue) To: macsyma-i@mit-mc Cc: franz-friends%UCBKIM@Berkeley Well, sort of. We now have Macsyma running on a Motorola 68000 - based system with 6 megabytes of real memory. The operating system is a Unisoft UNIX system, which has been ported to some large number (>65) boxes. The Pixel people were kind enough to lend us a machine with enough real memory to make virtual memory unnecessary. It takes a long time to load up, but once running, it is quite responsive, and appears to be about 60% of a VAX 11/780 in terms of CPU time. We have not shaken down everything, but since the source code is unchanged from the VAX, we expect the bugs to be limited to lisp compilation glitches, or differences between versions of the UNIX system.  Date: 31 May 83 17:28:35 PDT (Tue) From: lbl-csam!ssc-vax!steve@Berkeley Subject: packages Message-Id: <8306010028.AA16451@LBL-CSAM.ARPA> Received: by LBL-CSAM.ARPA (3.320/3.21) id AA16451; 31 May 83 17:28:35 PDT (Tue) Received: by UCBVAX.ARPA (3.341/3.31) id AA02877; 31 May 83 19:30:00 PDT (Tue) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5) id AA22745; 31 May 83 19:31:04 PDT (Tue) Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.341/3.31) id AA02892; 31 May 83 19:31:17 PDT (Tue) To: lbl-csam!franz-friends@Berkeley Does a version of LispMachine ``packages'' or some similar oblist partitioning scheme exist for franz? Having just integrated several independently coded modules, I think something like that would be very useful. -thanks Steve White, BAC, {uw-beaver,lbl-csam}!ssc-vax!steve  Date: Tuesday, 31 May 1983 10:45-PDT From: narain@rand-unix Subject: Interrupt question Message-Id: <8305311747.AA10893@UCBVAX.ARPA> Received: from rand-unix (rand-unix.ARPA) by UCBVAX.ARPA (3.341/3.29) id AA10893; 31 May 83 10:47:26 PDT (Tue) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5) id AA13428; 31 May 83 10:49:00 PDT (Tue) Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.341/3.29) id AA10905; 31 May 83 10:48:37 PDT (Tue) To: franz-friends@Berkeley Cc: narain@rand-unix Hi, I would be grateful if you could tell me what is the equivalent of Interlisp's control-h (followed by OK) in Franzlisp. In other words, I wish to interrupt a Franzlisp program, from time to time, examine its state and allow it to continue from the interrupted point. -- Sanjai  Date: Fri, 27 May 83 18:18:47 CDT From: Mike.Caplinger Subject: Re: Franz on the Sun Return-Path: Message-Id: <1983.05.27.18.18.47.150.08942@dione.rice> Received: from rand-relay.ARPA by UCBVAX.ARPA (3.341/3.29) id AA19088; 27 May 83 19:50:15 PDT (Fri) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5) id AA02221; 27 May 83 19:51:33 PDT (Fri) Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.341/3.29) id AA19103; 27 May 83 19:51:37 PDT (Fri) To: franz-friends@Berkeley In-Reply-To: baden%UCBKIM's message of 25 May 83 13:32:01 PDT (Wed) Via: Rice; 27 May 83 19:14-PDT As I type I'm bringing up the 68K version of Opus 38 (now FTPable from UCB-VAX) on a SUN running 4.1c. There don't seem to be any major problems so far, but the compiler doesn't run on a system with all the net servers on it because it runs out of memory. I've been told this is because there's a bug in 4.1c that forces it to only use 1/2 of the swap partition. I'm having to run standalone to compile the compiler; I don't yet know whether I'll be able to compile other stuff without this rather extreme fix. As I use the system more I will post more info to this group.  Date: 25 May 83 14:23:57 PDT (Wed) From: jkf%UCBKIM@Berkeley (John Foderaro) Subject: test Message-Id: <8305252123.3367@UCBKIM.ARPA> Received: by UCBKIM.ARPA (3.340/3.5) id AA03367; 25 May 83 14:23:57 PDT (Wed) Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.341/3.29) id AA04753; 25 May 83 14:49:26 PDT (Wed) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5) id AA03741; 25 May 83 14:50:16 PDT (Wed) Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.341/3.29) id AA04772; 25 May 83 14:50:09 PDT (Wed) To: franz-friends@Berkeley This is a test of the mailing list. There is no need to respond.  Date: 25 May 83 13:32:01 PDT (Wed) From: baden%UCBKIM@Berkeley (Scott B. Baden) Subject: Re: Franz on the Sun Message-Id: <8305252032.2716@UCBKIM.ARPA> Received: by UCBKIM.ARPA (3.340/3.5) id AA02716; 25 May 83 13:32:01 PDT (Wed) Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.341/3.29) id AA03753; 25 May 83 13:50:52 PDT (Wed) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5) id AA03002; 25 May 83 13:51:39 PDT (Wed) Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.341/3.29) id AA03791; 25 May 83 13:51:51 PDT (Wed) To: franz-friends@Berkeley Cc: cornwell@NRL-CSS Which sun are you using? My office mate says that he has seen a sun configured with 2MB of memory AND an Ethernet board.  Date: 25 May 83 16:05:54 PDT (Wed) From: jkf%UCBKIM@Berkeley (John Foderaro) Subject: second test message (ignore this too) Message-Id: <8305252305.5294@UCBKIM.ARPA> Received: by UCBKIM.ARPA (3.340/3.5) id AA05294; 25 May 83 16:05:54 PDT (Wed) Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.341/3.29) id AA05951; 25 May 83 16:05:43 PDT (Wed) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5) id AA05331; 25 May 83 16:06:47 PDT (Wed) Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.341/3.29) id AA05982; 25 May 83 16:07:38 PDT (Wed) To: franz-friends@Berkeley Just ignore this.  Date: 20 May 1983 14:57:55-PDT From: mbr@NPRDC Subject: lam9.c and curses Message-Id: <8305211434.AA16172@UCBVAX.ARPA> Received: from nprdc (nprdc.ARPA) by UCBVAX.ARPA (3.341/3.29) id AA16172; 21 May 83 07:34:43 PDT (Sat) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.340/3.5) id AA08856; 21 May 83 07:37:23 PDT (Sat) Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.341/3.29) id AA16888; 21 May 83 08:23:31 PDT (Sat) Reply-To: mbr To: franz-friends@Berkeley Cc: mbr@NPRDC When we attempted to cfasl a file that used the curses package of screen control routines into Franz 38.40, we got the message _ospeed: /usr/libcurses.a (cr_tty.o) multiply defined. The apparent cause of this cryptic remark is that in lam9.c there is an extern variable ospeed. There are a number of tantalizing routines in this source file dealing with termcaps that are apparently not called by anyone. Are there plans for these routines? Does anyone use them (heaven forbid they should be documented!). Our current fix is to just change ospeed to ospiid which so far has had no dire effects, but I am interested in others experience. The curses stuff seems to work fine after this modification. Mark Rosenstein  Date: 11 Apr 83 06:42:43 PST (Mon) From: jkf%UCBKIM@Berkeley (John Foderaro) Subject: mail to this mailing list Message-Id: <8304111442.11378@UCBKIM.ARPA> Received: by UCBKIM.ARPA (3.310/3.5) id AA11378; 11 Apr 83 06:42:43 PST (Mon) Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.332/3.21) id AA07288; 11 Apr 83 08:05:32 PST (Mon) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5) id AA11949; 11 Apr 83 08:07:39 PST (Mon) Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.332/3.21) id AA07315; 11 Apr 83 08:06:38 PST (Mon) To: franz-friends@Berkeley I'm sorry that people who mail to this mailing list must put up with lots of mail errors from our local mailer. The problem is not that we have a lot of illegal addresses, but that over the three day period that the mailer tries to deliver the mail, some of the destination sites never respond. I think that this is due primarily to the fact that many sites are running new mail and networking software. Hopefully this will improve over time. john foderaro  Date: 10 Apr 83 19:50:59 PST (Sun) From: fateman%UCBKIM@Berkeley (Richard Fateman) Subject: Re: Franz/Common lisp Message-Id: <8304110350.6176@UCBKIM.ARPA> Received: by UCBKIM.ARPA (3.310/3.5) id AA06176; 10 Apr 83 19:50:59 PST (Sun) Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.332/3.21) id AA10019; 10 Apr 83 19:49:55 PST (Sun) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5) id AA06192; 10 Apr 83 19:52:14 PST (Sun) Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.332/3.21) id AA10034; 10 Apr 83 19:50:48 PST (Sun) To: carr@utah-20, fahlman@cmu-cs-c Cc: franz-friends@Berkeley I think that a common-lisp-compatibility package written in Franz would not be as difficult as all that. If Common Lisp (TM of DEC?) were available on all the same machines at the same price, (appx. $0.) and CL were in fact a superset of Franz for all practical purposes, and with similar or better efficiency, etc. Why would anyone bother? Of course if CL does not meet all of the objectives (e.g. price, machines), then a CL-to-Franz "translator" might make sense. With that in mind, I would like to officially request a copy of the Common Lisp language (as implemented in CL, presumably), as soon as it becomes available (i.e. no later than when it is a "product" of DEC, and probably at "beta" test time). I agree fully with Scott that trying to do this with an incomplete language specification is unwise. I am also not making any commitment to do anything with CL at Berkeley, but since we are building tools for our own applications, and CL might be useful, we might consider an efficient merge of ideas.  Date: Thu, 7 Apr 1983 10:46 EST From: Scott E. Fahlman Subject: Franz/Common lisp Message-Id: <8304071549.AA13873@UCBVAX.ARPA> Received: ID ; 7 Apr 83 10:46:59 EST Received: from CMU-CS-C (cmu-cs-c.ARPA) by UCBVAX.ARPA (3.332/3.20) id AA13873; 7 Apr 83 07:49:42 PST (Thu) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5) id AA18082; 7 Apr 83 07:50:06 PST (Thu) Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.332/3.20) id AA13882; 7 Apr 83 07:50:13 PST (Thu) To: Harold Carr Cc: franz-friends@Berkeley In-Reply-To: Msg of 4 Apr 1983 11:22-EST from Harold Carr Harold, A couple of things make it seem unlikely that anyone would have such a package right now. First, we don't even have a final Common Lisp manual yet -- Guy's next draft is due very soon, but there will be some tuning and hassling after that. Second, there are things in Common Lisp that would be very tough to fake on Franz: lexical binding, generic sequences, some of the hairy number types, character objects, etc. Common Lisp is pretty close to being a superset of Franz, so I would expect to see Franz compatibility packages in Common Lisp, but not vice versa. Third, if anyone were writing such a package, they would be crazy not to have arranged for access to our code that implements all of the hairy functions, and nobody has done this to my knowledge. My standard advice is for people to continue to code in Franz with the knowledge that they can easily convert their code to Common Lisp whenever the DEC Common Lisp is available to them. This should be a one-time conversion, since moving the other way after "going native" in Common Lisp would be very tough. If someone does pop up with a compatibility package -- even a partial one -- I would be interested in hearing about it. -- Scott  Date: 4 Apr 1983 11:06:49 PST (Monday) From: Jeff Dean Subject: knowledge representation language Message-Id: <8304052042.AA26557@UCBVAX.ARPA> Received: from aids-unix (aids-unix.ARPA) by UCBVAX.ARPA (3.332/3.20) id AA26557; 5 Apr 83 12:42:11 PST (Tue) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5) id AA16443; 5 Apr 83 12:42:46 PST (Tue) Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.332/3.20) id AA26606; 5 Apr 83 12:45:51 PST (Tue) To: franz-friends@Berkeley Does anyone have a knowledge representation language (such as FRL or KL-ONE) available under Franz Lisp? Jeff Dean arpa: jeff@aids-unix uucp: ...ucbvax!jeff@aids-unix  Date: 4 Apr 1983 0922-MST From: Harold Carr Subject: Franz/Common lisp Message-Id: <8304041711.AA07020@UCBVAX.ARPA> Received: from UTAH-20 (utah-20.ARPA) by UCBVAX.ARPA (3.332/3.20) id AA07020; 4 Apr 83 09:11:40 PST (Mon) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5) id AA01683; 4 Apr 83 14:53:09 PST (Mon) Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.332/3.20) id AA09437; 4 Apr 83 17:34:06 PST (Mon) To: franz-friends@Berkeley Cc: KROHNFELDT@UTAH-20 Does anyone have any sort of Common Lisp compatibility package for Franz? If so, how can I obtain it? Thanks in advance. Harold Carr (CARR@UTAH-20). -------  Date: 26 Mar 83 08:46:28 PST (Sat) From: UCBKIM.jkf@Berkeley (John Foderaro) Subject: Re: open coding of (function (lambda ...)) Message-Id: <8303261646.2453@UCBKIM.ARPA> Received: by UCBKIM.ARPA (3.310/3.5) id AA02453; 26 Mar 83 08:46:28 PST (Sat) Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.331/3.17) id AA05012; 26 Mar 83 08:42:50 PST (Sat) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5) id AA02462; 26 Mar 83 08:46:44 PST (Sat) Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.331/3.17) id AA05022; 26 Mar 83 08:43:17 PST (Sat) To: tim.unc@UDel-Relay Cc: franz-friends@Berkeley In-Reply-To: Your message of 25 Mar 83 15:03:29 EST (Fri) Liszt only compiles functions, not literals it finds in files. To make this statement be compiled: (setq appsum (function (lambda (x) (apply 'sum x)))) you should surround it with a function defintion: (defun junk () (setq appsum (function (lambda (x) (apply 'sum x)))))  Date: 25 Mar 83 15:03:29 EST (Fri) From: Tim Maroney Subject: open coding of (function (lambda ...)) Return-Path: Message-Id: <8303261137.AB02371@UCBVAX.ARPA> Received: from udel-relay.ARPA by UCBVAX.ARPA (3.331/3.17) id AB02371; 26 Mar 83 03:37:13 PST (Sat) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5) id AA00854; 26 Mar 83 03:41:05 PST (Sat) Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.331/3.17) id AA02378; 26 Mar 83 03:37:41 PST (Sat) To: franz-friends@Berkeley Via: UNC; 25 Mar 83 19:43-EST This doesn't seem to work. I'm using Liszt version 8.10, University of Maryland distribution. The documentation in the file "lispnews" is sketchy, but it seems that compiling and loading the file: (setq appsum (function (lambda (x) (apply 'sum x)))) should leave a bcd object in appsum's value, but it doesn't. It leaves the uncompiled lambda. Am I doing something wrong? Tim Maroney decvax!duke!unc!tim tim.unc@udel-relay  Date: 8 Mar 1983 2:32-EST From: Susan Pintzuk Subject: lisp statistical packages Return-Path: Message-Id: <8303081401.AA13004@UCBVAX.ARPA> Received: from udel-relay.ARPA by UCBVAX.ARPA (3.322/3.14) id AA13004; 8 Mar 83 06:01:54 PST (Tue) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5) id AA08297; 8 Mar 83 06:04:10 PST (Tue) Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.322/3.14) id AA13016; 8 Mar 83 06:02:35 PST (Tue) To: franz-friends@Berkeley Via: UPenn; 8 Mar 83 3:49-EST do any franz-lisp packages exist which calculate mean, standard deviation, %n within mean +/- 1 (or 2 or 3) standard deviation(s), etc.? if so, how do i obtain a copy?  Date: 25 Feb 83 08:28:45 PST (Fri) From: UCBKIM.jkf@Berkeley (John Foderaro) Subject: research position at edinburgh Message-Id: <8302251628.528@UCBKIM.ARPA> Received: by UCBKIM.ARPA (3.310/3.5) id AA00528; 25 Feb 83 08:28:45 PST (Fri) Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.314/3.5) id AA00867; 25 Feb 83 08:18:48 PST (Fri) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5) id AA00537; 25 Feb 83 08:29:01 PST (Fri) Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.314/3.5) id AA00874; 25 Feb 83 08:19:20 PST (Fri) To: franz-friends@BERKELEY DEPARTMENT OF ARTIFICIAL INTELLIGENCE UNIVERSITY OF EDINBURGH RESEARCH FELLOW A Research Fellowship is available within the Programming Systems Development Group. The post has been created specifically to provide a modern LISP system for the Perq computer running under ICL MicroCode UNIX, and is funded by the Science and Engineering Research Council. Experience in implementing systems would be advantageous, as would be a knowledge of LISP and C. Access will be available to an SERC DECsystem-10 running TOPS-10 and to a University VAX 750 running Berkeley UNIX, as well as to Perqs. The appointment will be made on the salary range 1B/1A, 5550 - 10670 pounds sterling, according to age and experience. The post is funded for a period of two years from the date of appointment. Further particulars of the post can be obtained from: Administrative Assistant Department of Artificial Intelligence University of Edinburgh Forrest Hill Edinburgh EH1 2QL SCOTLAND phone 031-667-1011 x2554 or by contacting RAE%EDXA%UCL-CS@ISID (Networks permitting) Applications should be made by March 17th, 1983.  Date: 21 Feb 83 09:19:43 PST (Mon) From: UCBKIM.jkf@Berkeley (John Foderaro) Subject: Re: global nonspecial variables Message-Id: <8302211719.2798@UCBKIM.ARPA> Received: by UCBKIM.ARPA (3.310/3.5) id AA02798; 21 Feb 83 09:19:43 PST (Mon) Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.314/3.5) id AA13982; 21 Feb 83 09:11:52 PST (Mon) Received: from UCBVAX.ARPA by UCBKIM.ARPA (3.310/3.5) id AA02805; 21 Feb 83 09:19:56 PST (Mon) Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.314/3.5) id AA13999; 21 Feb 83 09:12:26 PST (Mon) To: Mac.uvacs@UDel-Relay, FRANZ-FRIENDS@BERKELEY In-Reply-To: Your message of 18 Feb 83 12:42:40-EST (Fri) I don't understand the distinction between what you call a global variable and a special variable. A special variable in Franz Lisp (and any other shallow bound lisp) can be accessed rapidly and is only rebound if you put it in a lambda, prog or do variable list.  Date: 18 Feb 83 12:42:40-EST (Fri) From: Mac.uvacs@UDel-Relay Subject: global nonspecial variables Return-Path: Message-Id: <8302190504.26020@UCBVAX.ARPA> Received: from udel-relay.ARPA by UCBVAX.ARPA (3.312/3.5) id AA26020; 18 Feb 83 21:04:31 PST (Fri) Received: by UCBKIM.ARPA (3.310/3.5) id AA00656; 21 Feb 83 01:59:26 PST (Mon) Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.314/3.5) id AA08024; 21 Feb 83 01:51:43 PST (Mon) To: FRANZ-FRIENDS@BERKELEY Via: Virginia; 18 Feb 83 23:58-EST Does the Liszt compiler have any notion of global variables -- free variables with fast access, without any rebinding? I think the MACLISP compiler has something like this for variables beginning "**". Alex Colvin uucp: ...decvax!duke!mcnc!ncsu!uvacs!mac csnet:mac@virginia arpa: mac.uvacs@udel-relay  Date: 13 February 1983 0034-EST (Sunday) From: Mark.Sherman@CMU-CS-A Subject: Space and Leakage Message-Id: <13Feb83 003422 MS40@CMU-CS-A> Received: from CMU-CS-A by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83]) id AA07842; 12 Feb 83 21:38:46 PST (Sat) Received: by UCBKIM.ARPA (3.310/3.3) id AA02341; 14 Feb 83 16:21:29 PST (Mon) Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.310/3.3) id AA14365; 14 Feb 83 16:20:48 PST (Mon) To: franz-friends@UCB-VAX Can someone tell me how the maximum amount of storage that franz lisp uses is decided? I can force the size up to (about) 3050 pages (according to "ps") and then get the message "storage exhausted". I have been told (and have seen) other jobs get substantially more space; can franz get more pages as well? (I am using the cshell and have already used the limit command to raise my process size up to 32 megabytes, or so I think.) I have also been told that the garbage collector leaks, that is, not all of the garbage is really collected. Does anyone have good ideas about how much (or fast) this happens, or if there is some way to minimize the lost space? (Please send responses directly to me as I am not on this list.) -Mark Sherman (Sherman@CMU-CS-A)  Date: 13 Feb 83 14:34:48 EST (Sun) From: Tim Maroney Subject: cfasl: no namelist Return-Path: Message-Id: <8302141052.25792@UCBVAX.ARPA> Received: from udel-relay.ARPA by UCBVAX.ARPA (3.310/3.3) id AA25792; 14 Feb 83 02:52:18 PST (Mon) Received: by UCBKIM.ARPA (3.310/3.3) id AA02234; 14 Feb 83 16:18:42 PST (Mon) Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.310/3.3) id AA14268; 14 Feb 83 16:17:17 PST (Mon) To: franz-friends@BERKELEY Via: UNC; 14 Feb 83 5:43-EST I don't seem to be able to write Jed Krohnfeldt, and this answer is probably of general interest anyway. The message "ld: no namelist" means that some well-meaning system admin has stripped the lisp executable file to save space; unfortunately, this makes the dynamic loading used by cfasl impossible. Lisp will have to be recompiled (groan). No Franz Lisp executable file should EVER be stripped. Tim Maroney tim.unc@udel-relay decvax!duke!unc!tim  Date: 14 Feb 1983 10:24:21-EST From: Andrew.Mendler@CMU-RI-ISL Subject: franz lisp under5 vms 3.0 Message-Id: <8302141531.27879@UCBVAX.ARPA> Received: from CMU-RI-ISL by UCBVAX.ARPA (3.310/3.3) id AA27879; 14 Feb 83 07:31:54 PST (Mon) Received: by UCBKIM.ARPA (3.310/3.3) id AA01172; 14 Feb 83 15:50:41 PST (Mon) Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.310/3.3) id AA13503; 14 Feb 83 15:53:29 PST (Mon) To: franz-friends@BERKELEY Does anyone have a copy of Franz Lisp and the compiler that works under VMS version 3.0?  Date: 11 Feb 1983 1601-MST From: Jed Krohnfeldt Subject: cfasl Message-Id: <8301112302.7475@UCBVAX.BERKELEY.ARPA> Received: from UTAH-20 by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83]) id AA07475; 11 Feb 83 15:02:05 PST (Fri) Received: by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83]) id AA07526; 11 Feb 83 15:04:51 PST (Fri) To: UCBVAX.Franz-friends@Berkeley I am having trouble using cfasl in franz 38.04. I keep getting the message "ld: /usr/ucb/lisp : no namelist". Can anyone decipher this for me? Thanks... -------  Date: 2 Feb 1983 1414-MST From: Jed Krohnfeldt Subject: mailing list Message-Id: <8301030033.5587@UCBVAX.BERKELEY.ARPA> Received: from UTAH-20 by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83]) id AA05587; 2 Feb 83 16:33:09 PST (Wed) Received: by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83]) id AA05669; 2 Feb 83 16:37:59 PST (Wed) To: franz-friends@UCB-VAX Please add "Krohnfeldt@utah-20" to your mailing list. Thank you. -------  From: UCBKIM.jkf@Berkeley (John Foderaro) Date: 2-Feb-83 08:14:21-PST (Wed) Subject: multiple messages fixed? Message-Id: <8301021614.25937@UCBKIM.BERKELEY.ARPA> Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82]) id AA25937; 2-Feb-83 08:14:21-PST (Wed) Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83]) id AA00384; 2 Feb 83 08:10:26 PST (Wed) Received: by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83]) id AA00421; 2 Feb 83 08:12:25 PST (Wed) To: ucbvax.franz-friends@Berkeley I've broken the franz-friends mailing list over two machines. I hope that this will fix the problem of mail to franz-friends crashing ucbvax every thirty minutes. If you get multiple copies of this message, please do not tell me about it, I will already know.  From: mike@RAND-UNIX Date: Tuesday, 1 Feb 1983 15:06-PST Subject: response to "emacs interface to franz?" Message-Id: <8301021325.221@UCBVAX.BERKELEY.ARPA> Received: from rand-unix by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83]) id AA00221; 2 Feb 83 05:25:50 PST (Wed) To: franz-friends@BERKELEY Cc: mike@RAND-UNIX Here are the responses that I received to my question "What's out there for emacs?" ------- Forwarded Messages Received: From SU-SCORE by RAND-UNIX at Mon Jan 24 23:41:37 1983 Date: Mon 24 Jan 83 22:43:01-PST From: Jay Lark Subject: Re: emacs interface to franz? To: mike@RAND-UNIX.ARPA In-Reply-To: Your message of Mon 24 Jan 83 18:49:21-PST I'm sure you've probably received several messages similar to this one, but just in case... There exists the capability in Unix Emacs to run a process in its own buffer. Typein can be directed to the process, and output is just sent right to the buffer. This is an excellent way of running Lisp, because you get all of the nice Emacs features (paren balancing, local sexpr editing) at essentially no cost. I have been largely unsuccessful with trying to run Emacs under Lisp. The process package is part of the standard Unix Emacs distribution. Jay Lark ------- ------- Message 2 Received: From UTAH-CS by RAND-UNIX at Tue Jan 25 07:01:36 1983 Date: 25 Jan 1983 7:20-MST From: Russ Fish (host 10.0.0.4) Subject: Re: emacs interface to franz? To: mike@RAND-UNIX Cc: utah-gr!galway@UTAH-CS In-Reply-To: mike's message of Monday, 24 Jan 1983 15:34-PST We have been running our PSL (Portable Standard Lisp) in gemacs (Gosling's emacs) windows for some time. I suspect it would be a minor hack to convert it to Franz, but haven't done it and am not a Franz user. I could mail you our .ml code if you wanted to undertake converting it to Franz (or just using it for inspiration and hacking your own) and distributing it to Franz folks. It works like this: The lisp process is associated with a gemacs buffer/window. In that window you can carry on a normal line-by-line conversation, if you wish. sends the current line, (back to mark, which is left after the prompt) into the lisp. We mostly use the PSL in Rlisp syntax, which is algol-like, but this part of the code is just a wrapping for the new-shell function in process.ml with appropriate editting syntax set, so you could do the same with no work for any Lisp. You can send an expression, fn def, etc. from any other lisp-mode window with a single keypress. Echoing as input in the dialog window is inhibited if a prefix arg is provided, so you don't have to look at long exprs or fn defs again, just the lisp response. Sending multiple line exprs in response to a single prompt depends on the fact that PSL numbers the prompts for history, like the c-shell. A gemacs mlisp output filter process monitors the output for toploop prompts and feeds another line of input if the same prompt number comes back, instead of printing the prompt. The result is pretty classy. You get the full many-window gemacs editing environment with tags, etc. for random-access navigation and just send chunks of code as you change them. The extreme of usage is "menu" like windows which contain debugging code in clusters rather than sequences. You select exprs with the cursor and send them in any order. We also provide key fns for the common case of sending single lines to the toploop or single-character commands to the break-loop without editting them into a buffer. Best respond directly to me, since I am not on Franz-Friends. -Russ Fish (Fish@Utah-20, utah-cs!fish) ------- Message 3 Received: From UDEL-RELAY by RAND-UNIX at Tue Jan 25 18:18:55 1983 Return-Path: Date: 25 Jan 83 15:13:51 EST (Tue) From: Bruce Israel Subject: Re: emacs interface to franz? To: mike@RAND-UNIX In-Reply-To: Message of Monday, 24 Jan 1983 15:34-PST from mike@RAND-UNIX <8300250008.58@UCBVAX.BERKELEY.ARPA> Via: UMCP-CS; 25 Jan 83 20:45-EST We have a few franz<->emacs interfaces, but I'm not sure what you mean. One is the process.ml package that comes with gosling's emacs (the emacs that I assume you are talking about). With this package, you can run franz inside a window from within emacs and have the facilities of an editor along with lisp. The other thing we have is a local Franz package called the load1 package. This package was written for compiling flavors (like in the lisp machine; another local package) and has a function called vi. (vi 'lisp-function) will call the editor (from the environment variable VISUAL, /usr/ucb/vi is default) on the file which contains the definition of the lisp function, positioning the editor at the point in the file where the function is defined. Upon exiting the editor, it asks you if you want to reload the modified file. To edit a function from a file this way, the file must have been load1'ed previously so that the info on where the function is stored and what type it is will have been saved. Load1 will distinguish between different types of functions, ie. defflavors, defmethods, defmacros, defuns etc. and will search for the correct definition in the file. Is this what you mean? If you like I can send you the four or five files necessary. - Bruce ------- Message 4 Received: From CMU-CS-VLSI by RAND-UNIX at Thu Jan 27 06:53:41 1983 Date: 27 Jan 1983 09:44-EST From: Carl.Ebeling@CMU-CS-VLSI Subject: Re: emacs interface to franz? To: mike@RAND-UNIX Message-Id: <412526661/ce@CMU-CS-VLSI> In-Reply-To: mike@RAND-UNIX's bboard message of 27-Jan-83 04:14 I have an electric lisp package and process package for emacs. It includes 'zap-function-to-lisp' among other things. It is for Gosling's emacs and uses the subprocess facility. I can mail them to you if you like. Carl ------- End of Forwarded Messages  From: mike@RAND-UNIX Date: Tuesday, 1 Feb 1983 15:06-PST Subject: response to "emacs interface to franz?" Message-Id: <8301021325.221@UCBVAX.BERKELEY.ARPA> Received: from rand-unix by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83]) id AA00221; 2 Feb 83 05:25:50 PST (Wed) To: franz-friends@BERKELEY Cc: mike@RAND-UNIX Here are the responses that I received to my question "What's out there for emacs?" ------- Forwarded Messages Received: From SU-SCORE by RAND-UNIX at Mon Jan 24 23:41:37 1983 Date: Mon 24 Jan 83 22:43:01-PST From: Jay Lark Subject: Re: emacs interface to franz? To: mike@RAND-UNIX.ARPA In-Reply-To: Your message of Mon 24 Jan 83 18:49:21-PST I'm sure you've probably received several messages similar to this one, but just in case... There exists the capability in Unix Emacs to run a process in its own buffer. Typein can be directed to the process, and output is just sent right to the buffer. This is an excellent way of running Lisp, because you get all of the nice Emacs features (paren balancing, local sexpr editing) at essentially no cost. I have been largely unsuccessful with trying to run Emacs under Lisp. The process package is part of the standard Unix Emacs distribution. Jay Lark ------- ------- Message 2 Received: From UTAH-CS by RAND-UNIX at Tue Jan 25 07:01:36 1983 Date: 25 Jan 1983 7:20-MST From: Russ Fish (host 10.0.0.4) Subject: Re: emacs interface to franz? To: mike@RAND-UNIX Cc: utah-gr!galway@UTAH-CS In-Reply-To: mike's message of Monday, 24 Jan 1983 15:34-PST We have been running our PSL (Portable Standard Lisp) in gemacs (Gosling's emacs) windows for some time. I suspect it would be a minor hack to convert it to Franz, but haven't done it and am not a Franz user. I could mail you our .ml code if you wanted to undertake converting it to Franz (or just using it for inspiration and hacking your own) and distributing it to Franz folks. It works like this: The lisp process is associated with a gemacs buffer/window. In that window you can carry on a normal line-by-line conversation, if you wish. sends the current line, (back to mark, which is left after the prompt) into the lisp. We mostly use the PSL in Rlisp syntax, which is algol-like, but this part of the code is just a wrapping for the new-shell function in process.ml with appropriate editting syntax set, so you could do the same with no work for any Lisp. You can send an expression, fn def, etc. from any other lisp-mode window with a single keypress. Echoing as input in the dialog window is inhibited if a prefix arg is provided, so you don't have to look at long exprs or fn defs again, just the lisp response. Sending multiple line exprs in response to a single prompt depends on the fact that PSL numbers the prompts for history, like the c-shell. A gemacs mlisp output filter process monitors the output for toploop prompts and feeds another line of input if the same prompt number comes back, instead of printing the prompt. The result is pretty classy. You get the full many-window gemacs editing environment with tags, etc. for random-access navigation and just send chunks of code as you change them. The extreme of usage is "menu" like windows which contain debugging code in clusters rather than sequences. You select exprs with the cursor and send them in any order. We also provide key fns for the common case of sending single lines to the toploop or single-character commands to the break-loop without editting them into a buffer. Best respond directly to me, since I am not on Franz-Friends. -Russ Fish (Fish@Utah-20, utah-cs!fish) ------- Message 3 Received: From UDEL-RELAY by RAND-UNIX at Tue Jan 25 18:18:55 1983 Return-Path: Date: 25 Jan 83 15:13:51 EST (Tue) From: Bruce Israel Subject: Re: emacs interface to franz? To: mike@RAND-UNIX In-Reply-To: Message of Monday, 24 Jan 1983 15:34-PST from mike@RAND-UNIX <8300250008.58@UCBVAX.BERKELEY.ARPA> Via: UMCP-CS; 25 Jan 83 20:45-EST We have a few franz<->emacs interfaces, but I'm not sure what you mean. One is the process.ml package that comes with gosling's emacs (the emacs that I assume you are talking about). With this package, you can run franz inside a window from within emacs and have the facilities of an editor along with lisp. The other thing we have is a local Franz package called the load1 package. This package was written for compiling flavors (like in the lisp machine; another local package) and has a function called vi. (vi 'lisp-function) will call the editor (from the environment variable VISUAL, /usr/ucb/vi is default) on the file which contains the definition of the lisp function, positioning the editor at the point in the file where the function is defined. Upon exiting the editor, it asks you if you want to reload the modified file. To edit a function from a file this way, the file must have been load1'ed previously so that the info on where the function is stored and what type it is will have been saved. Load1 will distinguish between different types of functions, ie. defflavors, defmethods, defmacros, defuns etc. and will search for the correct definition in the file. Is this what you mean? If you like I can send you the four or five files necessary. - Bruce ------- Message 4 Received: From CMU-CS-VLSI by RAND-UNIX at Thu Jan 27 06:53:41 1983 Date: 27 Jan 1983 09:44-EST From: Carl.Ebeling@CMU-CS-VLSI Subject: Re: emacs interface to franz? To: mike@RAND-UNIX Message-Id: <412526661/ce@CMU-CS-VLSI> In-Reply-To: mike@RAND-UNIX's bboard message of 27-Jan-83 04:14 I have an electric lisp package and process package for emacs. It includes 'zap-function-to-lisp' among other things. It is for Gosling's emacs and uses the subprocess facility. I can mail them to you if you like. Carl ------- End of Forwarded Messages  Date: 28-Jan-83 08:34:33-PST (Fri) Subject: Re: franz distribution Message-Id: <8300281634.17319@UCBKIM.BERKELEY.ARPA> Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82]) id AA17319; 28-Jan-83 08:34:33-PST (Fri) Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83]) id AA02275; 28 Jan 83 14:58:37 PST (Fri) To: CARR@UTAH-20 Cc: UCBVAX.franz-friends@Berkeley In-Reply-To: Your message of 28 Jan 1983 0912-MST Here is our current distribution policy. This differs a bit from the one sent out a month ago [in particular, we now have anonymous ftp] -[Fri Jan 28 08:31:45 1983 by jkf]- Franz Lisp Distribution This note describes our distribution policy for Franz Lisp. What is being distributed: We distribute only source code in order to keep the distribution small and relatively Unix independent. Makefiles are provided to build the entire lisp system from source, even if you don't have a version of lisp running already. This process takes about 3 cpu hours on a Vax 780. [This version for the Vax only, a 68000 version is being worked on. Contact ucbkim.sklower@berkeley or ucbkim.layer@berkeley] The following source is provided: lisp interpreter, compiler (liszt), cross reference program (lxref), lisp manual, and other utility programs: trace, step, debug, cmu library functions, (and other minor ones), and these packages from the MIT lisp library: defstruct, loop. [These programs are provided as a convenience to those who can't access the arpanet and copy them. There is no documentation for them in the Franz Lisp manual. The best source of documentation is the Lisp Machine manual (available from MIT, Symbolics or LMI)] Regarding Flavors: there are two implementations of flavors for Franz Lisp, one from MIT (contact person Richard Zippel (rz@mit-mc)) and one from the University of Maryland (contact person Liz Allen (liz.umcp-cs@udel-relay)). Neither implementation is exactly like flavors on the Lisp Machine (due to differences between Lisp Machine lisp and Franz Lisp), and the implementations differ from each other. The MIT version cannot be distributed by us (yet) due to licensing problems. If you have a Lisp Machine Source license from Symbolics, you should be able to get a copy from MIT. For a Tech Report on Maryland flavors, write to Liz Allen. What is the form of the distribution: The files are packaged in a giant (2.1Mbyte) shell script. Running this shell script through 'sh' will result in a directory tree. A ReadMe file in the current directory will contain instructions on building the lisp system. The shell script is broken into a number of smaller files. The current distribution looks like: total 2089 489 -rw-r--r-- 1 jkf 500003 Jan 26 11:33 opus38.50.aa 489 -rw-r--r-- 1 jkf 500002 Jan 26 11:35 opus38.50.ab 489 -rw-r--r-- 1 jkf 500047 Jan 26 11:37 opus38.50.ac 489 -rw-r--r-- 1 jkf 500007 Jan 26 11:38 opus38.50.ad 133 -rw-r--r-- 1 jkf 136038 Jan 26 11:39 opus38.50.ae The '38.50' means Opus 38, minor version 50. These numbers may be different by the time you get your distribution. In order to extract the lisp files from this shell script, you need only type: cat * | sh To get a copy of the distribution: The distribution may be obtained either using FTP from an arpanet site, or on a magnetic tape through the U.S Mail. Arpanet: The files are stored on the arpanet host 'ucb-vax' [ if you have an out of date host table, it may be called 'ucb-monet' or 'ucb-ingres'. Its internet number is 10.2.0.78]. You can login as 'anonymous'. Use your name as the password. The files are in the subdirectory pub/lisp. For those who have accounts on ucb-vax, the full path is ~ftp/pub/lisp. Mag Tape: In order to get a copy of the distribution mailed to you, send a check to cover our tape copying and mailing costs (fees are listed below). We will purchase the mag tape and you are free to keep it. Please do NOT send us a tape. Fees: $50 - distribution tape mailed 3rd class add $10 - a copy of the Lisp Manual (we will only send one copy, you are free to photocopy it) add $7 - send tape via 1st class mail. -or- $15 - for just a copy of the Lisp Manual The address to send checks to is Keith Sklower EECS/Computer Science Division 524 Evans Hall University of California Berkeley, CA 94720 All checks should be made out to "Regents, University of California." We require pre-payment. We will not invoice or process purchase orders. Disclaimers: This distribution works on the latest versions of Unix running at Berkeley (4.1a). We can't guarantee that it will work on older versions (although, if you are running 4.1, it is almost certain that it will work, but we have not verified it). VMS users who are using a typical Unix compatibility package will probably not be able to build a lisp from this distribution unless they know a great deal about VMS and their compatibility package. At least one package (Eunice) supports Franz at this time. Redistribution: If you get a copy of the distribution, you are free to give it to other people. We appreciate being informed of new sites so they can be put on a mailing list (electronic and conventional). This list is used to announce new releases. To be put on this list, send U.S. Mail to Keith Sklower (address above) or to franz-friends-request@berkeley or ucbvax!franz-friends-request  From: UCBCAD.pettengi@Berkeley (Rob Pettengill) Date: 28-Jan-83 10:54:51-PST (Fri) Subject: emacs interface to franz? Message-Id: <8300281854.26156@UCBCAD.BERKELEY.ARPA> Received: by UCBCAD.BERKELEY.ARPA (3.256 [12/5/82]) id AA26156; 28-Jan-83 10:54:51-PST (Fri) Received: from UCBCAD.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83]) id AA00374; 28 Jan 83 12:53:44 PST (Fri) To: mike@rand-unix, ucbvax.franz-friends@Berkeley Cc: UCBCAD.pettengi@Berkeley While I was at TI I used a very nice interface that let one start up a Franz lisp inside an Emacs window. It came from SRI when we got Eunice to run under our VMS. Try Kashtan@SRI-AI. Rob Pettengill E-Systems, Dallas, Tx.  Date: 28 Jan 83 08:32:08 PST (Fri) Subject: Re: franz distribution Message-Id: <8300281631.21039@UCBVAX.BERKELEY.ARPA> Received: by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83]) id AA21039; 28 Jan 83 08:31:58 PST (Fri) To: CARR@UTAH-20 Cc: ucbvax.franz-friends@Berkeley Our policy is that you may move copies of Franz elsewhere without notifying us. We continue to be interested in sharing anything you or your company wish to provide us, in suggestions, programs, etc.  From: Harold Carr Date: 28 Jan 1983 0912-MST Subject: franz distribution Message-Id: <8300281615.20646@UCBVAX.BERKELEY.ARPA> Received: from UTAH-20 by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83]) id AA20646; 28 Jan 83 08:15:18 PST (Fri) To: UCBVAX.franz-friends@Berkeley What is the distribution policy? I work for a company that has opus 36 and is now currently running opus 37. Here at the University of Utah we are running opus 38.04. Is it OK to make a tape of the University's 38.04 to bring my company more up to date? Do I have to make it more formal by signing a transfer agreement or by obtaining the release directly from Berkeley? Thanks in advance, Harold Carr CARR@UTAH-20 -------  Date: 25 Jan 1983 9:58-EST From: Tim Finin Subject: emacs interface to franz? Return-Path: Message-Id: <8300260022.29320@UCBVAX.BERKELEY.ARPA> Received: from udel-relay.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83]) id AA29320; 25 Jan 83 16:22:57 PST (Tue) To: mike@Rand-Unix Cc: franz-friends@BERKELEY Via: UPenn; 25 Jan 83 19:21-EST We have a simple interface from Franz to Emacs, but I much prefer to go the other way, i.e. run Franz as a inferior job under Emacs. I believe there are several Emacs packages which allow one to run inferior jobs in an Emacs window (I have my own which is, unfortunately totally undocumented). Some of the benefits of this set up include: - one has all of the text editing functions available in Emacs - one has many lisp-based editing functions available in Emacs (thru mock-lisp packages like electriclisp) - one has a history of the session in the editing buffer - one has an environment which supports multiple concurrent processes running in seperate windows. - it is very easy to experiment with new interface features such as symbol completion and re-evaluation of previously issued commands Tim  From: Sean McLinden Date: 24 Jan 1983 1324-EST Subject: Franz Lisp and floating point accelerator Message-Id: <8300241825.19602@UCBVAX.BERKELEY.ARPA> Received: from RUTGERS by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83]) id AA19602; 24 Jan 83 10:25:06 PST (Mon) To: UCBVAX.franz-friends@Berkeley Has anyone determined if a floating point accelerator speeds up Vax Franz Lisp jobs in any significant fashion? Pointers would be appreciated. Sean McLinden Decision Systems Lab -------  Date: Monday, 24 Jan 1983 15:34-PST From: mike@RAND-UNIX Subject: emacs interface to franz? Message-Id: <8300250008.58@UCBVAX.BERKELEY.ARPA> Received: from rand-unix by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83]) id AA00058; 24 Jan 83 16:08:36 PST (Mon) To: franz-friends@BERKELEY Does anyone have a snazzy interface to emacs for franz? Thanks, Michael  Date: 22 Jan 1983 1634-PST From: JTSCHUDY@USC-ISIE Subject: MAILINGLIST ADDITION Message-Id: <8300230037.1747@UCBVAX.BERKELEY.ARPA> Received: from USC-ISIE by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83]) id AA01747; 22 Jan 83 16:37:17 PST (Sat) To: franz-friends@BERKELEY Hi! My name is Jim. I am presently attending the Naval Post Graduate School in Monterey California. I am in the Air Force enrolled in a DOD sponsored graduate degree in Command Control and Communications Systems Technology. i would like to be added to your mailing list. My net address is JTSCHUDY at ISIE. Thanks - Jim. -------  Date: 21-Jan-83 08:11:01-PST (Fri) From: UCBKIM.jkf@Berkeley (John Foderaro) Subject: test message, ignore Message-Id: <8300211611.18650@UCBKIM.BERKELEY.ARPA> Received: by UCBKIM.BERKELEY.ARPA (3.256 [12/5/82]) id AA18650; 21-Jan-83 08:11:01-PST (Fri) Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.300 [1/17/83]) id AA24887; 21 Jan 83 08:09:27 PST (Fri) To: franz-friends@BERKELEY This will give our mailer a chance to tell me how many of our franz friends are no longer reachable.  Date: 17 Dec 1982 20:35:36-PST From: Kim.fateman@Berkeley To: Schiffman@SRI-KL, c70.franz-friends@Berkeley Subject: Re: Franz for the 68000? We expect to release a version of Franz to Dual, Unisoft, and others who might make use of it, beginning Jan 1, 1983. We hope to make the modest modifications to make it run on SUN Microsystems workstations a few weeks after we receive them (maybe 3 weeks from now). If you are considering bringing this up on your own variant of 68000, and/or your own variant of UNIX (tm), or have other questions, they may be addressed to Kevin Layer (kim.layer@berkeley) or Keith Sklower (sklower@berkeley). Best wishes for the new year. Richard Fateman  Date: 19 Dec 1982 2019-PST From: SCHIFFMAN@SRI-KL@Berkeley Subject: Franz for 68000? To: franz-friends at UCB-C70 Not so long ago I read of some kind of porting effort for Franz to the 68000 on this list. Could someone update me on the status of this effort, and give me the addresses of the people involved? Thanks, -Allan -------  Date: 19 Dec 1982 1502-PST From: Schiffman@SRI-KL@Berkeley Subject: Franz for the 68000? To: franz-friends at UCB-C70 Not so long ago I read of some kind of porting effort for Franz to the 68000 on this list. Could someone update me on the status of this effort, and give me the addresses of the people involved? Thanks, -Allan -------  Date: 15 Dec 82 02:49:50 EST (Wed) From: Tim Maroney Subject: Franz/curses interface request To: franz-friends at Ucb-C70 Via: UNC; 15 Dec 82 3:35-EST Does anyone have a copy of the Franz/curses interface that they could send me? Requests to Berkeley have gone unheeded. Not being on ARPANET, I am unable to FTP, so please use normal mail on the source files. Thank you. Tim Maroney tim.unc@udel-relay unc!tim for USENET  Date: 1-Dec-82 09:13:03-PST (Wed) From: jkf@UCBKIM (John Foderaro) Subject: Random Numbers in Franz Message-Id: <8211011713.3615@UCBKIM.BERKELEY.ARPA> Received: by UCBKIM.BERKELEY.ARPA (3.255 [11/28/82]) id AA03615; 1-Dec-82 09:13:03-PST (Wed) Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.227 [10/22/82]) id A18406; 1-Dec-82 09:13:23-PST (Wed) To: franz-friends@berkeley Date: 29-Nov-82 15:56:09-PST (Mon) From: alice!sola!mitch Subject: Random Numbers in Franz To: alice!ucbvax!franz-friends@Berkeley In general, it is very bad practice to compute a random number between 0 and n by any expression such as (mod (random) n). In fact, Franz's random function does exactly that, returning the number generated by the C function rand(3) modulo n. This technique uses only the rightmost bits of successive calls to rand, and the righmost n bits of congruential sequences (like that returned by rand(3)) have a period of AT MOST 2**n (See Knuth vol.2 p. 12). So using the rightmost two bits will indeed give you sequences of at most period 4. (If your lisp doesn't have this behavior, you're not using the standard rand.) A better way to do it is to use the high order bits, by dividing the entire range up into n pieces and then seeing where you fall. (This method is biased if n is of the same order as the range, though.) The code I use is: (or (getd '$old-random) (putd '$old-random (getd 'random))) (defun random n (cond ((eq n 0) ($old-random)) ((fix (quotient (boole 1 ($old-random) #o 7777777777) (quotient #o 7777777777 (arg 1))))))) Mitch Marcus  Date: 30-Nov-82 15:15:12-PST (Tue) From: jkf@UCBKIM (John Foderaro) Subject: duplication of messages Message-Id: <8210302315.20115@UCBKIM.BERKELEY.ARPA> Received: by UCBKIM.BERKELEY.ARPA (3.255 [11/28/82]) id AA20115; 30-Nov-82 15:15:12-PST (Tue) Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.227 [10/22/82]) id A26410; 30-Nov-82 15:15:25-PST (Tue) To: franz-friends@berkeley The problem was tracked down to a poor vax 11/750 whose load average shot up to 50 when processing the franz-friends mail. The mailing list has been rearranged to avoid overtaxing that machine.  Date: 29 Nov 1982 0711-EST From: EGK@MIT-OZ@MIT-MC (Edjik) Subject: Re: rng Message-Id: <8210291239.13942@UCBVAX.BERKELEY.ARPA> Received: by UCBVAX.BERKELEY.ARPA (3.227 [10/22/82]) id A13854; 29-Nov-82 04:39:51-PST (Mon) To: tim.unc@UDEL-RELAY Cc: franz-friends@UCB-C70, EGK@MIT-OZ@MIT-MC In-Reply-To: Your message of 29-Nov-82 0226-EST Ive gotten almost 20 copies of Tims msg. Why does this lossage always seem to come from Berkley? Someone/thing musty really be royally wedged in berkley, this is about the 6th time multi msgs have come from there in the past three months. Jesus Christ! And people flame about wasting disk space! -------  Date: 28 Nov 82 22:40:14 EST (Sun) From: Tim Maroney Subject: rng Message-Id: <8210290604.5430@UCBVAX.BERKELEY.ARPA> Received: by UCBVAX.BERKELEY.ARPA (3.227 [10/22/82]) id A05346; 28-Nov-82 22:04:47-PST (Sun) To: franz-friends@Ucb-C70 Via: UNC; 28 Nov 82 23:38-EST To the person who asked about random number generators and deficiencies in (random) [I can't write mail to you for some reason]: You're not doing anything wrong; that's the way the sucker works. One good way to get random numbers is to do the syscall that gets you the number of seconds since whenever-it-is, and use the mod function. This is especially good for getting a random one or zero, by using the evenp function. Tim Maroney tim@unc@udel-relay  Date: 28 Nov 82 22:40:14 EST (Sun) From: Tim Maroney Subject: rng Message-Id: <8210290606.5478@UCBVAX.BERKELEY.ARPA> Received: by UCBVAX.BERKELEY.ARPA (3.227 [10/22/82]) id A05428; 28-Nov-82 22:06:41-PST (Sun) To: franz-friends@Ucb-C70 Via: UNC; 28 Nov 82 23:38-EST To the person who asked about random number generators and deficiencies in (random) [I can't write mail to you for some reason]: You're not doing anything wrong; that's the way the sucker works. One good way to get random numbers is to do the syscall that gets you the number of seconds since whenever-it-is, and use the mod function. This is especially good for getting a random one or zero, by using the evenp function. Tim Maroney tim@unc@udel-relay  Date: 28 Nov 82 22:40:14 EST (Sun) From: Tim Maroney Subject: rng Message-Id: <8210290606.5471@UCBVAX.BERKELEY.ARPA> Received: by UCBVAX.BERKELEY.ARPA (3.227 [10/22/82]) id A05416; 28-Nov-82 22:06:22-PST (Sun) To: franz-friends@Ucb-C70 Via: UNC; 28 Nov 82 23:38-EST To the person who asked about random number generators and deficiencies in (random) [I can't write mail to you for some reason]: You're not doing anything wrong; that's the way the sucker works. One good way to get random numbers is to do the syscall that gets you the number of seconds since whenever-it-is, and use the mod function. This is especially good for getting a random one or zero, by using the evenp function. Tim Maroney tim@unc@udel-relay  Date: 28 Nov 82 22:40:14 EST (Sun) From: Tim Maroney Subject: rng Message-Id: <8210290605.5456@UCBVAX.BERKELEY.ARPA> Received: by UCBVAX.BERKELEY.ARPA (3.227 [10/22/82]) id A05386; 28-Nov-82 22:05:39-PST (Sun) To: franz-friends@Ucb-C70 Via: UNC; 28 Nov 82 23:38-EST To the person who asked about random number generators and deficiencies in (random) [I can't write mail to you for some reason]: You're not doing anything wrong; that's the way the sucker works. One good way to get random numbers is to do the syscall that gets you the number of seconds since whenever-it-is, and use the mod function. This is especially good for getting a random one or zero, by using the evenp function. Tim Maroney tim@unc@udel-relay  Date: 28 Nov 82 22:40:14 EST (Sun) From: Tim Maroney Subject: rng Message-Id: <8210290605.5450@UCBVAX.BERKELEY.ARPA> Received: by UCBVAX.BERKELEY.ARPA (3.227 [10/22/82]) id A05391; 28-Nov-82 22:05:28-PST (Sun) To: franz-friends@Ucb-C70 Via: UNC; 28 Nov 82 23:38-EST To the person who asked about random number generators and deficiencies in (random) [I can't write mail to you for some reason]: You're not doing anything wrong; that's the way the sucker works. One good way to get random numbers is to do the syscall that gets you the number of seconds since whenever-it-is, and use the mod function. This is especially good for getting a random one or zero, by using the evenp function. Tim Maroney tim@unc@udel-relay  Date: 28 Nov 82 22:40:14 EST (Sun) From: Tim Maroney Subject: rng Message-Id: <8210290604.5412@UCBVAX.BERKELEY.ARPA> Received: by UCBVAX.BERKELEY.ARPA (3.227 [10/22/82]) id A05275; 28-Nov-82 22:04:04-PST (Sun) To: franz-friends@Ucb-C70 Via: UNC; 28 Nov 82 23:38-EST To the person who asked about random number generators and deficiencies in (random) [I can't write mail to you for some reason]: You're not doing anything wrong; that's the way the sucker works. One good way to get random numbers is to do the syscall that gets you the number of seconds since whenever-it-is, and use the mod function. This is especially good for getting a random one or zero, by using the evenp function. Tim Maroney tim@unc@udel-relay  Date: 28 Nov 82 22:40:14 EST (Sun) From: Tim Maroney Subject: rng Message-Id: <8210290603.5399@UCBVAX.BERKELEY.ARPA> Received: by UCBVAX.BERKELEY.ARPA (3.227 [10/22/82]) id A05220; 28-Nov-82 22:03:25-PST (Sun) To: franz-friends@Ucb-C70 Via: UNC; 28 Nov 82 23:38-EST To the person who asked about random number generators and deficiencies in (random) [I can't write mail to you for some reason]: You're not doing anything wrong; that's the way the sucker works. One good way to get random numbers is to do the syscall that gets you the number of seconds since whenever-it-is, and use the mod function. This is especially good for getting a random one or zero, by using the evenp function. Tim Maroney tim@unc@udel-relay  Date: 28 Nov 82 22:40:14 EST (Sun) From: Tim Maroney Subject: rng Message-Id: <8210290602.5354@UCBVAX.BERKELEY.ARPA> Received: by UCBVAX.BERKELEY.ARPA (3.227 [10/22/82]) id A05178; 28-Nov-82 22:02:09-PST (Sun) To: franz-friends@Ucb-C70 Via: UNC; 28 Nov 82 23:38-EST To the person who asked about random number generators and deficiencies in (random) [I can't write mail to you for some reason]: You're not doing anything wrong; that's the way the sucker works. One good way to get random numbers is to do the syscall that gets you the number of seconds since whenever-it-is, and use the mod function. This is especially good for getting a random one or zero, by using the evenp function. Tim Maroney tim@unc@udel-relay  Date: 28 Nov 82 22:40:14 EST (Sun) From: Tim Maroney Subject: rng Message-Id: <8210290600.5284@UCBVAX.BERKELEY.ARPA> Received: by UCBVAX.BERKELEY.ARPA (3.227 [10/22/82]) id A05119; 28-Nov-82 22:00:33-PST (Sun) To: franz-friends@Ucb-C70 Via: UNC; 28 Nov 82 23:38-EST To the person who asked about random number generators and deficiencies in (random) [I can't write mail to you for some reason]: You're not doing anything wrong; that's the way the sucker works. One good way to get random numbers is to do the syscall that gets you the number of seconds since whenever-it-is, and use the mod function. This is especially good for getting a random one or zero, by using the evenp function. Tim Maroney tim@unc@udel-relay  Date: 28 Nov 82 22:40:14 EST (Sun) From: Tim Maroney Subject: rng Message-Id: <8210290600.5282@UCBVAX.BERKELEY.ARPA> Received: by UCBVAX.BERKELEY.ARPA (3.227 [10/22/82]) id A05123; 28-Nov-82 22:00:28-PST (Sun) To: franz-friends@Ucb-C70 Via: UNC; 28 Nov 82 23:38-EST To the person who asked about random number generators and deficiencies in (random) [I can't write mail to you for some reason]: You're not doing anything wrong; that's the way the sucker works. One good way to get random numbers is to do the syscall that gets you the number of seconds since whenever-it-is, and use the mod function. This is especially good for getting a random one or zero, by using the evenp function. Tim Maroney tim@unc@udel-relay  Date: 28 Nov 82 22:40:14 EST (Sun) From: Tim Maroney Subject: rng Message-Id: <8210290600.5268@UCBVAX.BERKELEY.ARPA> Received: by UCBVAX.BERKELEY.ARPA (3.227 [10/22/82]) id A05103; 28-Nov-82 22:00:09-PST (Sun) To: franz-friends@Ucb-C70 Via: UNC; 28 Nov 82 23:38-EST To the person who asked about random number generators and deficiencies in (random) [I can't write mail to you for some reason]: You're not doing anything wrong; that's the way the sucker works. One good way to get random numbers is to do the syscall that gets you the number of seconds since whenever-it-is, and use the mod function. This is especially good for getting a random one or zero, by using the evenp function. Tim Maroney tim@unc@udel-relay  Date: 28 Nov 82 22:40:14 EST (Sun) From: Tim Maroney Subject: rng Message-Id: <8210290600.5285@UCBVAX.BERKELEY.ARPA> Received: by UCBVAX.BERKELEY.ARPA (3.227 [10/22/82]) id A05135; 28-Nov-82 22:00:32-PST (Sun) To: franz-friends@Ucb-C70 Via: UNC; 28 Nov 82 23:38-EST To the person who asked about random number generators and deficiencies in (random) [I can't write mail to you for some reason]: You're not doing anything wrong; that's the way the sucker works. One good way to get random numbers is to do the syscall that gets you the number of seconds since whenever-it-is, and use the mod function. This is especially good for getting a random one or zero, by using the evenp function. Tim Maroney tim@unc@udel-relay  Date: 28 Nov 1982 11:47:28-EST From: Paul.Rosenbloom@CMU-CS-G@CMU-CS-A Subject: (random) problems Message-Id: <8210281711.21895@UCBVAX.BERKELEY.ARPA> Received: by UCBVAX.BERKELEY.ARPA (3.227 [10/22/82]) id A21827; 28-Nov-82 09:11:47-PST (Sun) Mail-From: CMUFTP host CMU-CS-G received by CMU-10A at 28-Nov-82 11:48:21-EST Apparently-To: franz-friends-local@mit-mc I am having two problems using (random) in Franz lisp. The first problem is that I can't find any way to set the seed. Every time I enter lisp, the generator is in the same state. I have had to resort to cfasling a c procedure that calls srand() (as (random) seems to be defined in c by a call on rand()). Is there a way to do this within lisp? The other problem is more serious. The generator seems to generate tight cycles for (at least) arguments that are small powers of 2. For example, repeatedly executing (random 2) yields the sequence 01010101..., and (random 4) yields 01230123.... These sequences apparently occur no matter to what value I set the seed. Does anyone one know what I could be doing wrong, or have a working random number generator?  Date: 23 Nov 82 12:30:39 EST (Tue) From: Liz Allen Subject: Re: Pipes between lisp and C Message-Id: <8210250139.11587@UCBVAX.BERKELEY.ARPA> Received: by UCBVAX.BERKELEY.ARPA (3.227 [10/22/82]) id A11511; 24-Nov-82 17:39:15-PST (Wed) To: ucbvax.(James@Berkeley, Larus)UCBKIM.larus@Berkeley, giarla@Rand-Unix Cc: UCBKIM.franz-friends@Berkeley In-Reply-To: Message of 22-Nov-82 17:38:39-PST (Mon) from UCBKIM.larus@Berkeley <8210230139.1912@UCBKIM.BERKELEY.ARPA> Via: UMCP-CS; 24 Nov 82 20:06-EST An alternative to using pipes is to use IPC (inter-process communication). A while back, we developed a large system here that had 4 seperate processes which (in our first attempt) had started up one another using the process function and had communicated via pipes. However, when we were trying to debug it, we found it nearly impossible to communicate with the subprocesses when they error'd out. These were written in lisp so we wanted to do (showstack)'s, etc. to find out where the bugs were occurring. Later, when IPC came out, we switched over to it, and the debugging became much simpler since we could run the processes independently on seperate terminals and debug each without having to interrupt the others explicitly. I don't know what the best way for you to get hold of IPC is. We had some lisp functions defined for doing IPC port open, close, read, etc, but we haven't used them for a long time. I believe that CMU has also used IPC with lisp and has exported a set of Franz Lisp IPC functions. You might want to contact them for more information. -Liz  Date: 24-Nov-82 19:23:52-PST (Wed) From: Kim.fateman@Berkeley Subject: Re: Pipes between lisp and C Message-Id: <8210250239.13284@UCBVAX.BERKELEY.ARPA> Received: by UCBVAX.BERKELEY.ARPA (3.227 [10/22/82]) id A13262; 24-Nov-82 18:39:06-PST (Wed) To: giarla@Rand-Unix, Kim.larus@Berkeley, liz.umcp-cs@UDel-Relay Cc: franz-friends@Kim@UDel-Relay Depending on the size of packages involved, the simplest and most effect way of interacting between languages, and the one I have personally had the most success with, is just loading the programs in, using cfasl or ffasl (for Fortran fans). This works quite well for loading things of the sort "random library of graphics functions" or "math library" or in one case "hairy interactive matrix package". The last case "MATLAB" from Univ. New Mexico, required some minor hacking, but I suspect the alternative of using pipes would be more painful. This is not to say IPC has no place or that pipes are no good; but I hate to use an overly general mechanism, or one with unnecessary inefficiency and inadequacies.  Date: 23 Nov 82 11:06:22 EST (Tue) From: Tim Maroney Subject: pipes in Franz Message-Id: <8210250015.9323@UCBVAX.BERKELEY.ARPA> Received: by UCBVAX.BERKELEY.ARPA (3.227 [10/22/82]) id A09224; 24-Nov-82 16:15:12-PST (Wed) To: franz-friends@Ucb-C70 Via: UNC; 23 Nov 82 21:15-EST Using process is all well and good, but the arguments don't seem to be actual pipes. They are ports, and I don't see how you can open a port without linking it to a file (not a pipe). How would you send input to a process and receive output from a process without going through an external file? Tim Maroney unc!tim on USENET  Date: 23-Nov-82 07:59:11-PST (Tue) From: UCBKIM.jkf@Berkeley (John Foderaro) Subject: second test message - ignore this too Message-Id: <8210231559.1923@UCBKIM.BERKELEY.ARPA> Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82]) id A01923; 23-Nov-82 07:59:13-PST (Tue) Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.227 [10/22/82]) id A16262; 23-Nov-82 07:57:41-PST (Tue) Received: by UCBVAX.BERKELEY.ARPA (3.227 [10/22/82]) id A17340; 23-Nov-82 08:37:37-PST (Tue) To: franz-friends@berkeley This is to verify that all non-existant names have been removed.  Date: 22-Nov-82 17:38:39-PST (Mon) From: UCBKIM.larus@Berkeley (James Larus) Subject: Re: Pipes between lisp and C Message-Id: <8210230139.1912@UCBKIM.BERKELEY.ARPA> Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82]) id A01912; 22-Nov-82 17:39:34-PST (Mon) Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.227 [10/22/82]) id A02414; 22-Nov-82 17:40:55-PST (Mon) To: giarla@RAND-UNIX Cc: UCBKIM.franz-friends@Berkeley In-Reply-To: Your message of Monday, 22 Nov 1982 13:09-PST Since this reply may be of se to more than the originator of the message, I am taking the liberty of distributing it to franz-friends. Communicating over pipes to another process (written in C or any other languages) is not difficult. There are two ways of doing it, depending on which release of Franz Lisp you have. If you have a vanilla release, you must use the "process" routine. Its first argument is the name of the program with which you wish to communicate. This program is started running. The other two arguments are symbols that name the variables where the ports going to and comming from the process, repectively, are stored. Note that these variables must be declared special since process takes its arguments unevaluated and does a setq into these variables. Sometime within the last few months, a few new functions were brought into Franz that make process communication much cleaner. The new function "*process" takes the program's name and two flags. The optional flags indicate whether to set up the read and write ports, respectively. The function always returns the process id of the child. If a port is opened, the port descriptor is returned in a list (see desetq). Two additional functions, "*process-send" and "*process-receive" take care of the common cases where you only write to or read from a process. A few warnings apply to any use of pipes in Lisp. Avoid the function "resetio", which closes all ports, including the pipes. Remember to close pipes when your process dies, or you will soon run out of ports very quickly. Call the function "wait" after you close the pipes to kill a subprocess, otherwise you will have a zombie process lying around. >From one who has been there, /Jim  Date: Monday, 22 Nov 1982 13:09-PST From: giarla@RAND-UNIX Subject: Pipes between lisp and C Message-Id: <8210222158.27984@UCBVAX.BERKELEY.ARPA> Received: by UCBVAX.BERKELEY.ARPA (3.227 [10/22/82]) id A27970; 22-Nov-82 13:58:37-PST (Mon) To: franz-friends@UCB-C70 Cc: giarla@RAND-UNIX, klahr@RAND-UNIX, obrien@RAND-UNIX We have a simulation written in fanzlisp and would like to have it communicate with a graphics package written in C. Looking thru the documentation we see that there are ways to use forks, execs, and pipes from fanzlisp. Before we spend too much time with false attempts and finally create something strange are there any suggestions as to how we might do the following... The user starts fanzlisp. The user loads the simulation environment. The user wants to run with the C-based graphics package. Two pipes are set up (bi-directional communications), Fork and Exec, The C graphics package starts and looks to the pipes for I/O. The user runs the simulation. The simulation runs one tick then sends via a pipe a collection of objects (data structures). When the graphics package receives the last object it sends back an ack. Many ticks later the user stops the simulation The user grabs the graphics tablet and positions a new object and sends this information back to the simulation... OK! I know the above is informal and sketchy... Questions: Has anyone used franzlisp with pipes to C? Is there an already written, niffty franzlisp-C communications package out there in franzlisp-land? Are there comments about the goodness or badness of what the documentation indicates can be done with pipes. Are there suggestions about alternatives to using pipes to communicate with a C program? A humble C-graphics hacker that has never used lisp before Giarla...  Date: 21-Nov-82 09:39:48-PST (Sun) From: UCBKIM.jkf@Berkeley (John Foderaro) Subject: test message - please ignore Message-Id: <8210211739.358@UCBKIM.BERKELEY.ARPA> Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82]) id A00358; 21-Nov-82 09:39:51-PST (Sun) Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.227 [10/22/82]) id A29249; 21-Nov-82 09:37:44-PST (Sun) Received: by UCBVAX.BERKELEY.ARPA (3.227 [10/22/82]) id A00332; 21-Nov-82 10:12:42-PST (Sun) To: franz-friends@berkeley I am trying to remove names which no longer exist.  Date: 19-Nov-82 19:37:22-PST (Fri) From: Kim.fateman@Berkeley Subject: Re: efficiency of large systems in franz Message-Id: <8210200549.18969@UCBVAX.BERKELEY.ARPA> Received: by UCBVAX.BERKELEY.ARPA (3.227 [10/22/82]) id A18808; 19-Nov-82 21:49:43-PST (Fri) To: c70.franz-friends@Berkeley, ucla-lax!patel@UCLA-Security I don't know what you are planning to compare to Franz. I believe there are several VLSI tools written in Franz; if efficiency must be combined with interactive program development, interpretation, automatic garbage collection, etc, it is usually possible to rewrite critical inner loops in C or assembler, for example. As far as large systems go, Vaxima is about 3.5megabytes; it can grow to considerably more. I suppose you could argue it could be made faster by reprogramming in assembler, but it would be a fairly Neanderthal view.  Date: 19 November 1982 1822-PST (Friday) From: ucla-lax!patel@UCLA-Security (Dorab Patel) Subject: efficiency of large systems in franz Message-Id: <8210200352.15133@UCBVAX.BERKELEY.ARPA> Received: by UCBVAX.BERKELEY.ARPA (3.227 [10/22/82]) id A15016; 19-Nov-82 19:52:26-PST (Fri) To: franz-friends@berkeley Does any one out there have experience with a "large" (actually any size will do) system written in franz? I am mainly interested in the efficiency question. Did you find that it was too slow? or was the response time adequate? I need this information to help argue for using franz to implement a CAD system at UCLA. Any pointers will be appreciated. Thanks, Dorab  Date: 16-Nov-82 15:49:12-PST (Tue) From: UCBKIM.larus@Berkeley (James Larus) Subject: Re: Franz interface to termcap? Message-Id: <8210162350.1283@UCBKIM.BERKELEY.ARPA> Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82]) id A01283; 16-Nov-82 15:50:28-PST (Tue) Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.227 [10/22/82]) id A02268; 16-Nov-82 16:51:27-PST (Tue) To: MHS@MIT-MC, UCBKIM.Franz-friends@Berkeley Cc: Mhs@MIT-OZ In-Reply-To: Your message of Monday, 15 November 1982 10:54-EST Mark, I have written a package that provides all of the functions of curses in Lisp. Since curses may or may not include all of the functions you need, I will send you a copy of the Lisp source code (+ c source code), if you wish. /Jim  Date: 02 Nov 1982 1808-PST From: FRD@SU-AI@Berkeley To: franz-friends at MIT-MC Does anybody have experience with or (preferably) hard data on the performance of a VAX 11/780, 2.5MegB, running VMS with and without Eunice/UNIX? For instance, start with a group of 20 VAX VMS users (about 30-35 processes) ... Then 10 of them switch to Eunice/UNIX on the same VAX to do the same kind of computing, editing, etc (admittedly shakey, 'cause they wouldn't switch if they couldn't do different things but oh well). Will the 10 remaining VMS users be aware of degraded performance? If so, exactly how?  Date: 02 Nov 1982 1808-PST From: FRD@SU-AI@Berkeley To: franz-friends at MIT-MC Does anybody have experience with or (preferably) hard data on the performance of a VAX 11/780, 2.5MegB, running VMS with and without Eunice/UNIX? For instance, start with a group of 20 VAX VMS users (about 30-35 processes) ... Then 10 of them switch to Eunice/UNIX on the same VAX to do the same kind of computing, editing, etc (admittedly shakey, 'cause they wouldn't switch if they couldn't do different things but oh well). Will the 10 remaining VMS users be aware of degraded performance? If so, exactly how?  Date: 29 Oct 82 12:04:24 EDT (Fri) From: Liz Allen Subject: Re: Flavor system To: ECC.MIT-MC at Ucb-C70, FRANZ-FRIENDS at Mit-Mc Cc: randy.umcp-cs at UDel-Relay In-Reply-To: Message of 25 October 1982 16:29-EDT from ECC@MIT-MC@Berkeley Via: UMCP-CS; 30 Oct 82 5:40-EDT Date: 25 October 1982 16:29-EDT From: ECC@MIT-MC@Berkeley Subject: Flavor system To: FRANZ-FRIENDS at MIT-MC Can someone give me a pointer to the Franz flavor system developed by U. Maryland? I am looking for information on how to FTP the files -- what machine, whether public, what files, etc. Since the U. of Maryland is not (yet) an Arpanet host, you can't FTP files directly from here. We are right now completing some documentation for all of our hacks -- including documentation for some recent improvements for our flavors system. When that documentation is complete, we will be ready to distribute the packages developed here. Besides flavors, this includes a top level called userexec which is based on INTERLISP's top level and a production system called YAPS similar to but more flexible than OPS5. We are supposed to become an Arpanet host in a few months... (Read open ended period of time.) Meanwhile, if you would like to get our code, mail me a tape, and I will mail it back with the code and documentation on it. I'd appreciate it if someone would volunteer to let other folks FTP the files from their machine until we do become an Arpanet host. My address is: Liz Allen Univ of Maryland Dept of Computer Science College Park MD 20783 (301) 454-4247 liz.umcp-cs@udel-relay -Liz  Date: 30 Oct 1982 11:51:58-PDT From: Kim.fateman@Berkeley To: Kim.franz-friends@Berkeley Subject: fugue # 2 FUGUE Notes An occasional publication of the Franz Lisp User Group under Unix and Eunice (FUGUE) Number 2 (October, 1982) edited by Richard J. Fateman University of California Berkeley CA 94720 USA fateman@berkeley 1. Welcome! It seems about time to publish the second of these newsletters, since we have accumulated a number of new items. We would also like to relay to others such informa- tion as has been forwarded to us. The reports of projects at Berkeley (and elsewhere) may strike sympathetic chords with other research. 2. New programs 2.1. OPS-5 OPS-5 is a "production system" written by Charles Forgy of CMU. It appears to work just fine in Franz, and is in wide use. Interested persons may obtain copies of documen- tation and the program from Charles.Forgy@CMU-10A. ( Charles Forgy, Computer Science Department, Carnegie-Mellon Univer- sity, Pittsburgh, PA 15213) It is their policy to send it to anyone who wants it free of charge. 2.2. GLISP GLISP is a system which provides interesting linguistic features for generic operations and data abstraction. Writ- ten by Gordon Novak at Stanford University, it was origi- nally developed for Interlisp, but has been ported to other lisps, including Franz. 2.3. Flavors There are now two distinct implementations, apparently with identical functionally, of "flavors" as appearing in the MIT Lisp Machine software. One is described in TR-1174, ____________________ 9 UNIX, Eunice, Franz Lisp, may be trademarks of Bell Labs, SRI Int'l, and Univ. of Calif. 9 "Franz Flavors" by Richard J. Wood (Dept of C.S., Univ. of Maryland, College Pk, MD 20742). The other was written by Juan R. Loaiza of MIT, Laboratory for Computer Science. We have a copy of the latter on-line here, and expect to receive a copy of the Maryland one, shortly. Eric Cooper here at Berkeley is in charge of the flavors situation. There is an implementation of closures, mostly compati- ble with the Lisp Machine specification, announced by John Foderaro for Opus 38.33. The incompatibility is a result of what we perceive to be a high performance penalty for eso- terica. 2.4. Database Interfaces Jim Larus at UCB has cooked up interfaces to both the INGRES relational database system, and the simpler TROLL database system. These will be described in his forthcoming MS report, along with the next item. 2.5. Cursor-control and Menus Larus has provided an implementation of screen manage- ment which uses the UNIX "curses" package for primitive win- dow management. A menu-based interface has also been developed as part of this. 2.6. Vaxima and Algebraic Manipulation A new version of vaxima, the VAX version of the MACSYMA algebraic manipulation system, was released in July by UCB, incorporating some bug fixes, improved programs, and a large number of user-contributed subroutine libraries. This was made available to test-site licensees. Unfortunately, MIT has suspended new test-site licensing since about April, 1982. We hope that MIT will be liberalizing its distribu- tion policy to non-commercial sites. See the note below about MACSYMA being sold. As a counterpoint to this, UC Berkeley has received a substantial grant from the System Development Foundation for work on Mathematical Representation and Manipulation, which should result in some more advanced systems for application of computers to symbolic mathematics. Recruiting for researchers, staff, and students is underway now, and interested persons should contact Richard Fateman. 2.7. VLSI Design Rule Checker Lyra, written in Lisp by Michael Arnold, is a retarget- able, hierarchical, design rule checker for VLSI circuits. Lyra features a rule compiler (also written in Lisp of course!) which translates symbolic design rule descriptions to lisp code for checking the rules. Lyra was used for the RISC project. It is currently being used extensively at Berkeley, and will be included in the Fall-82 distribution of of the Berkeley CAD tools. For more information contact Michael Arnold or John Ousterhout at Berkeley. 2.8. Generic Arithmetic As a proposed extension to Franz arithmetic, Richard Fateman, Keith Sklower and Scott Morrison, have written a simple-minded generic arithmetic package which includes modules which can be loaded to support exact rational arith- metic, software-simulated IEEE extended arithmetic, arbi- trary precision floating point, complex, interval, and mul- tivariate polynomial. Combinations of some of these are sup- ported, although the package is as yet incomplete in some areas. The IEEE arithmetic simulation is written in C. These packages are probably not in good enough shape for casual use by others. 3. New features Various performance enhancements and bug fixes have been incorporated in versions of Franz (now on Opus 38.33 and the compiler, Liszt 8.14) These are mentioned in brief here; more details accompany updates of the system and manual included in the forthcoming Berkeley 4.2BSD UNIX dis- tribution. 3.1. Franz We added a switch to cause the evaluator to save macro expansions so they need only be expanded once. We added vector and vector-immediate data types. We rewrote showstack and backtrace so they are easier to use. We made the lisp to foreign function interface more secure. The system now allows foreign function to call lisp functions. We added closures and support flavors, features from the Lisp Machine. 3.2. Liszt Liszt will check the number of arguments to system functions and user defined functions. 9 9 Liszt supports local declarations. Liszt will automatically compile lambda expressions headed by the function `function'. Liszt supports compiler-only macros and will autoload macros if necessary. 4. MC68000 Keith Sklower and Kevin Layer have been working on the MC68000 version of Franz under the UNIX operating system (using a DUAL System 83). While the current configuration is a swapping system, the Lisp should be able to use the full address space of the CPU. We expect to have this system run- ning on the UNIX 4.2 BSD SUN software, too. The base system on the DUAL, including the interpreter, reader, bignums, fasl, works; the compiler is being perfected. 5. Other Lisps We now have, in-house tried 4 (other) VAX UNIX lisp systems: YLISP, Interlisp, PSL, and VLISP. We know that Interlisp can run also on VMS using the Eunice package. Interested parties can contact David Dyer at USC-ISI. There is also a version of lisp which runs on VMS only, namely NIL, from MIT, which appears to be undergoing limited dis- tribution. Two other lisps under development under UNIX are Yale's answer to NIL, namely "T", and Common Lisp, from CMU and friends. Counting Franz, that makes 7 lisp systems for the VAX computer line. Not counting variants on 2 operating systems. A Paen to standardization. Dick Gabriel states some useful principles for com- parisons in the conference record of the 1982 ACM Lisp and Functional Programming Conference, which was held in August. We understand he now has a collection of some 18 programs which he is continuing to time on various systems. 6. Work in Progress 6.1. BITGRAPH SUN AED-512 Greg Foster at UCB is working on raster-graphics sup- port in Franz for the 800 by 1000 b/w raster displays of the BBN Bitgraph and/or the SUN Workstation, and possibly the color 512 by 512 AED system. We are probably going to han- dle mice and Bitpad (stylus) input for pointing. There are lots of projects we hear about with similar systems, e.g. just recently from the University of Maryland, using UNIX and multiplexed files for window management of a 68000-based home-grown workstation. 6.2. RISC-LISP Yes, Reduced Instruction Set Computer fans, who else but UCB would be so bold... Carl Ponder is examining the issues involved in constructing a fast lisp interpreter and compiler for the RISC architecture. You see, we have all these chips... 7. Work Contemplated 7.1. Fast Number Compiler Undergraduate Jeff Cohen at Berkeley is starting to look at this. There are several industrial concerns that have expressed interest in using such a system, but expected it to be subsidized by someone else. 7.2. IBM Franz Even more nibbles on this one, but not yet. 8. Business News 8.1. Eunice SOLD Some of you may have heard that the Eunice software package was sold by SRI to the Wollongong Group, a UNIX sup- port group in Palo Alto. Prices range from $2k (educa- tional) to $5k (commercial). Naturally this package is of interest beyond the availability of Franz Lisp. We have not compared this product to other similar ones, but we know that TWG has been distributing a working Franz opus 38. As far as alternatives to Eunice, we are aware of a system developed at Rice University, and another by Human Computing Resources (HCR) in Toronto. We have not evaluated either of these. 8.2. MACSYMA SOLD MIT has sold exclusive rights to MACSYMA, a large alge- braic manipulation system, to Symbolics, Inc. of Cambridge Mass. This package runs in Franz Lisp, (among other Lisps) We hope that soon it will again be available to educational institutions with VAX systems either from us or Symbolics, at a nominal charge. We understand that commercial licenses (from Symbolics) for versions of MACSYMA on PDP-10s, Lisp Machines, etc. will distributed at non-nominal prices and offered with maintenance contracts.  Date: 22 Oct 1982 2141-EDT From: ROADS@MIT-OZ@MIT-MC@Berkeley Subject: mailing list To: franz-friends at UCB-C70 Please remove me from your mailing list. Thank you. -------  Date: 19-Oct-82 18:54:02-PDT (Tue) From: UCBKIM.jkf@Berkeley Subject: lisp tags Message-Id: <8209200154.195@UCBKIM.BERKELEY.ARPA> Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82]) id A00195; 19-Oct-82 18:54:18-PDT (Tue) Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.207 [9/26/82]) id A04806; 19-Oct-82 18:59:19-PDT (Tue) To: UCBKIM.franz-friends@Berkeley We also use vi style tags so emacs users and vi users can share the same tags file. Rather than modify ctags, we use this shell script: #!/bin/csh # make a tags file for lisp source files. # use: # lisptags foo.l bar.l baz.l ... bof.l # generate the file 'tags' # awk -f /usr/local/lib/ltags $* | sort > tags where the file /usr/local/lib/ltags is /^\(DEF/ { print $2 " " FILENAME " ?^" $0 "$?" } /^\(def/ { print $2 " " FILENAME " ?^" $0 "$?" }  Date: 19-Oct-82 08:17:51-PDT (Tue) From: UCBKIM.jkf@Berkeley Subject: gprint message Message-Id: <8209191517.16197@UCBKIM.BERKELEY.ARPA> Received: by UCBKIM.BERKELEY.ARPA (3.222 [10/13/82]) id A16197; 19-Oct-82 08:17:52-PDT (Tue) Received: from UCBKIM.BERKELEY.ARPA by UCBVAX.BERKELEY.ARPA (3.207 [9/26/82]) id A04649; 19-Oct-82 08:18:51-PDT (Tue) To: franz-friends@berkeley I am forwarding this message from a user who is having trouble accessing the franz-friends mailing list: Date: 18 Oct 1982 15:44-PDT From: jjf%Diablo at SU-Score Subject: GPRINT and TAGS To: franz-friends@mit-mc Message-Id: <82/10/18 1544.050@Diablo> Does anyone know of an UNIX Emacs compatible TAGS program for Franz Lisp files that can be run from the shell? It would be nice to put such a job in the background. Is there a good pretty-print package (such as Waters' GPRINT) that someone has running in Franz? Thanks, Jeff Finger csd.jjf@score  Date: 23 Sep 1982 2058-PDT From: RWOOD@USC-ISIB@Berkeley Subject: delete me To: franz-friends at UCB-C70 Please delete me from this mailing list. Thanks, Rich Wood rwood@isib -------  Date: 16 Sep 1982 2130-EDT From: ACORREIRA@BBNA@Berkeley Subject: flavors in Franz Lisp? To: franz-friends at UCB-C70 Does anyone have a version of Lisp Machine Lisp flavors (or some close variation) running under Franz? Alfred Correira -------  Date: 30-Aug-82 20:16:20-PDT (Mon) From: ucbvax: (John Foderaro) Subject: case sensitivity: a correction Message-Id: <60852.8245.Kim@Berkeley> Received: from UCBKIM by UCB-UCBVAX (3.177 [8/27/82]) id a00732; 31-Aug-82 09:08:40-PDT (Tue) Via: ucbkim.EtherNet (V3.147 [7/22/82]); 31-Aug-82 09:08:52-PDT (Tue) To: franz-friends@berkeley A few people have pointed out to me that Interlisp is case-sensitive, not case-insensitive as I stated.  Date: 30 Aug 1982 14:09:48-PDT From: Kim.sklower at Berkeley To: franz-friends@UCB-C70 Subject: franz for VMS Until now, Franz has only run under VMS through the aid of a unix emulator developed at SRI by David Kashtan, called EUNICE. SRI has recently sold marketing rights to EUNICE to a company called the Wollogong Group. We are currently trying to convince them to license just Franz separately, which would reduce the cost to UNIVERSITIES from $2,000 to $500 (for the first copy). (This would be quite generous on their part, since they are still required to pay SRI royalties on each binary!) As the source to Franz is almost entirely free of Unix proprietary source code, we will be happy to send a copy to anybody who wishes to make it run under VMS for our usual duplication charge, (and as usual, have no objection to third party exchanges of the most recent version). The phone number for The Wollogong Group is (415) 962 9224.  Date: 30 Aug 1982 1227-MDT From: Harold Carr Subject: franz for VMS To: franz-friends at UCB-C70 How do I obtain franz for VMS along with a manual? Harold Carr Carr@Utah-20 -------  Date: 29-Aug-82 22:02:05-PDT (Sun) From: ucbvax: (John Foderaro) Subject: Common Lisp and case sensitivity Message-Id: <60852.16628.Kim@Berkeley> Received: from UCBKIM by UCB-UCBVAX (3.177 [8/27/82]) id a05520; 29-Aug-82 22:01:57-PDT (Sun) Via: ucbkim.EtherNet (V3.147 [7/22/82]); 29-Aug-82 22:02:06-PDT (Sun) To: franz-friends@berkeley As many of you may already know, a new version of Lisp is being designed by a group of representatives from the Maclisp, Lisp Machine Lisp and Interlisp communities. This lisp, called 'Common Lisp', promises to be a very powerful and portable Lisp. Currently Common Lisp is 'case-insensitive' on input. By that I mean that the reader converts all non-escaped characters to a single case (currently UPPER CASE). Thus the symbols foo, FOO, Foo, fOO and FoO are all 'eq'. Although case-insensitivity may seem strange to Unix users, it is the rule in Maclisp, Lisp Machine Lisp and Interlisp. Franz Lisp is case-sensitive (FOO and foo are not 'eq') primarily because Unix is case-sensitive. I have been trying to convince the Common Lisp designers that they should consider providing a case-sensitive reader option so that Common Lisp will fit in on Unix systems. I would like to find out how important case-sensitivity is to you. I would appreciate it if all Franz Lisp users would let me know the answers to the following questions. Please send them to ucbvax!jkf or jkf@berkeley. Please do no send them to the usenet. I will keep track of replies and mail out a summary of the results. Poll: 1) Do you use the fact that Franz Lisp is case sensitive, that is do you use variables with capital letters? If yes, do you ever have two different variables whose names differ only by capitalization? [When I refer to 'variable' I mean a symbol to which you assign a variable to distinguish it from something used just for printing, as in (print 'Results). ] 2) If a case-insensitive Common Lisp was the only lisp available on your machine would you: a) use it without complaint about the case-insensitivity b) ask the person in charge of Common Lisp at your sight to add a switch to disable the code that maps all characters to the same case, thus making it possible for each user to make Common Lisp case-sensitive. 3) Do you prefer an operating system to be case-sensitive (like Unix and Multics) or case-insensitive (like Tops-10, Tops-20, Tenex, etc etc). End of poll. Please send replies to me [not the usenet] John Foderaro ucbvax!jkf jkf@berkeley  Date: 29-Aug-82 22:02:05-PDT (Sun) From: ucbvax: (John Foderaro) Subject: Common Lisp and case sensitivity Message-Id: <60852.16628.Kim@Berkeley> Received: from UCBKIM by UCB-UCBVAX (3.177 [8/27/82]) id a05520; 29-Aug-82 22:01:57-PDT (Sun) Via: ucbkim.EtherNet (V3.147 [7/22/82]); 29-Aug-82 22:02:06-PDT (Sun) To: franz-friends@berkeley As many of you may already know, a new version of Lisp is being designed by a group of representatives from the Maclisp, Lisp Machine Lisp and Interlisp communities. This lisp, called 'Common Lisp', promises to be a very powerful and portable Lisp. Currently Common Lisp is 'case-insensitive' on input. By that I mean that the reader converts all non-escaped characters to a single case (currently UPPER CASE). Thus the symbols foo, FOO, Foo, fOO and FoO are all 'eq'. Although case-insensitivity may seem strange to Unix users, it is the rule in Maclisp, Lisp Machine Lisp and Interlisp. Franz Lisp is case-sensitive (FOO and foo are not 'eq') primarily because Unix is case-sensitive. I have been trying to convince the Common Lisp designers that they should consider providing a case-sensitive reader option so that Common Lisp will fit in on Unix systems. I would like to find out how important case-sensitivity is to you. I would appreciate it if all Franz Lisp users would let me know the answers to the following questions. Please send them to ucbvax!jkf or jkf@berkeley. Please do no send them to the usenet. I will keep track of replies and mail out a summary of the results. Poll: 1) Do you use the fact that Franz Lisp is case sensitive, that is do you use variables with capital letters? If yes, do you ever have two different variables whose names differ only by capitalization? [When I refer to 'variable' I mean a symbol to which you assign a variable to distinguish it from something used just for printing, as in (print 'Results). ] 2) If a case-insensitive Common Lisp was the only lisp available on your machine would you: a) use it without complaint about the case-insensitivity b) ask the person in charge of Common Lisp at your sight to add a switch to disable the code that maps all characters to the same case, thus making it possible for each user to make Common Lisp case-sensitive. 3) Do you prefer an operating system to be case-sensitive (like Unix and Multics) or case-insensitive (like Tops-10, Tops-20, Tenex, etc etc). End of poll. Please send replies to me [not the usenet] John Foderaro ucbvax!jkf jkf@berkeley  Date: 27 Aug 1982 0331-PDT From: Jeff Dean Subject: string package To: franz-friends at UCB-C70 Does anyone have a set of string manipulation routines for Franz (preferably similar to those available in Maclisp/Lisp Machine Lisp)? -------  Date: 18 Aug 1982 1732-PDT From: Jeff Dean Subject: hash table package To: franz-friends at MIT-MC I'm looking for a hash table package for Franz Lisp. Does anyone have one (suitable for public consumption)? Also, is there a list somewhere of generally available packages? It would be real nice to use existing software, rather than always creating things from scratch... Jeff Dean, AI&DS, (415)941-3912 DEAN@USC-ECL ( ...!ucbvax!DEAN@USC-ECL ) -------  Date: 18 Aug 1982 1732-PDT From: Jeff Dean Subject: hash table package To: franz-friends at MIT-MC I'm looking for a hash table package for Franz Lisp. Does anyone have one (suitable for public consumption)? Also, is there a list somewhere of generally available packages? It would be real nice to use existing software, rather than always creating things from scratch... Jeff Dean, AI&DS, (415)941-3912 DEAN@USC-ECL ( ...!ucbvax!DEAN@USC-ECL ) -------  Date: 25 July 1982 12:36-EDT From: Mark L. Miller Subject: Re: info on readers and benchmarks To: Kim.fateman at UCB-C70 cc: patel at UCLA-SECURITY, DGorman at BBNA, ACorreira at BBNA, LBlaine at BBNA, Kim.franz-friends at UCB-C70 In Reply to: Date: 21 Jul 1982 19:23:25-PDT From: Kim.fateman at Berkeley 1. There is an implementation of CGOL in Franz which provides a reader which may appeal to you. It is driven by a "top-down operator precedence " grammar specification. A copy of it could be mailed to you. 2. Dick Gabriel, RPG@su-ai, has a collection of benchmark programs, and some data on a variety of computers and systems. Where can we get these, what do they cost, and are they public domain? Thanks, Mark  Date: 22 July 1982 1945-EDT (Thursday) From: Mark.Boggs at CMU-10A To: kim.franz-friends at UCB-C70 Subject: VMS franz etc. Message-Id: <22Jul82 194538 WB70@CMU-10A> Could someone point me at the person currently handling the VMS/EUNICE implementation of FranzLisp. Also is there any reason why the strlen function is not included in the basic Franz? It is sort of silly to explode strings to find out their length when C-code exists which could do this faster and more efficiently (C-code which is used by the substring function anyway). Thanx, -Mark  Date: 22 Jul 82 15:29:11-EDT (Thu) From: Paul Broome (CSL) To: Kim.fateman at Ucb-C70 cc: tim.upenn at Udel-Relay, Kim.franz-friends at Ucb-C70 Subject: Re: transporting Franz to a non-Vax Which 68000? Sun? Fortune? If you're transporting Franz to a 68000 based machine I'd like to know more. Such information could influence my future purchases. Thanks.  Date: 22 Jul 1982 13:51:20-PDT From: Kim.fateman at Berkeley To: Kim.franz-friends@Berkeley Martin Griss pointed out that PSL is now running on an Apollo (which has a 68000 in it), and that he has started work on an HP9836 (which has a 68000 in it). Furthermore, there is some hope that a Franz/PSL compatibility package will emerge. This latter work is, I believe, being done at HP labs.  Date: 22 Jul 1982 13:04:13-PDT From: Kim.fateman at Berkeley To: broome@BRL Subject: Re: transporting Franz to a non-Vax Cc: Kim.franz-friends@Berkeley, tim.upenn@Udel-Relay first DUAL, which is now running UNIX, next (probably), SUN, maybe hp9836... it depends on who has UNIX and can deliver...  Date: 22 Jul 1982 09:09:56-PDT From: Kim.fateman at Berkeley To: tim.upenn@UDel-Relay Subject: Re: transporting Franz to a non-Vax Cc: Kim.franz-friends@Berkeley how about a 68000? We should be getting that to work in the next few months; in the process it will be made more independent of the VAX.  Date: 22 Jul 82 0:48:23-EDT (Thu) From: Tim Finin To: franz-friends at Ucb-C70 Subject: transporting Franz to a non-Vax Via: UPenn; 22 Jul 82 4:35-EDT Has anyone attempted to transport Franz to a machine other than a Vax? We are getting a version of Unix for a Univac 1100 (a 36 bit machine) and are very interested in bringing up Franz in it. The Unix was written at Bell Labs and appears to be rather complete. It has, of course, a C compiler. I am interested in hearing from anyone who has any experience or thoughts concerning the prospects of adapting Franz to another machine. Tim Finin (tim.upenn@udel-relay)  Date: 21 July 1982 1748-PDT (Wednesday) From: patel at UCLA-Security (Dorab Patel) Subject: info on readers and benchmarks To: franz-friends at berkeley I am interested in the following software, and would appreciate any information on any aspect of them. 1. A Lisp reader function (equivalent to the standard 'read') but which can be driven from a BNF (or other) specification of a grammar that describes acceptable input. This is similar to a parser, but I would also like to have the dynamic capabilities offered by the standard Franz reader (like associating functions/macros with characters and being able to change the syntactical meaning of symbols (a la syntax classes) 2. Are there any existing benchmarks available for Lisps. I am specifically interested in any that exercise Lisps in ways similar to the way CAD systems would do (e.g. lots of creation, modification, and traversing of structures). Thanks for any information that you may be able to provide, Dorab Patel UCLA (213) 825-7276 patel@ucla-security  Date: 21 Jul 1982 19:23:25-PDT From: Kim.fateman at Berkeley To: patel@UCLA-Security Subject: Re: info on readers and benchmarks Cc: Kim.franz-friends@Berkeley 1. There is an implementation of CGOL in Franz which provides a reader which may appeal to you. It is driven by a "top-down operator precedence " grammar specification. A copy of it could be mailed to you. 2. Dick Gabriel, RPG@su-ai, has a collection of benchmark programs, and some data on a variety of computers and systems.  Date: 6 Jul 1982 2319-PDT From: Zellich at OFFICE-3 (Rich Zellich) Subject: Mailing-list for "List of lists" update notices To: Zellich@All@Berkeley, mailing-lists.@Berkeley cc: Zellich@ZELLICH@Berkeley For those of you not previously aware of it, I maintain a master list of ARPANET mailing-lists/digests/discussion groups (currently 756 lines or ~29,000 characters) on OFFICE-3 in file: INTEREST-GROUPS.TXT For ARPANET users, OFFICE-3 supports the net-standard ANONYMOUS login within FTP, with any password. To keep people up to date on the large number of such lists, I have established a mailing list for list-of-lists \update notices/. I do not propose to send copies of the list itself to the world at large, but for those ARPANET users who seriously intend to FTP the updated versions when updated, I will send a brief notice that a new version is available. For those counterparts at internet sites who maintain or redistribute copies for their own networks (DECNet, Xerox, etc.) and can't reach the master by ARPANET FTP, I will send out the complete new file. I do \not/ intend to send file copies to individual users, either ARPANET or internet; our system is fairly heavily loaded, and we can't afford it. There is no particular pattern to the update frequency of INTEREST- GROUPS.TXT; I will occasionally receive a burst of new mailing-lists or perhaps a single change of address for a host or mailing-list coordinator, and then have a long period with no changes. To get on the list, send requests to ZELLICH@OFFICE-3, \not/ to the mailing-list this message appears in. Cheers, Rich -------  Date: 30 June 1982 0051-EDT From: Frank Boyle at CMU-10A To: .include:@Berkeley, FranzL.DST[F100BB00] at CMU-10A Subject: Production Systems Attention: franzlisp bboard GRAPES is a Goal Restricted Production System written in CMU Franz Lisp. GRAPES user's manuals are available upon request. Send requests to FARRELL on the CMU psychology vax (PSYA) or mail a request to: Robert Farrell Department of Psychology Carnegie-Mellon University Schenly Park Pittsburgh, PA. 15213  Date: 18 Jun 1982 20:10:53-PDT From: uucp at NPRDC >From davidson Fri Jun 18 18:56:30 1982 remote from sdcsvax Date: 18 June 1982 1856-PDT (Friday) Reply-To: davidson To: franz-friends@berkeley Subject: wanted: lisp shells I am looking for lisp packages which allow lisp to serve as a shell for UNIX. Please let me know if you have such a package, or if you know of someone else who does. Thank you, Greg Davidson  Date: 14 May 1982 20:12:40-PDT From: ucsbcsl!eggert at Berkeley To: ucbvax!frd@su-ai Subject: Vax prolog interpreter Cc: ucbvax!franz-friends@Berkeley I have transported Clocksin and Mellish's PDP-11 Prolog interpreter to the VAX. Its main advantage is for teaching: it is covered by their introductory text (Programming in Prolog, Springer-Verlag, 1981), and is somewhat compatible with Edinburgh DEC-10 Prolog. Its main disadvantage is that it runs slowly and has internal memory limitations: it is not suited for much practical work. My modifications to their system (and to some Berkeley Unix code) are gratis, but you must obtain permission from the original authors and send a copy of their letter to me. Write to Chris Mellish and Bill Clocksin Department of Artificial Intelligence University of Edinburgh Hope Park Square, Meadow Lane Edinburgh EH8 9NW UNITED KINGDOM Chris has recently moved to the University of Sussex; I don't have his new address, but the above should serve. Paul Eggert Department of Computer Science University of California Santa Barbara, CA 93106  Date: 13 May 1982 1457-PDT From: Fred Lakin To: franz-friends at MIT-MC FUGUE notes number 1, March 82, mentioned that 'several places are working on Prolog interpreters or Prolog-to-Lisp translators'. Does anyone have more specific information on these projects? Please mail any news regarding Prolog/Franz to frd@su-ai. Thanks.  Date: 29 April 1982 0956-PDT (Thursday) From: patel at UCLA-Security (Dorab Patel) Subject: program transformation software To: franz-friends at berkeley I am about to write a system to transform 'pure' Lisp programs and was wondering whether some such system already exists somewhere written in Franz Lisp. I would also be interested in any parts thereof. In particular, I am interested in any (tree) pattern matching functions that may exist out there. Thanks, Dorab Patel patel@ucla-security ucbvax!ucla-s!patel ucbvax!ucla-vax!patel  Date: 27 Mar 1982 19:35:16-PST From: Kim.jkf at Berkeley To: Kim.franz-friends@Berkeley Subject: alternate distribution of opus 38 These people have kindly offered to redistribute Franz Lisp sources: ----Date: 24 March 1982 1101-PST (Wednesday) From: patel at UCLA-Security (Dorab Patel) Once we get the sources for opus 38, I would be willing to redistribute the tape at cost for anyone in this area. My address is: Dorab Patel 3804A Boelter Hall Computer Science Department UCLA Los Angeles, CA 90024 phone: (213) 825 7276 (213) 825 8456 (message only) Dorab ----Date: 27 Mar 1982 1848-EST From: Sean McLinden Work-address: Decision Systems Lab, University of Pittsburgh Work-phone: 412-624-3490 Assuming that everything goes ok, we will be glad to provide anyone with a copy of Franz who might not have access to it otherwise, at no charge (if they have their own tape). If not, we can loan a tape (but prefer not to do that by mail). Thanks Sean -------  Date: 24 Mar 1982 15:58:30-PST From: Kim.jkf at Berkeley To: Kim.franz-friends@Berkeley Subject: bug reports and question I don't mind answering questions about franz, but I don't want to send the answers to everyone in franz-friends because I know that there are people on franz-friends who would leave the mailing list if they got too much mail. Thus I've set up 'franz-bugs@berkeley'. That mail will just go to people here at berkeley who are willing to answer bug reports. Periodically we will send out a digest of bug reports and replies to franz-friends.  Date: 24 Mar 1982 14:05:52-PST From: jock@Diablo@Sumex-Aim at Berkeley Mail-from: SU-NET host SU-HNV rcvd at 24-Mar-82 1319-PST Date: 24 Mar 1982 13:17:43-PST From: jock@Diablo at Sumex-Aim To: franz-friends@berkeley Subject: Help woth the function PROCESS To whom it may concern, The manual is a little vague. I want to run a separate shell where I can send commands (like "rm foo") and receive the output back. Is there someone that can tell me how to do this? Do I need to open the pipes of does PROCESS do it for me? What should the function call look like? Thanks Jock  Date: 24 Mar 1982 0127-PST From: Gunther Goerz Subject: Mailing address To: franz-friends at MIT-MC CC: GXG at SU-AI Please note my current mailing address (no longer UCLA): Guenther Goerz Univ. Erlangen-Nuernberg, RRZE Martensstr. 1 D-8520 Erlangen W. Germany Thans!  Date: 23 Mar 1982 22:12:17-PST From: Kim.jkf at Berkeley To: Kim.franz-friends@Berkeley Subject: opus 38 distribution We are now ready to distribute Franz Lisp Opus 38. We are distributing the source for the lisp system (lisp, liszt, lxref and The Franz Lisp Manual) and typeset copies of The Franz Lisp Manual. The manuals must be sent by U.S. Mail; the source for the lisp system can be obtained using FTP over the ArpaNet, or from a magnetic tape sent through the U.S. Mail. The source for the lisp system includes Makefiles which will build the lisp system from the source alone on systems which run Berkeley 4bsd Vax Unix. This distribution may also run on other Vax Unix systems although you will need the Berkeley version of the assembler (which we don't supply). VMS users can run the lisp system only with the Eunice library package (write to David Kashtan, kashtan@sri-unix: or Mary Kopecky Arificial Intelligence Center SRI International 333 Ravenswood Ave. Menlo Park, CA 94025 for more details.) If you obtain a copy, you are free to "improve" it or make copies for other people. We would appreciate hearing about improvements and further distributions. The lisp system source is distributed in one of two ways: 1) The Arpanet The lisp system source is distributed as a 1.7 megabyte shell script. The script is broken up into nine files, each slighly less than 200K bytes. All files contain only Ascii characters (0001-0177). 195 -rw-r--r-- 1 jkf 199020 Mar 23 15:22 opus38.aa 195 -rw-r--r-- 1 jkf 199005 Mar 23 15:22 opus38.ab 195 -rw-r--r-- 1 jkf 199017 Mar 23 15:24 opus38.ac 195 -rw-r--r-- 1 jkf 199001 Mar 23 15:24 opus38.ad 195 -rw-r--r-- 1 jkf 199034 Mar 23 15:25 opus38.ae 195 -rw-r--r-- 1 jkf 199051 Mar 23 15:25 opus38.af 195 -rw-r--r-- 1 jkf 199021 Mar 23 15:25 opus38.ag 195 -rw-r--r-- 1 jkf 199004 Mar 23 15:26 opus38.ah 184 -rw-r--r-- 1 jkf 187824 Mar 23 15:26 opus38.ai These pieces are on the ucb-c70 arpanet host (directory /users/lisp/lispuser). If you don't have an account on the ucb-c70 and would like to ftp these files, mail me (jkf@berkeley) a message and let me know what password you would like the account to have. When the account is set up I will mail you a reply. (We are currently trying to find a arpanet machine with an anonymous login to store our files.) After you get the files, just say: cat opus38* | sh and the files will be extracted. Then read the file ReadMe for instructions. 2) Mag Tape If you can't get to an Arpanet host, we will send you the distribution by magnetic tape in tar format. There are three options: a) we supply the tape: we will purchase a 1200 foot tape, put the distribution on it and mail it to you. First you must send us $200 for the tape, copying, mailing. A manual will be included. Eloquent pleas of poverty will be considered. b) you get it from someone else who got it from us: we will forward to you a list of other UNIX sites wishing to provide distribution (any volunteers?) for less. c) you wait for the next (4.2 BSD) distribution, scheduled for the fall. The lisp source contains the source for the lisp manual in nroff/troff format. It also contains an nroff'ed version of the manual. If you would like a copy of a phototypeset version, send us $15 and we will mail you one. The manual is copyrighted, but you may make copies of it as long as the copies are not sold for a profit. The address to send checks to is Keith Sklower EECS/Computer Science Division 524 Evans Hall University of California Berkeley, CA 94720 All checks should be made out to "Regents, University of California." We require pre-payment.  Date: 23 Mar 1982 11:49:03-PST From: Kim.jkf at Berkeley To: Kim.franz-friends@Berkeley Subject: mailing list moves The franz-friends mail lists have moved to Berkeley so that it is easier for me to handle your requests. The lists are: franz-friends@berkeley to reach all people interested in franz franz-composers@berkeley to reach only those who are maintainingg franz. franz-friends-request@berkeley to reach people who can alter the mailing lists or answer questions about the list. The addresses franz-friends@mit-mc, franz-composers@mit-mc and franz-friends-request@mit-mc will still work and will just send the mail on to Berkeley. John Foderaro (jkf@berkeley)  Date: 17 March 1982 1514-PST (Wednesday) From: patel at UCLA-Security (Dorab Patel) Subject: addition to mailing list To: franz-friends at mit-mc Please add me to your mailing list. Thanks, Dorab  Date: 19 February 1982 20:51-EST From: George J. Carrette Subject: booting of cgol To: KIM.jkf at UCB-C70 cc: FRANZ-FRIENDS at MIT-MC, Kim.fateman at UCB-C70 I apologize for thinking that just because it was trivial to bring up on the Lispmachine and NIL it would be trivial to bring up in Franz. The same CGOL source file runs on the LISPMACHINE, Maclisp, and NIL. It *should* have been trivial to bring it up in Franz. If you claim that it was not trivial, then I will take your word for it, since you are a Franz expert. For some reason you also chose to maintain an entirely different source, I bow to your special Franz expertise on that question too.  Date: 19-Feb-82 15:31:32-PST (Fri) From: KIM.jkf@Berkeley (John Foderaro) Subject: booting of cgol Via: KIM.BerkNet (V3.73 [1/5/82]); 19-Feb-82 15:31:32-PST (Fri) To: gjc@mit-mc Cc: franz-friends@mit-mc, Kim.fateman@Berkeley Your code was looked at but for the most part was not used. We certainly don't need fancy rubout handlers, we have an operating system for that. We don't have sfa's so your I/O code was useless. It was not a trivial operation to get it running, as you have implied.  Date: 19 February 1982 17:17-EST From: George J. Carrette To: KIM.FATEMAN at MIT-MC cc: FRANZ-FRIENDS at MIT-MC You mentioned in Franz-friends that JKF did the bootstrapping which brought CGOL up in Franz, this is not correct, as you well know. [It wasn't long ago that you asked me to help you do this!] I did the rewriting of CGOL and set up the bootstrapping technology which brought up CGOL on the Lispmachine, and which trivially allowed it to be brought up in other lisps. Please what your step in the future.  Date: 19 Feb 1982 12:25:11-PST From: Kim.fateman at Berkeley To: franz-friends@mit-mc FUGUE Notes An occasional publication of the Franz Lisp User Group under Unix and Eunice (FUGUE) Number 1 (March, 1982) edited by Richard J. Fateman University of California Berkeley CA 94720 USA fateman@berkeley _1. _W_e_l_c_o_m_e! It seemed about time to publish the first of these newsletters, since we have accumulated a suite of short com- positions, and moved on to Opus 38. We would also like to relay to others such information as has been forwarded to us. The reports of projects at Berkeley (and elsewhere) may strike sympathetic chords with other research. _1._1. _H_o_w _m_a_n_y _p_l_a_y_e_r_s _a_r_e _w_e? It is hard for us to know how many people are using Franz Lisp. Franz Lisp has been distributed to at least 250 UNIX 4.1BSD sites, many of which have multiple CPUs. There are an estimated 750 VAX 11/780 and 11/750 systems capable of running Franz Lisp under UNIX. There are probably a few dozen sites using Franz under Eunice, a UNIX simulation package developed by David Kashtan at SRI. Judging from the FUGUE mailing lists there are at least 150 people interested in Franz News. (There are 100 non-Berkeley names on the Arpanet list "franz-friends@mit-mc" and some of those names are in fact mailing lists on other machines. There are about 40 additional sites requiring postal service.) Some are undoubtedly intent on cheering or jeering from the side- lines, and some may be mail junkies, but many users (includ- ing the students who must write programs in Franz Lisp for class work) are not represented directly. While we at Berkeley can afford active communication with only a handful of sites, we know of a few dozen users who have various application programs running in Franz. _1._2. _A_n _i_n_v_i_t_a_t_i_o_n We invite our colleagues who are designing alternative Lisp or Lisp-like systems to provide comments in future ____________________ 9 UNIX, Eunice, Franz Lisp, may be trademarks of Bell Labs, SRI Int'l, and Univ. of Calif. 9 newsletters. In particular, we hope to see information on Interlisp, NIL, T, Ylisp, PSL, and "Common Lisp" for the VAX. _1._3. _T_h_e _s_t_r_u_c_t_u_r_e _o_f _t_h_i_s _n_e_w_s_l_e_t_t_e_r We have no particular format in mind for this newsletter, although we suspect the headings (e.g. bugs, fixes) will re-appear in the future. For this issue, we mention some of the applications written on top of Franz in sections below. Future editions of this newsletter, will, we hope, describe other applications, or perhaps highlight one already mentioned. _2. _W_h_a_t'_s _N_e_w? Since the earliest release of Franz, there have been several additional chapters added to the manual, and possi- bly interesting new reports of Lisp applications. These are (1) _C_M_U_e_d_i_t, _C_M_U_t_o_p_l_e_v_e_l, _C_M_U_d_e_b_u_g_g_i_n_g: Is this new? It was in 4.1BSD, but may not be known to you all. Included are a somewhat streamlined version of the Interlisp structure editor, a history-keeping top-level, and some front-end to the debugging system. (2) _F_P: An implementation of John Backus' Functional Pro- gramming notation. Written by Scott Baden at Berkeley, it is described in a mostly machine-reproducible memo available with the code. (3) _P_E_A_R_L: A simple and efficient data base system for artificial intelligence natural language programs, from the school of Prof. Robert Wilensky at Berkeley. It is up and running at Fairchild. Watch this space for PHRAN, a phrase analysis program. (4) _C_G_O_L: This is a replacement for the lisp reader which provides an infix syntax for arithmetic, iteration, (etc), an extensible parser for whatever was left out, and for the fun of it, a fierce lesson in software bootstrapping technology. CGOL is, of course, written in CGOL. Vaughn Pratt is the author, although John Foderaro at Berkeley did the bootstrap. The documenta- tion is available in a separate memo (and in machine readable form with the code.) (5) _F_R_L: Frame Representation Language: (Roberts and Gold- stein, MIT), was moved from Maclisp to Franz Lisp by Steve Rosenberg and Douglas Lanam, working at Lawrence Berkeley Laboratory, and refined since then at Hewlett Packard Research Center, where they now work. 9 9 (6) _M_a_c_s_y_m_a: Macsyma is an algebraic manipulation system, originating primarily with the work done by the Mathlab Group at MIT, and transported to the VAX by Richard Fateman, Keith Sklower, and John Foderaro. It is available currently by first signing a test-site agree- ment with MIT, and then obtaining a tape (from Berke- ley). (7) _A_I _P_r_o_g_r_a_m_m_i_n_g A package of programs providing compa- tibility with the Lisp dialect used in the text "Artif- icial Intelligence Programming" by Charniak, Riesbeck, and McDermott, has been developed by Brown University (under the baton of Matt Kaplan). A revised and illus- trated manual "Franz Lisp ... The Manual" describing the Brown variations is being maintained by Graeme Hirst. Many features seem to be in the style of UCI lisp, which is also supplied by a library file of func- tions. (DE took the FUN out of DEFUN). (8) _A_d_v_i_s_e: The advice-taking system from Interlisp has been converted to run under Franz by Lisa Rau at Berke- ley. Advise uses the CMU version of the Interlisp edi- tor, and thus is slightly different in its "location" performance. (9) _P_r_o_l_o_g: There appear to be several places working on Prolog interpreters or Prolog-to-Lisp translators. We do not yet have one on hand, but would consider adopt- ing one. (10) _I_n_t_e_r_l_i_s_p _C_o_m_p_a_t_i_b_i_l_i_t_y: There seem to be a number of people working on translation aids. We have as a starting point, a number of functions which can be read into the compiler to help it gobble DEFINEQ's, for example. We hope others working in this area will volunteer more code. _3. _A_v_a_i_l_a_b_i_l_i_t_y Some readers may be curious as to how changes to Franz will be promulgated. We are attempting to set up an Arpanet site, perhaps at Berkeley, which will support anonymous login for file transfer. Then persons able to tap into the Arpanet or Csnet can obtain fresh copies of source, and perhaps even binary code. If you receive this note via com- puter network, you will hear of progress. Most people "off-net" should get periodic new releases as the Berkeley Software Distribution progresses from 4.1 to 4.2. For peo- ple who cannot wait (We expect the successor to 4.1BSD to appear in September, 1982) or others, typically Eunice sites, who do not get "nBSD" we will continue to make mag- netic tapes as needed. As in the past we will charge $200 as a tape copying fee, including one hard-copy of the documentation. This charge is for the copying service, not the software, and we have no objection to a recipient making further copies and redistributing. In particular, we have no objection to SRI giving out versions of Franz in combination with Eunice. If others would care to distribute tapes at lower cost, we would be pleased to cooperate. So far as possible, we will attempt to distribute work- ing versions of programs which appear to be generally use- ful, which are given to us in machine readable format along with documentation, and without restriction as to further distribution. _4. _P_r_o_j_e_c_t_s _a_t _B_e_r_k_e_l_e_y This section mentions a few of the continuing projects at Berkeley. This is not intended to be complete. (1) James Larus is working on a version of Masterscope for Franz with the essential difference that the Ingres relational data base system is being used instead of an ad-hoc lisp system. This may make it possible to deal with much larger program profiles, or it may be unac- ceptably slow. A side effect will be a set of routines for interfacing to Ingres. (2) Various students are working on graphics interfaces for Franz. While an "Alto Terminal" system was constructed at CMU, very few others (perhaps no others) can make use of it because of the hardware requirements. We have two BBN BitGraph terminals (768 by 1024 bits) which can be used for line or raster graphics,audio output, etc. While there may be, at the moment, even fewer BitGraphs than Altos, at least we have them at Berkeley. We expect to try out a few other workstation/graphics systems (SUN) in the near future. (3) Work being done by Scott Morrison will provide a super- set of the "Common Lisp" specifications for numeric data types. This will be based on the IEEE floating point standard, currently software simulated on the VAX via C programs. (4) A group of students (David R. Barton, John Foderaro and Neil Soiffer) are designing and implementing a pro- gramming language which provides data abstraction in a mathematical setting. This may be the basis for a future algebraic manipulation system, and should have other uses. (5) Along with investigators at Lawrence Livermore Lab, interactive systems for combined algebraic and numeric manipulation are being set up. For example, minimiza- tion via MINPACK numerical routines, and solution of systems of ordinary differential equations, are being studied. (people: D.C. Halbert, J.D. Halpern, T. Einwohner). A variety of programs for CAD and VLSI are being used, in some cases, quite heavily, at Berkeley, but their authors are not yet ready to distribute them. We understand that Franz is being used for VLSI work at MIT and other loca- tions. We hope to have more information prepared for a later newsletter. Similarly, there may be versions of AI programs described later. _5. _M_o_d_i_f_i_c_a_t_i_o_n_s _a_n_d _B_u_g _F_i_x_e_s For Opus 38, there are some changes have been made to setsyntax, the reader, the compiler, "format" These are described in this section, written by John Foderaro. _5._1. _B_u_g _F_i_x_e_s The following bug fixes and new features are in the latest Lisp system, Opus 38: (1) If _s_y_s_c_a_l_l returns a small integer, it will do so from the small integer table rather than allocating a new integer. (2) The _d_o function will properly handle the _g_o pseudo- function. (3) We added new functions <&, =& and >& which are like <, = and > except their arguments must be fixnums. The compiler can use this information to generate better code. (4) The function which handles &rest, &aux and &optional forms within the formal variable list of a _d_e_f_u_n was rewritten to recognize cases where it can avoid gen- erating an lexpr. (5) Two bugs in error handlers were found and fixed. One was in the _e_r_r function itself, the other in the inter- nal function _I-_t_h_r_o_w-_e_r_r which prevented _u_n_w_i_n_d-_p_r_o_t_e_c_t from working correctly. (6) It was discovered that any non local transfer through an _u_n_w_i_n_d-_p_r_o_t_e_c_t would be continued as a *_t_h_r_o_w. This was fixed. 9 9 (7) Some users didn't like the fact that the compiler _p_u_r_c_o_p_y's literals. Thus there is a new symbol, $_p_u_r_- _c_o_p_y_l_i_t_s which if nil will prevent the _p_u_r_c_o_p_y. (8) _l_o_a_d will no longer disable garbage collection during a load. The problem we ran into was that if a _d_u_m_p_l_i_s_p was done during a load, the garbage collector would remain disabled in the _d_u_m_p_l_i_s_ped file. (9) We have improved the reader's error messages when it read an incorrect period or right parenthesis. (10) When allocating a large amount of space, the system no longer tries to clear all of it with one movc5 instruc- tion, because the hardware limits the range of that instruction. (11) The sharp-sign macro is now user extensible via the _d_e_f_s_h_a_r_p function. (12) We fixed a bug in _r_e_a_d_l_i_s_t so that if an error occurs during the readlist, the file descriptor will be deal- located. (13) We fixed a bug in the internal character macro reader, so that if the macro switches the port it is reading from, this will not confuse the function which called the macro. (14) We fixed a bug in _f_a_s_l which caused the message "File not in new fasl format" to occur when _f_a_s_ling in large files. The problem was that the number of functions in a large file would overflow the fixed sized table in the _f_a_s_l function. The table size was increased, and a more appropriate error message is printed should that table overflow. (15) We fixed a bug in bignum division which would rarely occur when the leading bigit of the quotient and divi- sor were the same. (16) We fixed a bug in eval so that eval now protects the definition of an interpreted function before starting to execute it. (17) We changed the lisp reader to treat each part of the syntax code independently, thus allowing for more user control over the reader and printer. This is explained further below. 9 9 _5._2. _R_e_a_d_e_r _C_h_a_n_g_e The most visible difference between Opus 37 and Opus 38 is the lisp reader. The syntax code for each character is now viewed as a triple: character class, escape requirement, and separatorness. The character class describes the syn- tactic category to which the character belongs. The escape requirement describes in which cases the character should be escaped when printed. The separatorness says whether this character separates symbols. To reduce user confusion, and to make it easy to extend the reader at a future time, the user describes a syntax class with a name rather than a number. The user is free to add syntax classes if the built-in ones are not sufficient. The _g_e_t_s_y_n_t_a_x function will return the syntax code of a character as a name. The function (_s_t_a_t_u_s _s_y_n_t_a_x _c) is now an error, because we want to prevent the user from ever seeing the number associated with the syntax name. Also, the actual numbers were forced to change, so that the result of (_s_t_a_t_u_s _s_y_n_t_a_x _c) in Opus 38 is probably not what an existing program expects, and rather than return a strange value, we felt it was better to signal an error. For compatibility, the _s_e_t_s_y_n_t_a_x function will accept Opus 37 syntax code numbers as the syntax class, and will convert them to the proper name; however we encourage all code which uses numbers to convert to names. _5._3. _N_e_w _p_a_c_k_a_g_e_s The _f_o_r_m_a_t, _l_o_o_p, _C_G_O_L, and _d_e_f_s_t_r_u_c_t packages have been moved to Franz from the Maclisp world. _5._4. _O_t_h_e_r _m_o_d_i_f_i_c_a_t_i_o_n_s (1) The garbage collector will now collect string space on a page by page basis. It is possible to disable the string garbage collection with a call to _s_s_t_a_t_u_s. (2) The -a switch has be added to the lisp compiler. When a file compiled with -a is _f_a_s_led into lisp, a property is added to each function defined which describes the source file of that function, when it was compiled and how many arguments it expects. _6. _O_t_h_e_r _m_a_c_h_i_n_e_s A Motorola 68000 implementation of Franz is being worked on by Keith Sklower. We expect that it will appear first on a system supporting the UNIX operating system, and that it may not support more than a 2 megabyte address space unless memory mapping is available. There have been are occasional flirts with the IBM world, especially UNIX sys- tems such as supported by Amdahl, but there are no definite plans at this time. _7. _C_o_m_m_o_n _L_i_s_p A new Lisp named "Common Lisp" based loosely on MacLisp, MIT Lisp Machine Lisp("Zetalisp"), NIL, and SCHEME, but incorporating yet newer features is a topic of study of a group lead by Guy Steele Jr. at CMU. Guy has assembled a voluminous draft manual, and several subgroups seem to be working on (getting funding for) implementations for machines as diverse as the IBM 4341, DEC20, MC68000, Perq1A and of course the VAX. We expect that many, if not all, of the features of Common Lisp, will be supported in Franz, either by work at Berkeley, or elsewhere. We are however, waiting until the manual is more settled and funding ques- tions are resolved, to say more than this. 9 9  LIZ@MIT-AI 02/17/82 14:20:37 Re: a new production system To: franz-friends at MIT-MC This is to announce YAPS (Yet Another Production System). It is currently implemented in Franz Lisp and is running on the Univ of Maryland's VAX 11/780. It has a discrimination net similar to the net used in OPS5 and runs at a comparable speed. In addition, YAPS allows arbitrary tests on the left hand sides of productions (using any number of variables) and arbitrary actions on the right hand sides. If you're interested in YAPS, a Maryland Tech Report will be available shortly, TR-1146, and will be a user's manual. Also, you may contact me at liz@mit-ai. We also have available a flavor package that contains a reasonable subset of the things described in the MIT Lisp Machine Manual. This was written by Rich Wood. Either contact me or rwood@isib. Liz Allen Univ of Maryland Dept of Computer Science College Park, MD 20783  Date: 17 Aug 1981 (Monday) 1656-EDT From: FININ at WHARTON-10 (Tim Finin) Subject: non-standard readmacro behavior... To: franz-friends at MIT-MC I want to change the syntax of ' so that it will act like an alphabetic character if it is embedded within an atom or is at the end of an atom. Thus 'foo is (quote foo) but foo' is foo'. A ' before a list or a ' surrounded by seperators will still act as a readmacro for the quote function. Offhand, I don't see a reasonable way to do this given the Franz character syntax situation. Any ideas? Tim  Date: 17 Jul 1981 17:06:22-PDT From: CSVAX.jkf at Berkeley To: FININ@WHARTON-10 cc: franz-friends at MIT-MC Subject: Re: sxhash, Franz function info and the maclisp-style array package. In-reply-to: Your message of 17 Jul 1981 1347-PDT (Friday). From: FININ@WHARTON-10 Subject: sxhash, Franz function info and the maclisp-style array package. [1] Does Franz have a hashing function like maclisp's SXHASH? If not, has anyone written one? There isn't a distributed version of sxhash. We wrote one for use in Vax Macsyma but it isn't any better than something you could write in a minute. [2] For a compiled function or a built-in system function, is there any way to get its type and the number of arguments it requires? You get get the type of function using the function 'getdisc' (get discipline) on the binary object which is stored in the function cell [getd] of a symbol. You can't determine the number of arguments. [3] We've been having problems with the MacLisp compatable array package - it doesn't work! Does anyone have a debugged version? Can you be more specific? We use it in Vax Macsyma without any problems. Personally I feel that Maclisp arrays were invented by a madman and no new code should be written using them. -- john foderaro  Date: 17 Jul 1981 (Friday) 1642-EDT From: FININ at WHARTON-10 (Tim Finin) Subject: sxhash, Franz function info and the maclisp-style array package. To: franz-friends at MIT-MC Three questions that some of the friends of Franz may be able to answer: [1] Does Franz have a hashing function like maclisp's SXHASH? If not, has anyone written one? [2] For a compiled function or a built-in system function, is there any way to get its type and the number of arguments it requires? [3] We've been having problems with the MacLisp compatable array package - it doesn't work! Does anyone have a debugged version? - Tim -  Date: 7 Jul 1981 08:11:10-PDT From: CSVAX.jkf at Berkeley To: CSVAX.msgs@Berkeley Subject: new lisp installed Cc: CSVAX.lisp@Berkeley A new lisp has been installed which contains an improved internal mechanism for saving and restoring contexts. Old compiled code should be recompiled. We have incorporated the cmu step and fixit packages. You can single step your lisp program through compiled and/or interpreted code, and when an error occurs you can examine the entire evaluation stack and determine the value of variables at any state in the evaluation. Documentation on the step package is in chapter 14 of the Lisp Manual [thus you can type (help 14) within lisp to see it on-line] and documentation on the fixit package is in chapter 15. Stop by and see me for hard copies of these chapters.  Date: 23 Jun 1981 14:42:11-PDT From: CSVAX.fateman at Berkeley To: franz-friends@mit-mc Subject: updates to code and manual We are assuming that people who send us code and documentation (most notably, CMU), are willing for us to reproduce machine-readable copies, and hardcopies, on a cost recovery basis, so long as any expressed copyright notices accompany their sections. If there is a problem with this, please let us know. We intend to bring some of the CMU and UCI Lisp stuff into the manual, along with some corrections of typos. Some of the CMU sections are probably not useful for most sites (Alto Terminal package, IPC), and will probably be mentioned but not included in the default hardcopy. (Thanks to Lars Ericson, Don Cohen, Mitch Marcus, J. Eugene Ball, Rick Raschid, Dave Touretzky, and others for contributions.)  Date: 11 June 1981 1543-EDT (Thursday) From: Peter.Lucas at CMU-10A To: franz-friends at mit-mc Subject: list update Message-Id: <11Jun81 154349 PL70@CMU-10A> CMU has a local bulletin board intended for Franz-friends messages. Would you please mail a copy of the notices to the following: To: BBoard at CMU-10A Attention: FranzLisp BBoard Note that The Attention field is required or else it will end up on our local BBoard. Also, when you do this, you may remove my personal name from the list since I will be able to pick up the notices from the BB. Thanks -PAL  Date: 8 Jun 1981 17:15:55-PDT From: CSVAX.fateman at Berkeley To: franz-friends@mit-mc Subject: multics vs vax I agree with JIM that if multics fits your needs, you should use it. For those of you who already have a VAX, you may feel some reluctance to use a unique "other" machine for algebraic manipulation. The VAX 11/780 is, we have found, a decent machine for running Lisp and macsyma. Given that memory is cheap and getting cheaper, and that this seems to be the most important resource to make Lisp (and lots of other things) run faster, I think it will continue to get better. We are buying VAX memory at about $7k/megabyte, I think. Thus the difference, for macsyma, between a small machine .5meg and a large machine 4 meg is not much money. (You can get 8 meg by buying an expensive controller from DEC, or waiting for 64k chip memory boards). We have not gone above 4 meg on any of our machines; 3 or 4 macsymas are less of a load than lots of other things (3 or 4 CIFplots, 3 or 4 troffs). I am reminded, however, of the argument I have made in the past with owners of cdc7600's who wanted to run macsyma on it, and I argued that the machine was unsuited to running lisp; they argued that since the 7600 was, to them, free, it was the most suitable machine. Many people no doubt feel that their VAX is free; a few people feel that multics is free. (I don't mean to compare the 7600 with the Honeywell machine directly) Just that there are lots of other considerations than merely technical (i.e. does it work?).  Date: 8 June 1981 19:43-EDT From: James E. O'Dell Subject: problems with the deal To: FRANZ-FRIENDS at MIT-MC Date: 4 Jun 1981 08:42:53-PDT From: CSVAX.fateman at Berkeley 2. Multics macsyma is neither pleasant nor cheap, by my reckoning, especially since mit-mc is free, if you can get on. (this is possibly going to improve). As I have a personal stake in this i feel I should comment on this. I like multics a lot, it has semi infinite address space, has ~ 1/2 the absoulte cpu speed of MC's KL-10 and an awful lot of nice software, including a BONAFIDE EMACS written in lisp. I do a lot of work there and enjoy it. If I had my own VAX and used macsyma every day I would get a license. If I used macsyma 1 day a week I might not bother. If I used it once a month I would surely use Multics. By a computer scientists point of view the Multics user interface may seem primitive but most "serious" macsyma users have little trouble with it. If I were considering getting a Macsyma for my vax I'd surely try out the one on Multics first, Then I'd also want to try out one on a VAX, I'm told that 4 Macsyma's is about all a BIG Vax can handle, although RJF can say more about that. At one point on a smaller machine with only 2 cpu's and less memory Multics ran between 10 and 15. Look before you leap and there will be less chance of dissapointment.  Date: 4 Jun 1981 08:42:53-PDT From: CSVAX.fateman at Berkeley To: SHRAGE@WHARTON-10, franz-friends@MIT-MC Subject: problems with the deal 1. In my opinion, the agreement as stands will probably not be signed by any lawyer. You are thus in a position to forge your own license. This is a good way to waste 6 months, if your lawyers are like ours. 2. Multics macsyma is neither pleasant nor cheap, by my reckoning, especially since mit-mc is free, if you can get on. (this is possibly going to improve). 3. At the moment, Berkeley is doing all the tape-writing, but we are trying to get MIT up to speed on this.  Date: 4 Jun 1981 (Thursday) 0112-EDT From: SHRAGE at WHARTON-10 (Jeffrey Shrager) Subject: Here's the deal on Vaxyma: To: franz-friends at MIT-MC I spoke to JM this afternoon and the method of obtaining Vaxyma is as follows: 1) Obtain a license agreement from LCS for Vaxyma. Write to Professor Joel Moses The Laboratory for Computer Science 545 Tech Square. Cambridge, Mass. 02139 2) Have the agreement reviewed by you university counsel and sign it and return it. They send you a tape, I assume. Price: Vaxyma is free to universities (I did not get figures for businesses) but (and here's the catch) you MUST pay a $2000/yr. support fee which includes software support and consulting. If you just have some differentials to run a better idea is to get a multics accound for a mere $4/hr line time by calling the multics admin people at (617)253-7848. -- May all your series converge. Jeff  Date: 31 May 1981 (Sunday) 0041-EDT From: SHRAGE at WHARTON-10 (Jeffrey Shrager) Subject: Prolog (Qlog) for Franz -- An initial release To: franz-friends at MIT-MC Some hacker (who shall rename mainless) has modified Jon Komorowski's Qlog system (originally in interlisp and later hacked for CADR) to run on Franz. It can be found on [4115,40]QLOG.FTP @ WHARTON-10. I think that our FTP server needs no login thus you can snarf the file at will. We run this under Franz on VMS but it can be easily modified to run on Unix, I assume. Warning... This is a Q&D implementation and we will have it recoded someday with much of the cruft removed. Believe it or not, there IS doc as far as it goes. I think that it even matches the code! If anyone has a burning interest in this feel free to snarf it. If you don't know ProLog it won't be of any use to you -- there is no tutorial. I have added "either" to Komorowski's original code as well as fixing up some of the original cruft but it still has problems. The most notable is the lack of a NOT function. If you take a copy please tell me and we'll form a SIG to discuss enhancements. Thanks and good luck -- Jeff  Date: 29 May 1981 08:47:44-PDT From: CSVAX.fateman at Berkeley To: SHRAGE@WHARTON-10, franz-friends@MIT-MC Subject: Vaxyma -- let's not all attack MIT at once! It is not our intention to indiscriminately hand out copies of the macsyma source, since we (perhaps foolishly) agreed, several years ago, not to do so, (an agreement with MIT). This does not prevent others from getting the (same) source from mit-mc. Anything other than the mit source can be obtained from us (including Franz, its compiler, set-up "makefiles" etc.) it is not trivial to get all the sources from MIT. However, if there are any people with government contracts who need macsyma on a vax, they should contact me directly, if JM has not been responsive. Perhaps with the help of government sponsors, something can be shaken loose. (esp. Dept. of Energy). If you are just curious about macsyma, probably you should hold off for a while. If it is an;y comfort to you, I have copies of very strongly worded letters from Peter Denning, pres. of ACM, to JM, protesting the withholding of software developed under gov't sponsorship. [Well, Purdue, got its copy, anyway...]  Date: 29 May 1981 (Friday) 0307-EDT From: SHRAGE at WHARTON-10 (Jeffrey Shrager) Subject: Vaxyma -- let's not all attack MIT at once! To: franz-friends at MIT-MC OK, OK -- I've gotten about thirty messages and I'm sure all the others have as well... If we all attack MIT for permission to run Vaxyma at once noone will get anywhere (sorry, "no one"). I am trying to fund out exactly how the Macsyma people feel about our snarfing Berkeley's Franz Macsyma system and will report as soon as I find out. -- Jeff  FONER@MIT-AI 05/27/81 23:04:03 Re: VAXIMA (VAXYMA? VAXSYMA?) and replies to my question To: Franz-Friends at MIT-MC CC: FONER at MIT-AI I've gotten about a half dozen replies to my request for information on VAX MACSYMA, and expect some more. For anyone who is interested, I'm archiving the replies in USERS1;FONER VAXIMA at MIT-AI. I'll tell the list when the replies trickle off, if you're interested but don't want to read the file until things quiet down. For those who've responded so far, thanx muchly.  Date: 26 May 1981 08:29:17-PDT From: CSVAX.fateman at Berkeley To: FONER@MIT-AI Subject: MACSYMA on a VAX? Cc: Franz-Friends@mit-mc Such a wild and crazy rumor... who could possibly believe it? actually, macsyma has been running on Vaxes since October, 1979, and on VAX/VMS since April 1980. At a number of locations. It was moved to VMS during the first 3 weeks of April 1980 for a demonstration at DEC. It has been running at Los Alamos and at MIT on VAX/VMS. SRI's involvement: we were early customers of Eunice, and helped debug it. Franz runs on 11/780s and 11/750. It is nice to have Eunice around, but not essential to run interpreter or code compiled by other people.  FONER@MIT-AI 05/26/81 00:25:18 Re: MACSYMA on a VAX? To: Franz-Friends at MIT-MC I heard a wild rumor today. Is it true that SRI has gotten MACSYMA to run using Franz LISP on a VAX? What do you SRI people say about this? If so, I'm kinda interested. I dunno if I'd be interested enough to acquire a copy if it costs (we don't get much into field theory equations or similar good uses for MACSYMA where I work), but it might come in handy if it runs and is economical. Available are two 11/780's running VAX/VMS Release 2.2 and one 11/750 running EUNICE under VAX/VMS Release 2.2. All can run Franz, I believe. Thanx for any info people can provide. Maybe we should spread the word to INFO-VAX if this is not just a rumor?  Date: 14 May 1981 (Thursday) 1645-EDT From: FININ at WHARTON-10 (Tim Finin) Subject: Inter-dialect Lisp translation (esp. Interlisp -> Franz) To: franz-friends at MIT-MC I am involved in a project to translate a large InterLisp system to run in Franz Lisp. We envision this process as having two components: (1) a system which translates InterLisp source code to Franz Lisp source code, and (2) a set of packages which create a run-time environment in Franz Lisp which is more similar to InterLisp's. One of our goals is to produce a translation system which will allow us to take a new release of the InterLisp version and produce a Franz version with less than one man-week's worth of effort. I am very interested in hearing about: o existing translators which go from one dialect of Lisp to another (especially from InterLisp to FranzLisp or MacLisp) o People's experience with automatic translators - how good can they be? o existing packages which implement standard InterLisp utilities (e.g. Record package, Decl package) - Tim Finin -  Date: 8 Mar 1981 10:28:23-PST From: CSVAX.jkf at Berkeley To: CSVAX.lisp@Berkeley Subject: new liszt autorun feature The -r switch to liszt causes it to add a small bootstrap loader to the beginning of the object file it creates. Such an object file can either be fasl'ed in to a lisp or executed. If the object file is executed, it will execute a lisp and that lisp will then fasl in the object file which caused the lisp to be executed. By setting user-top-level to the name of a function in the fasl file, you can bypass the interactive top level of lisp. Previously the only way to get the effect of an executable lisp program was to fasl in the object file and dumplisp the entire lisp image. The problem with this is that each dumped lisp image occupies 900 disk block. With the -r switch, you can write lisp programs that occupy less disk space than their equivalents in other languages. When lisp is searching for the fasl file which executed it, it looks in all directories in the user's path (getenv 'PATH). This means that you can put these executable lisp object files in system directories and anyone can run them just like any other program.  Date: 26 Jan 1981 23:38:02-PST From: CSVAX.jkf at Berkeley Message-ID: <9822.209.349428934.CSVAX@Berkeley> To: sdcsvax!davidson cc: CSVAX.lisp Subject: Re: A few bugs/undocumented features In-reply-to: Your message of 26 Jan 1981 1648-PST (Monday). Date: 26 Jan 1981 1648-PST (Monday) From: sdcsvax!davidson@Berkeley To: ucbvax!lisp 1) (mapcar (functin quote) '(lions tigers bears)) dosn't work if you expect this to return (lions tigers bears) you should define kwote (def kwote (lambda (x) x)) and map it over the list. You are asking for trouble if you map an nlambda over a list. The reason the mapcar fails is the same reason that (funcall 'quote 'a) fails, an nlambda expects a list as an argument. 2) (implode '(lions tigers bears)) => ltb rather than lionstigersbears here the manual was not explicit enough. implode is only defined to take arguments which are single characters or fixnums. The Maclisp manual does not say what it does when an argument is a symbol whose pname is longer than one character, so we decided to just use the first character. Use the function concat to concatenate entire print names. 3) (pp environment) causes a bad memory reference the environment contains dotted pairs and our crufty pretty printer sometimes gets confused by these not listy structures. CMU probably has a better pretty printer (although theirs may require a `print macro' capability to work). ==>> While we are on the subject of utility packages for Franz, we should mention that we and Lars Ericson at CMU have decided to maintain a central distribution center for our lisp software on a computer here at Berkeley which will soon (2 months) be on the Arpanet. When this all comes about we will let everyone know and will encourage you to contribute your software to this pool. 4) (oblist) reports nil twice (I havn't rechecked this in Opus 34 this is true. Look in your mailbox in a few days for the fix for this bug (and for all the others you've found). I will also send the fixes to the franz-composers mailing list so someone at every site should receive it. 5) Franz Lisp chokes when it comes up on some environments. In particular, an environment with extensive TERMCAP and EXINIT variables, with embedded control characters seems to be a cause of this. (not shown on typescript. If the problem does not immediately occur to you, please let me know and I'll restore my old .login with those settings and send you a duplicatable typescript). this is unfortunate. The problem is the creation of the value of the environment variable, which in fact is not even necessary, since the getenv function does not use it. This has never happened to anyone here so you must be running with different terminals. I suggest you just make the makenv function in inits.c return immediately instead of try to create the value to store in the environment variable. Let me know if you really care about the environment variable. 6) alphalessp seems to be an alphaleqp, also, it chokes on strings! We just noticed the bug in alphalessp here a few days ago. the bug will be fixed and it will work for strings. Again, check you mailbox for the fix.  Date: 26 Jan 1981 12:36:22-PST From: sdcsvax!davidson at Berkeley To: ucbvax!lisp Subject: A few bugs/undocumented features Cc: sdcsvax!davidson Good Sirs, I found the following bugs in the previous release of Franz Lisp. They appear to remain, as the appended typescript indicates. 1) (mapcar (functin quote) '(lions tigers bears)) dosn't work 2) (implode '(lions tigers bears)) => ltb rather than lionstigersbears 3) (pp environment) causes a bad memory reference 4) (oblist) reports nil twice (I havn't rechecked this in Opus 34 5) Franz Lisp chokes when it comes up on some environments. In particular, an environment with extensive TERMCAP and EXINIT variables, with embedded control characters seems to be a cause of this. (not shown on typescript. If the problem does not immediately occur to you, please let me know and I'll restore my old .login with those settings and send you a duplicatable typescript). 6) alphalessp seems to be an alphaleqp, also, it chokes on strings! Greg (typescript follows) Script started on Mon Jan 26 11:17:33 1981 Warning: no access to tty; thus no job control in this shell... 1)) lisp Franz Lisp, Opus 34 -> (mapcar (function quote) '(lions tigers bears)) Args: (ER%misc 0 t |Bad funcall arg(s) to fexpr.| lions) Error: Bad funcall arg(s) to fexpr. lions <1>: (showstack) Forms in evaluation: (showstack) (mapcar (function quote) '(lions tigers bears)) nil <1>: (reset) [Return to top level] -> (implode '(lions tigers bears)) ltb -> (pp environment) (setq environment (quote ((HOME . /csl/davidson) (SHELL . /bin/csh) (Args: (ER%misc 0 nil |Internal bad memory reference, you are advised to (reset).|) Error: Internal bad memory reference, you are advised to (reset). <1>: (showstack) Forms in evaluation: (showstack) (pp environment) nil <1>: (reset) [Return to top level] -> (alphalessp 'a 'a) t -> (alphalessp "a" "a") Args: (ER%misc 0 nil |alphalessp expects atoms|) Error: alphalessp expects atoms <1>: (showstack) Forms in evaluation: (showstack) (alphalessp "a" "a") nil <1>: (reset) [Return to top level] -> (exit) 2)) script done on Mon Jan 26 11:20:06 1981  Date: 20 Nov 80 16:37-EST (Thu) From: Weisched at UDel Subject: franz mailing list To: franz-friends at Mit-Mc cc: Weisched at UDel Message-ID: <80324.59837.5170 @ UDel> Please add my name to the mailing list for information regarding franz lisp. arpa-net: weisched@udel US mail: Ralph M. Weischedel Dept. of Computer & Information Sciences University of Delaware Newark, DE 19711  Date: 20 Nov 1980 08:29:29-PST From: CSVAX.fateman at Berkeley To: franz-friends@MIT-MC Subject: character I/O in UNIX is trivially accomplished by typing stty cbreak before entering lisp. The reader then gets each character as typed. It means you can't use normal line/character delete stuff as provided in UNIX unless you program it yourself in an alternate reader, but that's the point of all this. (I tried the above on a 4bsd UNIX system; I do not know that 3bsd will be as nice. UNIX VAX systems should convert to 4bsd as soon as possible. We are making tapes now in preparation for the big mailing.)  Date: 20 Nov 1980 0736-EST From: Mark L. Miller Subject: Re: mailing echos To: DONC at USC-ISIB cc: franz-friends at MIT-MC In-Reply-To: Your message of 18-Nov-80 2018-EST I'm getting about 4 copies myself. Regards, Mark -------  Date: 19 Nov 1980 (Wednesday) 2348-EDT From: SHRAGE at WHARTON (Jeffrey Shrager) Subject: Ok -- Unix wizards... in search of the elusive VMS character IO To: franz-friends at MIT-MC We run VMS and thus are certainly not experts in Unix system calls. When I asked about character IO I was informed that the Unix SYSCALL function actually works in VMS as well. The problem is that we don't really know how to do this (not being Unix wizards). Does someone out there actually have the code to do this magic in LISP that I can glom straight? [Someone actually said that they did but I've lost the mail and forgotten who it was]  Date: 19 Nov 1980 0401-EST From: Mark L. Miller Subject: Re: Franz Lisp Documentation To: Mike at RAND-UNIX cc: franz-friends at MIT-MC In-Reply-To: Your message of 18-Nov-80 1449-EST read winston and horn's new book called LISP. -------  Date: 18 Nov 1980 1718-PST From: Don.Cohen Subject: mailing echos To: franz-friends at MIT-MC Why do I get multiple copies of every message? If the mailing list maintainers could arrange to stop the duplication I'd appreciate it. Otherwise take me off the list and I'll read the messages some other way. -------  Date: 18 November 1980 1842-EST (Tuesday) From: Lars.Ericson at CMU-10A To: jmiller at sumex-aim Subject: break package and editor CC: franz-friends at MIT-MC Message-Id: <18Nov80 184219 LE60@CMU-10A> the break package and editor are on TEMP:[M200LE60], with the following file names: EDIT.L, EDIT.DOC, FIXIT.L, FIXIT.REF, FIXIT.DOC. Lars  Date: 18 November 1980 1842-EST (Tuesday) From: Lars.Ericson at CMU-10A To: jmiller at sumex-aim Subject: break package and editor CC: franz-friends at MIT-MC Message-Id: <18Nov80 184219 LE60@CMU-10A> the break package and editor are on TEMP:[M200LE60], with the following file names: EDIT.L, EDIT.DOC, FIXIT.L, FIXIT.REF, FIXIT.DOC. Lars  Date: 18 November 1980 1832-EST (Tuesday) From: Lars.Ericson at CMU-10A To: Mike at Rand-Unix Subject: Re: Franz Lisp Documentation CC: franz-friends at mit-mc In-Reply-To: Mike@Rand-Unix's message of 18 Nov 80 14:46-EST Message-Id: <18Nov80 183252 LE60@CMU-10A> Try Winston's book on LISP. Lars  Date: 18 Nov 1980 (Tuesday) 1820-EDT From: SHRAGE at WHARTON (Jeffrey Shrager) Subject: VMS implementation character I/O To: franz-friends at MIT-MC Can anyone hack Franz under VMS to do character I/O so that we can put up a screen editor? Will this be possible under Eunice?  Date: 18 Nov 1980 (Tuesday) 1818-UDT From: SHRAGE at WHARTON (Jefvrey Shrager) Subject: An Intro LISP book To: franz-friends at MIT-MC A friend of mine0qnd I have written a book0introducing the LISP language itself. It is written at a Freshman college0level and is a much better language learners book than Winston-Horn. We were originally going to publish it but not any longer (likely). In any case -- it is about 80% complete (all the basic language stuff is there 100%) and I can send around copies of the printable form if there is sufficient interest.  Date: 18 Nov 1980 13:58:13-PST From: CSVAX.jkf at Berkeley To: mike@rand-unix Subject: Franz Documentation Cc: franz-friends@mit-mc I agree that the documentation in the 3bsd package was much too brief. You will find that the 4bsd manual is much more complete (all references to chapter X.Y have been removed). The 4bsd tapes are going out once the documentation gets back from the printers (any day now) and when you get the latest Franz manual, please let me know what needs to be added/corrected. I think that Winston's book has a good introduction to lisp. After you get the basic idea and you want to see some Franz code, look in the lisp coded function packages (such as /usr/lib/lisp/auxfns0.l and /usr/lib/lisp/trace.l), the lisp top level (/usr/lib/lisp/toplevel.l) or the lisp compiler.  Date: 18 Nov 1980 13:34:52-PST From: CSVAX.fateman at Berkeley To: Mike@Rand-Unix, franz-friends@Mit-Mc Subject: Franz Lisp Documentation There is a new manual which describes the 4bsd Franz system, which is distributed with 4bsd. (We are making tapes right now; the manual is at the printer's). I think the Winston-Horn book "LISP" now in paperback (Addison-Wesley) would be a good introduction to the language. The Winston AI book has some relevant material, of course.  From: Mike at Rand-Unix Date: 18 Nov 1980 at 1146-PST To: franz-friends at Mit-Mc Subject: Franz Lisp Documentation In-reply-to: Your message of 18 Nov 1980 (Tuesday) 0013-EDT. (greetings) I am learning lisp and franz lisp simultaneously, and I would like some pointers to documentation. In particular, the franz lisp manual in the 3bsd (third berkeley software distribution) is laudable in its compactness and terseness and yet quite useless unless you already know lisp (and possibly maclisp). I am reading Winston's book on AI. What else should I read? The MACLISP manual? (mike)  Date: 18 Nov 1980 (Tuesday) 0013-EDT From: SHRAGE at WHARTON (Jeffrey Shrager) Subject: Welcome to the Franz-Friends mailing list. To: franz-friends at MIT-MC Welcome to the Franz-Friends Arpa-net mailing list. This list is meant to service persons associated with the Berkeley Franz LISP system running under Unix (typically VAX Unix or VMS emulation). Hopefully we will be able to diseminate recent relevant information about Franz and associated packages. In order to have a friend added to the main list send mail to SHRAGE@WHARTO. (That's Jeff Shrager@Wharton-10) The names will be collected and posted to the file enmasse so it may take a few days to actually get in. You aren't likely to miss very much in that time (I hope). In order to send out mail to the list send to FRANZ-FRIENDS@MC. There is an associated implementor's list which you might prefer to be on. Again, send mail to me if you would like your status changed (or deleted) [Note; readers at Berkeley get theirs via an internal net so they will have to deal with "the local authorities" about their status.] Enough administrivia (to kwote another imfamous mailinglist). I've said my piece and done my handiwork -- now it's up to you to make of this a useful tool. -- Jeff Shrager Department of Computer Science The Moore School Univ. of Penna.  Date: 17 October 1980 12:32-EDT From: Kent M. Pitman Subject: File initialization To: "(FILE [LSPMAI;FRANZL FORUM])" at MIT-MC If a Franz Lisp forum is created, it will go to this file.