Inter-Office MemorandumToPE Group (c: Bob Taylor)DateJune 19, 1978FromP. Deutsch (as scribe)LocationPalo AltoSubjectMinutes of today's meetingOrganizationCSLXEROX Filed on: pe-minutes-6-19-78.memo on Maxc1This was the first meeting of a working group to produce a draft report on programmingenvironments. The group consists of:Peter DeutschJim HorningButler LampsonJim MorrisEd SatterthwaiteWarren TeitelmanAgenda & structureWe agreed to accept Bob Taylor's charter and Jim Horning's first-order report outline, amended asfollows:We feel it is important to include good ideas not present in the 3 primary systems -- wedon't think there will be very many of them. (A new heading between III.C and III.D, plussome appropriate revision of I.A.)We must enumerate requirements (V.A) before we can evaluate deficiencies in them (V.B),so V.A needs to be a priority item as well as V.B.We agreed to begin as Jim H. suggested, namely, to put together a catalog of current good ideas,assign weights to them, and then evaluate our current systems with respect to them.We saw three ways to evaluate features: by imagination ("I think X would be a good idea"),from experience ("I think X has been a good idea"), and by measurement ("In real life,people use X a lot"). Since we do not have or expect others to invest the resources requiredfor measurement, we will not attempt to answer questions on this basis.We obtained commitments from people as follows:Deutsch, Horning, and Lampson are fully committed to the group, at least until Horningleaves in roughly 4 weeks.Morris has some reservations about the charter of the group, but is willing to participate.Satterthwaite has heavy demands on his time right now but will participate at least as anobserver and Mesa wizard.]gp c8q]r-q7Br ]q]r-q7Br Yq]r-q 7BrSsr M3 G@ Fi%C= A @3 > =); 8xt 5Lr^ 30 N/#7-"*e+,(2 %Y $/S!:~++>tG H/Vk.-?+.  s>Q\Minutes of 6/19 PE Group meeting2Teitelman has other projects with demanding time constraints but will participate as well aspossible.We decided on a regular meeting time of 1:30-3:30 PM on Mondays and Thursdays.Homework for this Thursday's meeting consists of adding to the catalog anything we feelwas omitted, and assigning to each item one of three importance levels (essential, useful,marginal) and one of two difficulty levels (easy, hard). It is important to distinguish"intrinsically or structurally hard" from "requiring a lot of straightforward coding".After taking care of the above, we began discussion of the ideas catalog, starting from a list whichwas brought to the meeting (file [Maxc1]pe-ideas-6-19-78.memo).Discussion of the catalogWe observed that some kinds of tools require more pre-planning than others, e.g. on-line access todocumentation can be added after the fact much more easily than a source-language debugger.We made several small comments on and additions to the list as proposed:User access to underlying system mechanisms was not originally on the list, and has turnedout to be very important in Interlisp."Low overhead" for compilation/interpretation at run time may mean something like <1second if it only refers to type-in, but means something quite different if programs routinelycompose and execute other programs (e.g. Lisp EVAL).Prettyprinting is not just a source-to-source process: it must take some internal, program-manipulatable program representation and produce source from it.Most of our subsequent discussion centered around the first four items on the proposed list, and inparticular the question of how programs should be able to deal with large, somewhat structured datacollections.Addressing and accessWe observed that 2^20 items was not a "large" address space, and considered two alternativemeanings of "large".An address space of, say, 2^24 items would be adequate to hold all the code actually beingused even in a large system, but not adequate for all of its data (e.g. the American Heritagedictionary).An address space of, say 2^48 items would be adequate for all the code and data of a verylarge, even multi-machine system.We tended to favor the former, more conservative definition, since we did not understand how toprovide an efficient, robust implementation of the latter (more on the robustness question below).However, we did feel that it was essential that a transition across the 2^24-object boundary notrequire the kind of wholesale reorganization of programs that such a transition requires in currentlanguage systems.System facilities for accessing large, external data bases are required for several reasons:Many questions of organization and efficient implementation can be solved once, rather thanover and over again by applications. frGb O` ]mNZA KX4&W79UV RS QH Mt JrP I$? EHB LAG&>T<H;47J6`@ 34;( 1L 0* ,u )r@ (M%!9!#A" $urf! :<#  X 0G B! & \ M I$  ?Q\Minutes of 6/19 PE Group meeting3The system itself needs data base facilities for tools like the librarian.Access to externally stored data objects needs to be smooth for the debugger and othersystem facilities, not just the application programs.Programs normally refer to internal objects with individual references, but to external data baseswith both individual references and "mass" queries. We then observed that there are three basictechniques for speeding up references to external data:Caches (good for individual references);Using sequentiality properties (good for searching);Inversion (good for searching).IntegrityWe observed that a programming environment in which the file system is viewed as an extension ofthe address space must be extremely robust -- much more so than any programming system we nowhave. We observed that our current practice is to make the "truth" for a data base be a text file,and not expend a lot of effort on armoring the binary version against all imaginable errors. Notableexceptions are the basic file facilities like IFS; we believed that a system that provides robustnessfacilities usable at higher levels would have a lot of advantages.Long-term integrity seems to require some kind of history or redundancy information.To protect against "cosmic rays", it is sufficient to record this information in a form thatonly the implementing program understands.To provide Undo capability, the history must be in a form which makes sense to clients.Another kind of integrity has to do with not losing information. We mentioned the following kindsof ideas in this connection:A computed object (e.g. a Mesa configuration) should track of how it got made, in enoughdetail to make it again. The description of the putting-together process should be program-manipulable.Files should be self-identifying in a way that does not depend on their transfer betweenstorage media or locations.It should not be possible to destroy all traces of a file containing input (as opposed to purelycomputed) information. The space requirements can be kept under control by storingdescriptions of files (such as changes from other files) rather than all the bits.We also observed that the dangling reference problem and various garbage collection approachescould be viewed as integrity questions. frGbJ^;]m5 ZA\ XE W77T (P4M Ju G[rF E] DQZ Be AGe ?B QNInter-Office MemorandumToPE groupDateJune 26, 1978FromB. W. LampsonLocationPalo AltoSubjectMinutes of June 22 meetingOrganizationCSLXEROX Filed on: PE6-22.memoWe spent the entire meeting discussing items 5-10 on Peter's newly numbered list (pe-eval-6-21-78.memo). The following conclusions were reached:(5) Minimal support for interrupting the program is A. Good facilities are B. There seemed to beno strong religious feelings about the form of a process mechanism.(6) There was a long and inconclusive discussion. Apparently we don't really know what this pointis about. At one extreme of "data trapping" there is a simple address trap, as on early machines.At the other extreme is KRL. No one was willing to espouse either extreme. It was noted thatprogramming with data abstractions can help with this problem, since there is then a betterhandle on when data is being changed.checking some predicate at preiodic intervals (e.g. on every control transfer) may be quiteadequate when data trapping is being used to catch "core smashing" types of bugs. Mesaalready has this facility.many interesting cases can probably be handled by using the primitive trapping facilities ofthe mapping hardware.It was agreed that this should be moved to C pending better understanding of what it is all about.(7) Certain things are required: something to unwind the stack, some way of catching an unwind,and program control of error processing. What should be provided beyond this is not agreed - thecontroversies raging around the Mesa signal facilities are a reflection of our poor understanding ofthe problem. "Good" exceptional condition handling is C-333.(8) It was agreed that access to BitBlt, disk and ethernet should be moved to packages, withpriorities A, B and C respectively. "Adequate" access to packed data remains A, "Good" access(i.e. first class citizenship) is B. There was a long discussion of why it is hard to add packed data toAlto Lisp, which centered around a protection question: how carefully should the system preventthe user from smashing its underlying data structures. There wasn't much agreement on this point,but it does seem to have considerable practical importance, since a highly restrictive attitude makesit difficult to code low-level parts of the system in itself.(9-10) These are closely related. A long discussion led to the conclusion that all this information iscurrently available in Mesa, modulo the question of how stable the compiler's internalrepresentation of the program as a tree should be expected to be. Straightforward methods (like theones used in Clisp) will allow compiled code to be attached to source in a user-created datastructure, although it is certainly easier to do this in Lisp, where interpretation is simple. Notexplored was the usefulness of an interpreter for a subset of the language, such as currently exists in]gp c8q]r-q7Br ]q]r -q7Br Yq]r-q 7BrSsr M G^ Fi< C=$> AC >W = X ;B8V+06%4yA22%1o/..- *fI ':_ % V $0I "= K P uZ F k U _ a= 5X :;C +=' J !>% !F \ U>]Minutes of June 22 PE meeting2the Mesa debugger.It was agreed to continue along the same path at the next meeting. frG b [Br U'.Inter-Office MemorandumToAllDateJuly 21, 1978FromP. DeutschLocationPalo AltoSubjectMinutes of PE group 6-26 meetingOrganizationCSLXEROX The file containing the minutes of this meeting was unaccountably lost. See any member of the PEworking group (Deutsch, Horning, Lampson, Morris, Satterthwaite, Teitelman) for a hardcopy.]gp c8q]r-q7Br ]q]r -q7Br Yq]r-q 7BrSsr PzA NQ JN>QTJMemorandumToPE GroupDateJune 29, 1978FromJim HorningLocationPalo AltoSubjectPE Minutes, June 29, 1978OrganizationCSLXEROX Filed on: [Ivy]June29-minutes.memoHomework:Peter has discussed the "default" future for Smalltalk. Things that are likely to happen (in additionto anything done by a Programming Environment project) are:Development of a constraints interface, following Alan Bornings work.Simplification of the user interface, following Adele Goldberg's ideas.A major effort to fit the system into small machines, specifically Notetaker.Information retrieval capabilities.More work on animation.We concluded that this work was pretty much orthogonal to our Priority A items; if we want abetter Smalltalk environment for CSL, we'll have to do it ourselves.At Peter's request, Danny Bobrow prepared a discussion of directions in which the Lispenvironment will probably evolve if there is no special PE effort. At least some attention will bepaid to several of our priority items, so things aren't quite as orthogonal as with Smalltalk, butneither will it be anything close to what we have been hoping for and discussing. Danny also madea special plea to raise the priority of "ability to create fully integrated local sublanguages," which heconsiders a critical part of the present Lisp environment. For further discussion of this point, seeitem B3 below.Butler wasn't present, but has agreed to prepare a similar projection for Mesa upon his return.Peter reported that he was making substantial progress in integrating the discussion from previousmeetings, as reported in the minutes, into an outline based on his "catalog" of June 21. He willcirculate at least a partial draft prior to our next (July 6) meeting.Jim H. distributed the following possible outline for the core of our report (i.e., Peter's integration,reported above):"Bare Catalog" as a table of contents and coordinate system for what follows.Amplification and explanation of catalog items.Analysis of importance of items for E(PE) and/or (EP)E.Relation to existing environments: analysis of difficulty for Priority A items in eachenvironment; projections for non-EPE development.]gp c8q]r-q7Br ]q]r -q7Br Yq]r-q 7BrSsr M+ Gp D|rO B;@E>GG;M9#7? 4\ 2D /bV -C ,XK *X )N` 'a &D #A !A g U F S 1M/)7"4 L1| =[PE Minutes, June 29, 19782Priorities (A vs. A+).There was some discussion about whether the matrix of catalog items versus concerns should bepresented in row-major or column-major order. An omitted concern was noted: on which items isthere substantial agreement on the solution, as well as on the importance? The concern forpriorities led to some inconclusive discussion of how to define them, and of chickens and eggs; theconsensus was to postpone any attempt at further partitioning Priority A.Discussion of Catalog:We resumed the discussion of Peter's Priority A items in the Virtual machine/programminglanguage category.A(13). Simple, unambiguous syntax.Peter: It is important to have syntax equations (or their equivalent) clearly defining a language thatcan be used safely; this doesn't exist for CLISP, and for Mesa it runs to five densely-packed pages.Warren: It was more important in CLISP to respond reasonably to a wide variety of errors than toprecisely define what the user could do safely.Peter: I seriously doubt the utility of a system where the gap between what can be precisely definedand what the user can reasonably do is so large.Jim H: Although backward compatibility was important for CLISP, and a source of significantdifficulty, it is something that we should probably be prepared to sacrifice in a new programmingenvironment if it conflicts strongly with high-priority goals.Miscellaneous discussion finally led to the conclusion that neither Mesa nor CLISP syntax were thesource of sufficient problems for the practicing programmer that we should make this a high-priority item. Dropped to Priority B.A(14-15). Encapsulation/protection mechanisms (scopes, classes, import/export rules); abstractionmechanisms, explicit notion of "interface."Peter: An interface should be viewed as at least a partial specification.Jim H: One of the problems with Mesa is that user-defined abstractions (packages) are not first-classcitizens in the sense that they cannot be used wherever language primitives can. In building multi-layer systems using packages, it seems important that the user of a facility not need to care whetherit is primitive or user-defined. Having said that, let me warn that this is an open research area, andit is easy to be led astray (modules as data types were the source of a significant fraction of theproblems with Euclid).Alan: A crucial aspect of an (EP)E will be the ability to gain efficiency by wiping out or obscuringinterfaces and otherwise destroying structure.Several: This is an important optimization issue for compilers, etc., but is relatively well-understoodcompared to most of our Priority A items.Jim H: I think that at the present time we dare not attempt anything much beyond Mesa for (15),but we might model (14) somewhat more closely on Euclid. (Groan from Warren.) Import/exportlists provide useful documentation, even if they are automatically derived (cf. our earlier discussionof declarations).Peter: Control of exported names has proved to be even more crucial than importation; even theLisp compiler has had to make some provision for it. I rate export control Priority A, importcontrol Priority B.Ed: Some future version of Mesa (6 or later) will probably take steps in this direction, anyhow. frGb ^> ]m R [> ZcI XI Sp Pr!t Or Kt# Ir33 H N E<$ D-/ A:* @P0 =? 8^ 7@ 5& 2`tN 0+ .rI ,+Q *d )!U 'L &S $ ":N . ]I ) E F vR  Z <"  7,4 =Z3PE Minutes, June 29, 19783A(16). Non-hierarchical control (coroutines, backtracking).Peter: All three systems provide adequate solutions for coroutines, although each leaves somethingto be desired in cleanliness, generality, and/or efficiency. Only Lisp does backtracking, but thisisn't too important, and Lisp probably doesn't do it right, anyhow.Jim M: Would this category include procedure closures?Peter: It certainly should!Ed: The Mesa compiler would be cleaner with closures, it currently gets much the same effect bynesting procedures.Some discussion of whether such a general mechanism was needed, or whether specializedmechanisms (e.g., generators) would span the more common and important uses. The efficiencyissue was raised; provision of automatic object management (garbage collection) may reduce themarginal overhead of allowing for closures.Peter: Closure is Priority B.A(17). Adequate run-time efficiency.Peter: The following rough estimates indicate the general situation:Current Smalltalk is a factor of 100 slower than Mesa.The re-engineered Smalltalk would be a factor of 5-10 slower than Mesa.Lisp will be a factor of 3-6 slower than Mesa.If Dorado is a factor of five faster than the Alto, and Mesa efficiency on the Alto is assumed to beacceptable, then just switching to the Dorado should at least buy a couple of years for either re-engineered Smalltalk or Lisp. Thus, to first order, we are OK here.B(3). Ability to create fully integrated local sublanguages.[Integrated from discussions that took place at two separate times in the meeting.]Peter: Danny has spoken to me several times on this--he feels it's an absolutely crucial feature ofthe Lisp environment.Jim M: Why has the Lisp environment been so much more successful than any of the others atsuch integration?In the discussion, the following factors were mentioned:A major enabling feature is the standard internal representation for parse trees in allsublanguages (S-expressions).There is a completely standard method of sharing names and passing environments.Lots of system hooks are available to the sublanguage implementor, allowing him to dig hisway in incrementally (although pioneers sometimes encounter quicksand).Warren: An important principle is that the amount of work for a language change should beproportional to the size of the change.Peter: Some of the things that have made Lisp sublanguages easy are going to be needed for theother language environments, anyhow. For example, the Mesa debugger needs many of thesethings; a re-engineered Smalltalk compiler could take advantage of them. The essential notion isthat a name scope must become a first-class object within the language.Jim M: One of the reasons is the availability of packages for dealing with language-like structures,e.g., prettyprinters and program input.Warren: Don't ever underestimate the importance of convenient I/O in the interactive environment. frG bt< _rL ^A^ \C Zd6 X  UP T/ QB PR\ N(6 MH+ J Gt% ElrDC6@G>d. < $@ :4. 9D 5t= 3~rS 1&.5 / -I0* + )l8'<%#7P SZG 1( }' % P ; B t r6 > W ' aT  r =YPE Minutes, June 29, 19784Peter and Alan: One omission by oversight from the Priority A list is a reasonable multi-languageinterface.It was agreed that if this meant the ability for programs in each language to call packages in theother two, this would be a 333 item. However, we could probably settle for somewhat less, namely,the ability to drop from Lisp or Smalltalk into Mesa subroutines, as a "machine code" substitute.The more general facility can be Priority B.Alan: Lisp makes it easy to "go up" by building new systems/sublanguages on top of old. TheEPE should also make it easy to "go down" by re-engineering a high-level system to rely on lesssupport mechanism or run on a smaller machine.Several: This is hard; no generally useful mechanisms are known.At this point we turned to Tools, and discussed only A(1). Fast turnaround for minor programchanges.Peter: I have proposed to separate this from my original item "integrated editor," since if theturnaround is fast enough, I don't care how it is achieved.Alan: If the turnaround is fast enough, you have an integrated editor.Peter and Warren: No, by integrated, we mean that the editor knows about the structure of thelanguage system and conversely; an integrated editor can be called from within a program, and canitself invoke programs.Warren: It is important to be able to apply the full power of the language to whatever problem youhave in hand, even if that is a text manipulation problem, and conversely.Peter: This suggests that the editor should be one of the sublanguages that we have been discussing.However, the interfaces to our more popular editors don't look very much like any of ourprogramming languages.Warren: Yes, this is a hard research problem that I'm interested in working on: How should weincorporate selections and mouse clicks into our programming languages?Peter: I propose that we assign Priority A to fast turnaround, and to an editor package that iscallable from the language, and assign Priority B to the integrated editor.Warren: I'm serious. The integrated editor is very high on my priority list.We agreed to resume discussion on this point at our next meeting, July 6.c: R. TaylorA. Perlis frG b.3 ` ^A02 \G [7A Y, WZ/- UW TP. Q@ Nt/. MG Jr R Ij; G,tr D'6 C5P A ?X4. =J ;{ Y 9> 8q 6@ 4G 2<>! 0K ._M ,tI 'Vr % %>BInter-Office MemorandumToPE GroupDateJuly 10, 1978FromP. DeutschLocationPalo AltoSubjectMinutes of 7/7 meetingOrganizationCSLXEROX Filed on: pe-minutes-7-7.memo on Maxc1Warren was absent from this meeting; Alan Perlis attended.Agenda, outline & homeworkHomeworkIn order to make our priorities crisper, each of us will take 100 votes and allocate them amongfeatures for next meeting. Jim H. originally proposed that the units be "man-months" rather than"votes"; after discussion, we decided on votes so as to avoid tying together the desirability of afeature and its difficulty. Both the mean and the variance of the allocations are of interest!We discussed the difference between the two parsings of the label EPE, and decided it was only oneof emphasis. Jim H. suggested that a useful way to describe the difference was in terms of whatquestions we were interested in asking (and answering):(EP)E implies an environment for writing programs in which we are more interested inasking questions about the functioning of those programs (but are still interested indeveloping the environment as such).E(PE) implies an environment in which we are more interested in asking questions about theenvironment itself (but must still provide enough features and stability for people to use itto produce real programs).Anyone who feels this difference affects the priorities of features is free to submit two differentallocations of votes. We agreed that we should try to be more sensitive to this difference in ourremaining discussion of individual features.Our current working document does not address two major areas that we want to cover in the finalreport: distinguishing fundamental features from those which could be added later with relativelylittle difficulty, and identifying which features enable other features. Jim H. agreed to writesomething in these areas by the end of next week.The working document contains two sets of difficulty estimates (Peter's and Butler's), which disagreesubstantially in some cases. Peter and Butler agreed to work out these conflicts between themselves.Input from other group members is also solicited. We hope to limit group time for discussing theseestimates to cases where conflict absolutely cannot be resolved off-line.Butler still owes the group a document on the probable future course of Mesa, similar to Peter'scomments on Smalltalk and Danny's memo on Lisp.]gp c8q]r-q7Br ]q]r -q7Br Yq]r-q 7BrSsr M/ G: Dt Au >jrK <-4 ;`Pu r 9u r; 6+7 5*L 370yA.E-o$*CP (*3'9 $ C "3/ !, 1/ RQ J H1 &? 50 c I a)7 / t ?Q\mMinutes of 7/7 PE Group meeting2IntroductionJim H. said he would write an introduction for the report, dealing in particular with the question ofhow one decides whether one PE is better than another. He suggested there were really only twocriteria for judging PEs and PE features:whether they improve the economics of programming -- the resources (machine and human)required for the programming process;whether they improve the quality of the programs produced -- the performance,modifiability, maintainability, etc.Subsequent discussion led to agreement on these criteria, but also to the observation that since inpractice no one used them to measure systems quantitatively, the criterion actually used forevaluation was usually how well experienced programmers liked the system (which, presumably,often led to the same conclusions). We concluded that it was still important to include these criteriain the report, as a qualitative statement.A different viewAlan gave a somewhat different view of how one should look at PE features. He suggested therewere three key notions:"closure" - the ability to take any capability (package, tool, language construct, ...) and use itin any context where it made sense semantically;"linking" - the possibility of taking capabilities developed as experiments and integratingthem into a standard base environment;"editing" - the ability to alter any or all parts of a system easily.Ideally, a PE designed for experimentation should leave every conceivable binding potentiallyalterable. Alan's prime example was taking a cut-down form of Mesa and experimenting withadding garbage collection. L* reflects this philosophy -- all levels of the system, from the mostsophisticated external language to the most primitive machine-like level, are available to theprogrammer.Subsequent discussion revealed little support for this view. We observed that an approach whichencouraged people to build their own variants of systems or system subsets tended to destroy theability to share the results, although it might permit more alternatives to be tried. With respect toAlan's example, we observed that the experiment in itself was very difficult, and that designing anenvironment to make experiments of that magnitude easy was beyond what any of us knew how todo. Most of us felt that system design almost inevitably required making more decisions at designtime than Alan was advocating. Even though Alan's desiderata were a useful way to think aboutresearch areas in PEs, they did not seem concrete or attainable enough to incorporate in our presenteffort.Language integrationPoint (VM/PL) B3, fully integrated sublanguages, took up the rest of the meeting. There were twomajor threads to the discussion: why Lisp seems so much more hospitable than Mesa to the creationof integrated sublanguages, and what some alternative meanings of "integrated" might be. [I havetaken the liberty of rearranging the discussion somewhat in light of what I think we came tounderstand in the course of it.]We observed two characteristics of Lisp that made it easy to create sublanguages that couldcommunicate among each other: the existence of S-expressions as a common, simple representation frG bu ^r Z ]mD [)X"4W7%T 8#9*R$ OZc M\ LP N JW IF* Fu Br:$ Ai>=W <09?8&4E 1Q 0*6$ .D - B + (oB &;% %eK #B! "[Y I QO S G t r8) j7* B `I  < *+4 >Q]'3Minutes of 7/7 PE Group meeting3of programs, and the existence of a single, very simple name environment (atoms) that allsublanguages shared. (This has both advantages and drawbacks: it leads to the "FLG" phenomenon,for example.) The sublanguages that don't take advantage of these characteristics, such as CLISP,QLISP, and KRL, find their lives a lot more difficult. If we were willing to limit the complexity ofsublanguages to that of S-expressions, i.e. procedures and conditionals, then we could devise an S-expression-like representation for Mesa also. [This is a bit of a handwave: in particular, it doesn'tallow embedding of a reasonable subset of Mesa itself in a sublanguage, and it doesn't address thepoint that some of the highest payoff comes from the integration of languages, like KRL, that don'tlook like S-expressions.] We also noted that no matter what features the language and environmentprovided, proper proceduralization of facilities was essential: even Lisp has sublanguages -- inparticular, the compiler control sublanguage -- which are implemented so as to interact with the userdirectly, and which therefore cannot be considered integrated.To sharpen our ideas about what integration means, we considered a "straw man": a system inwhich all languages (editor, interpreter, ...) shared a screen interface (window manager) but wereotherwise entirely separate. This led us to the following observations:Butler put forward this model as one that imposed minimal requirements on the individualsubsystems, at least if they only dealt with the screen as a sequential character I/O device.Peter disagreed, observing that despite numerous attempts, no such package had ever beendeveloped for the Alto, and suggesting that this was because no entirely satisfactory modelfor the interface had been developed. We agreed that things become more complex as thesubsystem's view of the display becomes more sophisticated (e.g. an editable document, abitmap).While this model allowed for considerable communication (by human transfer of charactersoutput in one window as input to another), it had two serious deficiencies: it made noprovisions for communication under program, rather than manual, control, and it requiredthat all transmitted information be in string form. [Note that even transmission of filenames requires integration in the sense of sharing a common file system.]While we did not reach any clear conclusions, we were able to agree on the following:This is an important area for discussion, but it needs more time than we have available tous.Integration really means a common model for communication.The one catalog entry we now have should be broken down into multiple features. Some ofthese should be priority A, some B. [We did not address the question of how we would dothis.]If all the other priority A features in the catalog were provided, Mesa could readily supportsublanguages of the complexity of S-expressions.Adequate proceduralization is necessary for a package implementing a sublanguage to beusable.A major source of difficulty is the sharing or passing of environment information betweensublanguages. One part of this difficulty is simply addressing or naming objects to beshared. Another part is making sure that shared objects are interpreted the same way (inMesa, making sure the communicants share the same declarations for the objects). One wayaround this is to have a limited number of globally agreed-upon structures, such as stringsor S-expressions, and then encoding more specialized languages within them and interpretingthem by convention or agreement (as Lisp does). frG b0) `N _/3 ]K \ T Z7/ Y:( W{Hu UrE TqD RE Qg> N;5& L.4 K1HH9F'6D:Cv4'AC@l'1>;7!:6682&7,:5I 2{U/O P-*:'rO%L $h!<U0S6#U4#QK(13(A[/2 u>QYMInter-Office MemorandumToDistributionDateJuly 11, 1978FromB. W. LampsonLocationPalo AltoSubjectMinutes of 7/10/78 EPE meetingOrganizationCSLXEROX Filed on: epe7-10.memoIt was agreed that we will discuss Horning's assignment of fundamental/intermediate/add-onattributes to the catalog at the Wednesday meeting.Rationale: Horning's draft was accepted pretty much as is. M: Should we recommend that someonework on evaluation of systems? L: No, since no one in the group wants to.Votes: M agrees to tabulate the votes. L and T have not yet voted.We then continued down the catalog, and made it all the way through the Tools section in thismeeting.A1/B1: B1 is a subset of what we discussed last time about integrated sublanguages - see theminutes. After some fruitless discussion, it was agreed that we are happy with this, except that Twould like B1 raised to A.A3: Simple batch cross-reference facility is A, the rest is B. An incremental facility must be Fund.Further discussion revealed that the Fund. aspect is the need for a single funnel for changes to thesystem (Mesa pretty much has this now, but Lisp does not). Relation to the file system wasdiscussed, and it was agreed that manual use of the file system should be outlawed. A consequenceis that the PE must do recovery at least as well as the file system does. Of course, having a reliablefile system underneath makes this much easier. A variety of techniques are possible, which we didnot explore in detail.A4: Often B6 is hidden under this - the two were discussed together. Definition: A4 is anefficiency issue: to get the right thing to happen without blindly recompiling and reloadingeverything. B6 is more fundamental, and was raised to priority A. It has two major aspects: historyand parametrization.Under history, we want to be able to tell exactly how a particular system or component wasconstructed, and what it depends on (e.g. microcode version, defs module or whatever).Furthermore, we want to be able to reconstruct a component automatically. This requires thatevery computation involved in its original construction must record all its inputs, and be preparedto repeat itself from this record. Since the inputs may be (references to) files, it is also necessary tohave a naming scheme for files which is unique over the whole universe, and a guarantee that nofile will ever be destroyed (unless the rule for reconstructing it is saved, together with all therequired inputs).Under parametrization, we want a systematic way of specifying the construction of a system whichnever existed before (e.g. it is for a new microcode version, or different implementations of thesame interface are combined in a new way). We agreed that we don't aspire to solve this problemin the full generality required by IBM.]gp c8q]r -q7Br ]q]r -q7Br Yq]r-q 7BrSsr M GE Fi3 C=tr J AJ >tr= ;`#%tr 9 6 P 5LU 3 0U /Atr -:! , /3 *` )^ '} $Q!9 ":" !G,9  1) -V 0- *tr #G =" xE  +5 B@! ` 8'  >_)Minutes of 7/10/78 EPE meeting2Replacing code in an existing system is in principle a special case of A4 - the general question iswhen a complete but expensive procedure (recompilation, reloading, etc) can be bypassed. It wasnoted that replacing code is in practice not just an efficiency issue, since getting the system back tothe exact current state is not possible in general. The reason is that the current state depends onuser program execution, and the user program cannot be counted on to follow the rules mentionedunder history, which we impose on the system programs which make up the environment.A6: Existing facilities were reviewed: Smalltalk and Mesa have a Spy, which works by sampling thePC, and Lisp has Breakdown. Proposed for Mesa by SDD arethe Diamond Test Module's facility for counting frequency and time between any pair ofbreakpoints,a facility for writing an event in a log either by procedure calls, or as an action to be takenat a breakpoint, anda "transfer trap" mechanism which logs data at every control transfer, together with somestandard ways of reducing this data to produce the same kind of information that a Spyproduces.It was agreed that something as good as Breakdown is good enough.A7: The weakness of the facilities in all three current systems was noted: file state is not saved, noris there any check that it hasn't changed on a restart. D: "protected environments" means theability to install a new version of something in a system an still be able to revert to the old versionvery cheaply. If checkpoints are cheap, this would be B at most. Cheap checkpoints can be donein a paged system with copy-on-write techniques.A8: D: this means a typescript file, the ability to feed back stuff from the typescript to the system,and the ability to have a handle on the values returned as well. M: All this is an attribute of theinteractive interface. Undoing is of system-implemented actions (e.g. edits), and a way for the userto integrate with this, by supplying undo procedures for his procedures.B3: H: Perhaps a lot of this is part of version control. L: DeSoto takes care of updating a "Bible"version from individual versions, and vice versa. H: That's what I meant. It was agreed that that isA. M: I want a "package librarian."B4: Moved to A.Distribution:DeutschHorningLampsonMorrisPerlisSatterthwaiteTeitelman frG b$? `K _)tr; ]31 \ 6) Z; WY4- U9S|FQ O_NK<J=K H EA B`C$ @Z ?V_ =8(   4 < =QIInter-Office MemorandumToDistributionDateJuly 13, 1978FromJim MorrisLocationPalo AltoSubjectMinutes of 7/12OrganizationCSLXEROX Filed on: pe-minutes-7-12.memoD reported on progress with the write-up, lamented variation in depth.D listed the various feature attributes: priority (A,B,C), votes/ranking, difficulty in various langauges,fundamental/add-on, and the enabling relationships.D reviewed some sugesstion from Masinter (try Swinehart's non-premptive user interface) andGuibas (consider TEX, and the general idea of attaching attributes to text and other data structures).They will be put into an appropriate discussion section.P asked whether the suggestion by Guibas was similar to the one that programs annotated byassertions be interpreted alternately by an evaluator or a verifier and pointed out that this idea hadyet to bear fruit.The outcome of the voting was discussed. H pointed out that the rankings according to medianwere roughly the same as according to the totals. This suggests that the effect of block voting wasnot significant.H's categorization of fundamental/add-on was discussed. L and D revised many fundamental thingsto intermediate or add-on. The basic disagreement seemed to be whether "fundamental" meant thechoice to include or exclude a feature was "important" or "non-reversible"L said that page memory management was add-on and object oriented swapping was notworth the trouble if there was enough memory.Cross reference capabilitues were raised to fundamental to the extent that the processing ofprograms had to be sufficiently centralized (unlike InterLisp) that there was a funnel; i.e. aprocess or program through which all the code passed on its way to becoming a system, orobject worthy of being cross-referenced.The Other section was dicussed with some revisions to priorities and difficulties. CSL control of thelanguage was taken as given, although the extent to which we want to remain compatible with thevarious languages will be a hard issue, dependent upon the importance of the implementors andusers of the langauges.Packages, priority A, were discussed.The screen manager as an allocator of raster points was promoted to be part of the virtualmachine, partly to avoid the current anarchy.The need for a package czar/librarian was cited.]gp c8q]r -q7Br ]q]r -q7Br Yq]r-q 7BrSsr M& GF D(B C=3 @ Q >trM =8 9? 8V8. 6 3S 2 X 0 -o` +_ *eJ'9&,%-"Y!Pur~B( R H0/ = > 4%ZW- z0  3?Q]Minutes of 7/122D pointed out that the various images (text, line, bit) were but manifestions of some abstactobjects that need to be specified and designed.It was pointed out that it will be easier for a Mesa-based EPE to draw on Pilot for variouspackages; e.g. remote files. frG`]_/\ [Z T*8Z%Inter-Office MemorandumToPE GroupDateJuly 17, 1978FromEd SatterthwaiteLocationPalo AltoSubjectMinutes of 7/13 MeetingOrganizationSDD/SDXEROX Filed on: [Iris]pe-minutes-7-13.memoWarren was absent from this meeting; Alan Perlis attended.What will happen next?Peter will circulate a draft report for comments this week, and the report will be available thefollowing week. We weren't sure what would happen after that (a CSL meeting was suggested).We seemed to agree that each of the three languages were equally far from our goals ("abouthalfway there", by Jim H.'s estimate), and that the immediate roadblocks were clear in each case.Jim M. asked about the increase in productivity that a EPE might provide. Butler estimated afourfold increase (but part of this comes from the hardware in any case). Consequences for CSLmight include fewer people per project, an increase in the number of systems attempted (because ofsmaller initial cost), and more ambitious projects at current project staffing levels.We will meet again after Jim H. returns to discuss feedback received by then and to decide what todo next.Discussion of Draft ReportPeter distributed a second draft of the proposed PE report. He commented on some gaps that hehad noticed, mainly in explaining the rationale for various features. We agreed that Peter could usehis discretion in expanding the discussions. We also noted that the specifications of the Lisp andSmalltalk systems we postulated in our evaluation needed clarification (especially re Pilot facilities).Butler agreed to write a one page conclusion. We agreed that statements about productivity shouldbe emphasized - where it will come from (packages, tools, language upgrades) and where it will go(more projects, more ambitious experiments, etc.). It also seemed important that the conclusions bestated in a way that will encourage discussion of the productivity claims rather than quibbling overthe details of our choice and ranking of features.We found that our agreement about the lessons we have learned from the existing systems issurprisingly high; most disagreement concerns the ranking of areas for further work. To supportthis claim, the report will include a tally of individual votes on the language features.Peter agreed to write an introduction that will summarize the group's charter, how we proceeded,and how it all relates to the final report.It is important that the report not be interpreted as a call for a new global plan.]g~p cq]r-q7Br ]q]r-q7Br Yq]r-q 7BrSsr M3 G: Dt Ar` @A <I ;`M 84:# 6[ 5*H 3V 0yJ . +t (r[ '%@ %D $ U J \"? F R5/ 2 F -3 Y kH + tr0 F=hMinutes of 7/13 Meeting2Discussion of Mesa in SDDEd distributed a memo concerning the prospects for future development of Mesa by SDD. Thisprovoked a somewhat extended and inconclusive discussion of how garbage collection might beadded to (a restricted subset of) Mesa. Butler promised to resurrect and circulate an old memo onthis subject.We noted that the charter of SDD/SD Palo Alto includes producing a Mesa programmingenvironment (albeit with somewhat differrent properties) and that SDD has committed ~6 people tothe further development of Mesa (but pressures to produce a product could dilute thiscommitment). Lisp was seen as having goals appropriate for an EPE but a lower level of support,while Smalltalk seemed to have rather different goals.Strawman ScenariosWe discussed several scenarios for developing a satisfactory PE. This included considering andrejecting a number of alternatives (developing Interlisp with some redesign, waiting for a Mesa PEfrom SDD, restarting from scratch). With respect to restarting from scratch, Peter agreed that muchcould be done with existing systems and that an evolutionary path to our long term goals seemspossible.The issue of a multilanguage EPE was raised repeatedly during this discussion. Peter and Butlerwere skeptical; they noted that an environment providing all our A features would support anyexisting style, while a two language system would reduce synergy and create artifical barriers ("one-language experts"). I believe we agreed that the only sensible course was to make a serious, singleEPE effort that eventually would support all styles of programming. During the interim, all theother language systems must remain usable, but an attempt to extend all of them significantlywould result in the commitment of subcritical resources to each.Our evaluation of the existing systems seemed to be the following: there is not much to choosebetween Lisp and Mesa; the uncertainity in estimating the work required to make either satisfactoryprobably exceeds the differences between the two languages. Smalltalk is further from our goalsbut contains important ideas that should be captured. Smalltalk and Lisp are closer to one anotherthan either is to Mesa, and Lisp might assimilate features from Smalltalk more easily. frG bt ^rF ]m? [b Zc W7: U8( T-)1*$ RB Q#6 Mt Jr@ IFM G13 F< Q D A$< @B >e <6. ;w` 9G 8m@ 5AI 3'< 27(8 0+8 /-V .=9$ TIMESROMAN  TIMESROMAN TIMESROMAN LOGO TIMESROMAN  TIMESROMAN  TIMESROMAN  TIMESROMAN TIMESROMAN LOGO TIMESROMAN  TIMESROMAN  TIMESROMAN TIMESROMAN LOGOHIPPO  TIMESROMAN " / % .6*<C L V^ djlr/xi.status6-21$.o6-6$.1.memo$.ai.status6-21.o6-6.1.memo. ai.status6-21$.o6-6$.1.memo$. ai.status6-21.o6-6.1.memo.,ai.status6-21$.o6-6$.1.memo.+ai.status6-21.o6-6.1.memo..ai.status6-21$.o6-6$.1.memo$. I me.resume$..memo.e5-31.memoj/|zEDper>minutes.pressdeutsch11-Aug-78 12:13:08 PDTz