Requirements for anExperimental Programming Environmentedited by L. Peter Deutsch and Edward A. TaftCSL-80-10June 1980; reprinted May 1982c Copyright Xerox Corporation 1982. All rights reserved.Abstract: We define experimental programming to mean the production of moderate-sizesoftware systems that are usable by moderate numbers of people in order to test ideas aboutsuch systems. An experimental programming environment enables a small number ofprogrammers to construct such experimental systems efficiently and cheaplyan importantgoal in view of the rising cost of software.In this report we present a catalog of programming environment capabilities and anevaluation of their cost, value, and relative priority. Following this we discuss thesecapabilities in the context of three existing programming environments: Lisp, Mesa, andSmalltalk. We consider the importance of specific capabilities in environments that alreadyhave them and the possibility of including them in environments that do not.CR Categories: 4.20, 4.33, 4.34, 4.4Key words and phrases: programming environment, experimental programmingXEROXXerox CorporationPalo Alto Research Centers3333 Coyote Hill RoadPalo Alto, California 94304НЇОW;pТ·НЇОSЛП$НЇОNЖqТXП-НЇОJGrН ТFНЇОE≈stП8НЇО=ЮqТю u vuТаНЇО;╚Т┴Т┼ПKНЇО9wТШТЭvП$uНЇО7BТІП>ТЇНЇО5ТП,НЇО12ТПOТНЇО.ЧТП8ТНЇО,иТЕПGТФНЇО*∙Т╘Т╙ПAНЇО(`ТПLНЇО" q uНЇОЁquП2НЇОЙwН*+О(uТXН*+ОєН*+О Н*+О⌡╨ЇT>QJЬ⌠REQUIREMENTS FOR AN EXPERIMENTAL PROGRAMMING ENVIRONMENTiPrefaceComputer software costs rise steadily, as we expand our ambitions to include ever morecomplex systems using ever cheaper hardware. The software that we can produce, and the rate atwhich we can produce it, are too often limiting factors in our research within the Xerox Palo AltoResearch Center's Computer Science Laboratory (CSL). We believe that it is increasingly desirable,feasible, and economic to use computers to directly assist the process of experimental programming.This report was produced two years ago as the report of an ad hoc Programming EnvironmentWorking Group'' that I chaired. It provided much of the initial impetus for Cedar, a major projectnow underway in CSL. Cedar is developing an advanced programming environment for the Mesalanguage as the basis for most of our programming during the next several years. We plan toreport in due course both on various novel aspects of the design of Cedar and on our experiences inconstructing and using it.Meanwhile, interest in the important properties of programming environments has beengrowing. For example, the U. S. Department of Defense recently published Requirements for AdaProgramming Support Environments.'' [Stoneman, 1980] Our situation has much in common withthat of other groups needing programming environments; hence we believe that others may beinterested in the requirements that we originally set for Cedar.This report was originally edited by Peter Deutsch for consideration within CSL. Ed Taft hasedited it slightly to make it more comprehensible outside its original context, but has not attemptedto either update or generalize it. Considering its age, and the speed with which it was prepared, Ibelieve that it stands up very well. However, the reader should bear in mind that it was addressedto the problems of CSL as we saw them in mid-1978.J. J. HorningJune 1980НгОfЯxyТFxyxy xy НHіxНЇО^оzНyОZСxТЦТДП?НЇОX©Т⌡П\Т°НЇОV┼Т≤П>Т≥П$НЇОTVТ┤Т┬ПIНЇОR"Т┼П:Т▀П)НyОOМТ┐П-Т└П.НЇОM╧Т┴П1Т┼П2НЇОK└Т≈ПAТ≤НЇОIPТҐПIТЎНЇОGТ─П*Т│П9НЇОDГТНyОB╡ТТП:НЇО@~Т┌Т┐ПSНЇО>JТ²ПLТ·НЇО<ТфП?ТгНЇО9АТП@НyО7╛Т∙Т√ПCНЇО5xТ▄ПX{xТ█ НЇО3CТ√ПbТ≈НЇО1Т▐ПHТ░НЇО.зТП2Н*+О+▄Н*+О)WЪ┬Ї)=Г>Шб11. IntroductionCharter and historyThe purpose of this report is to collect and setdown our experience and intentions in the area ofprogramming environments. This material was pre-pared by a working group consisting of the follow-ing members of the PARC Computer ScienceLaboratory:L. Peter DeutschJames J. HorningButler W. LampsonJames H. MorrisEdwin H. Satterthwaite (Xerox SDD)Warren Teitelmanwith the occasional participation of Alan Perlis (YaleUniversity).We quickly decided that the right way toproceed was to address what we felt was the realquestion requiring resolution, namely to produce acatalog of programming environment capabilitieswhich included justified value, cost, and priorityevaluations.The working group was given a one-monthdeadline and held eight two-hour meetings.Needless to say, there were many areas we had totreat superficially because of the time constraint, andsome areas in which we realized we simply couldnot reach agreement. We also realize that we haveundoubtedly overlooked some significant issues andviewpoints. However, we expected much more inthe way of intractable disagreement than we actuallyexperienced. This suggests that we were successfulat avoiding religious debates, and instead weconcentrated on the technical issues.How should we compare programming environments?Before considering particular features that wefeel contribute to good'' programming environ-ments, it is important to consider how we can tellthat one programming environment is better'' thananother.Any evaluation must be in some context. Thereis no reason to believe that some one programmingenvironment could be optimal for all kinds ofprogramming in all places at all times. In ourdiscussions, we have focussed our attention on theforeseeable needs within CSL in the next few years,with particular attention to experimental program-ming. We have taken experimental programming tomean the production of moderate-sized systems thatare usable by moderate numbers of people in orderto test ideas about such systems. We believe that itwill be important to conduct future experimentsmore quickly and at lower cost than is possible atpresent.It is difficult to quantitatively compare program-ming environments, even in fixed contexts. A largenumber of qualitative comparisons are possible, butthe more convincing ones all seem to fall into twocategories, both based on the premise that thepurpose of a programming environment is, aboveall, to facilitate programming.First, a good programming environment willreduce the cost of solving a problem by software.The cost will include the time of programmers andothers in design, coding, testing, debugging, systemintegration, documentation, etc., as well as of anymechanical support (computer time, etc.) Since ourhuman costs continue to be dominant, one of themost convincing arguments in favor of a particularprogramming environment feature is that it speedsup some time-consuming task or reduces the needfor that task (e.g., it might either speed updebugging or reduce the amount of debuggingneeded). Bottleneck removal is the implicit argu-ment in much that follows.Second, a good programming environment willalso improve the quality of solutions to problems.Measures of quality include the time and spaceefficiency of the programs, as well as their usability,reliability, maintainability, and generality. Argu-ments relevant to this category tend to be of theform this feature reduces the severity of a knownsource of problems,'' or this feature makes it easierto improve an important aspect of programs.'' Thusa feature might be good because it reduces theНKaОfЯpНEОamqТiНEО]ьrТXН VОZпpТЇТ╦НEОXБТ╧Т╨П)НEОVТТ═П1НEОUТ╙ Т╚П(НEОSТYТZspНEОQ+ Н `ОN▄ТXН `ОMН `ОK└Н `ОJН `ОH|П"Н `ОFЬН@ОCПТ┬П0Т┴НEОBН VО@Т=Т>НEО>&ТкП+ТлНEО<8Т©П2НEО:KТ)Т*НEО8]ТЪП)ТНEО6oН VО4│Т)Т* НEО2⌠ТґТўНEО0╔Т╦П&Т╧ НEО.ЇТ┘Т├П$НEО,иТкТлП"НEО*шТ╒ТёП)НEО(НТ╛П2НEО'ТфП&ТгНEО%Т█ Т▌П*НEО#$Т╟Т╠НEО!6Т\Т]НEОHТП%НEОЁrТXП/Н VО╚pТП.НEОҐТТНEОоТ╩П)Т╪НEОАТ║Т╒НEОСН-УО]ьТ П'Т⌡Н+ДО[ЙТ║П%Т╒Н+ДОYЭТТ Н+ДОXТЖП/Н+ДОV!ТюП2Н+ДОT3Т≈Т≤Н+ДОREТЛrТМН+ДОPWpТ▒Т▓П*Н+ДОNiТ°П-Т²Н+ДОL{П1Н+ДОJ█Т∙Т√П.Н+ДОH÷ТТП(Н+ДОF╡Т╩П&Т╪Н+ДОDдН-УОBжТ²Т·П-Н+ДО@ХТ≥П3Н+ДО>ЗТ╔П%Ті Н+ДО=Т╠П!Т╡Н+ДО;ТТН+ДО90ТЮП.Н+ДО7BТН-УО5UТ"Т#Н+ДО3gТй rpТкН+ДО1yТ╘Т╙Н+ДО/▀ТЄП4Н+ДО-²ТсП3Н+ДО+╞Т П(Т⌡ Н+ДО)аТиП/Н+ДО'сТІТЇН+ДО%ЕТбТцН+ДО#ЬТаТбН+ДО" ТMП$ТNН+ДО Т)Т*Н+ДО.ТнП#ТоН+ДО@ТН-УОRТсТтН+ДОdТоrpТпН+ДОvТП.Н+ДО┬Т√П,Т≈ Н+ДО⌡ТП.ТН+ДОґТрП$ТсН+ДО©ТЄП(Т╣ Н+ДОяТ▓П7Н+ДО ЦТ▌П3Н+ДОУТЗТШЪ6@ў"_]5REQUIREMENTS FOR AN EXPERIMENTAL PROGRAMMING ENVIRONMENT2frequency of crashes in programs or because itmakes it convenient to optimize programs'performance.(These two categories could be reduced to oneby noting that there is a tradeoff between cost andquality. Thus by fixing cost, we could compare onlyquality; by fixing quality, we could compare onlycost. This seems to complicate, rather than simplify,a qualitative evaluation of features, so we will notseek to unify these two kinds of argument.)In the discussion that follows, we have attemptedto relate our catalog of important features'' to thesemore general concepts of what makes a goodenvironment'' whenever the connection is notobvious. In some cases, we have not been entirelysuccessful, because our experience tells us thatsomething is essential, but we haven't been able toanalyze that experience to find out why. In all cases,our arguments are more intuitive than logicallyrigorous. Strengthening these arguments would bean interesting research topic.We have been largely guided by experience withthree current programming environments availableto the PARC community: Interlisp, Mesa, andSmalltalk [Teitelman, 1978; Mitchell et al., 1979;Ingalls, 1978]. Both what we know about thestrengths and what we know about the limitations ofthese environments have been taken into con-sideration. It is of course dangerous to generalizetoo boldly from the intuitions and preferences ofusers: it is virtually impossible to be certain that theuseful features have been clearly distinguished fromthose that are merely addictive.НгОfЯpsТFpsps ps НEpНEОaЄТП+ТНEО_фТлТм НEО]ьН VО[ЙТфП)ТгНEОYЭТ╙П/Т╚НEОXТ┘Т├НEОV!ТяП$ТрНEОT3Т┴Т┼П0НEОREТюТаНEОPWТП+Н VОNiТ┼Т▀НEОL{Т┴Т┼П+НEОJ█ТТНEОH÷ТkП%ТlНEОF╡Т╘П2НEОDдТ0П#rpТ1НEОBжТўТ╞П'НEО@ХТ─Т│rpНEО>ЗТТНEО=Т╩Т╪НEО;ТН VО90Т∙Т√НEО7BТДТЕП#НEО5UТIspНEО3gТРП%rpНEО1yТТНEО/▀Т┴Т┼П!НEО-²Т9Т:НEО+╞Т©ТюНEО)аТэП"ТщНEО'сТ░П$Т▒НEО%ЕТ÷Т═П%НEО#ЬТЪ8E#╠*гDZ32. Catalog of programming environment capabilitiesWe have divided the capabilities of a pro-gramming environment into four categories. Virtualmachine / programming language refers to thosecapabilities that are primitive concepts in theprogramming language or in the virtual machine onwhich the programming language runs. Tools refersto capabilities for operating on programs. Packagesrefers to readily available programs that implementparticular clearly defined higher-level concepts.Other includes documentation and non-technicalconsiderations.It is important to note that the division betweentools and packages is a somewhat arbitrary one: in agood environment, there is little distinction betweenthe two, in that all the capability provided by thetools is available to the programmer in the form ofpackages, and all the capability of the language(including the packages, of course) is available to thehuman user to extend the functions of the tools.Additionally, it should be understood that we arediscussing a programming environment for a com-putationally rich environment: many of these capa-bilities are feasible only when each programmer hassubstantial computing power available to him at alltimes. More specifically, we expect our computingfacilities to be dominated by high-performancepersonal computers such as the Dorado [Lampson &Pier, 1980], which is a successor to the now inade-quate Alto computer [Thacker, et al., 1979]. Ourorientation toward single-user machines in adistributed environment requires us to consider anumber of operating system'' capabilities that mightbe taken for granted in a time-sharing environment.2.1. SummaryHere we enumerate the programming environ-ment capabilities we have considered and place eachin one of the four categories. In subsequent sectionswe shall discuss each capability in varying amountsof detail.Virtual machine / programming language(L1)Large virtual address space (>24 bits)(L2)Direct addressing for files(L2a)Segmenting(L2b)An enormous virtual address space(>48 bits)(L3)Well-integrated access to large, robust databases(L4)Memory managementobject/page swapping(L5)Object managementgarbage collection,reference counting(L6)Some support for interrupts(L7)Adequate exceptional condition handling(L8)User access to the machine's capability forpacked data(L9)Program-manipulable representation ofprograms(L10)Run-time availability of all informationderivable from source program (e.g., names,types, scopes)(L11)Statically checked type system(L12)Self-typing data (a la Lisp and Smalltalk), run-time type system(L13)Encapsulation/protection mechanisms (scopes,classes, import/export rules)(L14)Abstraction mechanisms; explicit notion ofinterface''(L15)Non-hierarchical control (coroutines,backtracking)(L16)Adequate run-time efficiency(L17)Inter-language communication(L18)Uniform screen management(L19)Inheritance/defaulting (e.g., Smalltalksubclassing; difficulty depends a lot on howmuch it has to do)(L20)Ability to extend language (e.g., operatoroverloading)(L21)Ability to create fully integrated localsublanguages(L22)User access to the machine's capability formulti-precision arithmeticНKaОfЯpНEОamqТiП2Н VО^epТ'Т(НEО\wТ■Т∙ rНEОZ┼ТТpНEОX°ТUП(ТVНEОVўТ⌡Т°НEОTюТ■П&rpТ∙НEОRрТ²rp Т·rНEОPДpТЄП3НEОNЖТkТlНEОMrpТ6Т7НEОKН VОI-Т·Т÷НEОG?Т▀Т▄НEОEQТ°П-Т²НEОCcТюП/ТаНEОAuТєП3НEО?┤ТП0НEО=≥Т┌ Т┐П)НEО;╚ТщТчП#Н VО9ҐТ┬Т┴П!НEО7пТфП(ТгНEО5БТ╡П,ТЁНEО3ТТ П$Т⌡НEО2Т╚П%Т╛ НEО0Т╟Т╠НEО.*ТCТDП!НEО,<Т▄П0НEО*NТ╠П!Т╡НEО(`ТнrpТоНEО&sТ≈П'Т≤НEО$┘ТЕП#ТФ НEО"≈Т┌Т┐НEО ╘Т Т⌡НEОЫsТXН VОЯpТЮТАНEОТ█Т▌НEОТ┐П-Т└НEО(ТґП+ТўНEО:Т Н+ДО^erТXП&Н+ДО[гpН0tpН+ДОYoН0Н0ОWН4( Н0ОTюН4(П!Н4(ОS<tpН+ДОPДН0П,Н0ОO`Н+ДОMН0П&Н+ДОJ╠Н0П%Н0ОI-Н+ДОFуН0Н+ДОD}Н0П'Н+ДОB%Н0П+Н0О@║ Н+ДО>JН0П%Н0О<фН+ДО:nН0П(Н0О8ЙП+Н0О7f Н+ДО5Н0Н+ДО2ІН0rpН0О12Н+ДО.зН0П,Н0О-VН+ДО*ЪН0П*Н0О){Н+ДО'#Н0П%Н0О%÷Н+ДО#GН0Н+ДО ОН0Н+ДО≤Н0Н+ДО@Н0П'Н0О╪П,Н0О8Н+ДОЮН0П*Н0О\Н+ДОН0П(Н0О─Н+ДО)Н0П+Н0О ╔^E ^$!ZґЪREQUIREMENTS FOR AN EXPERIMENTAL PROGRAMMING ENVIRONMENT4(L23)Good facilities for processes, monitors,interrupts(L24)Simple, unambiguous syntax (including infixnotation)(L25)Control over importation of names(L26)User packages as first-class citizens''(L27)Closures(L28)Full-scale inter-language communication(L29)User microprogramming(L30)Clean data and control trapping mechanisms(L31)Good'' exceptional condition handlingTools(T1)Fast turnaround for minor program changes(less than 5 seconds)(T2)Compiler/interpreter available with lowoverhead at run time(T3)Cross-reference/annotation capability(T4)Prettyprinter(T5)Consistent compilation(T6)Version control(T7)Librarian, program-oriented filing system(including Browser)(T8)Source-language debugger(T9)Dynamic measurement facilities(T10)Checkpoint, establishing a protectedenvironment(T11)History and undoing(T12)Editor integrated with language system(T13)More optimizing compiler if user willing tobind more tightlywith full compatibility(T14)Aids for incremental development (stubs,outstanding task list)(T15)Regression testing system(T16)Random testing aids(T17)(high capability) Masterscope(T18)Access to on-line documentation (Helpsys)(T19)Static analyzers: verifier, performancepredictorPackages(P1)Text objects and images(P2)Line objects and images(P3)Scanned (bitmap) objects and images(P4)Formatted document files(P5)More elaborate screen management(P6)Remote file storage(P7)Small data base manager(P8)Message transmission system(P9)Remote procedure call(P10)Event logging(P11)Background processing(P12)Generalized cache(P13)Document editing(P14)Forms(P15)Menus and other standard user interfaces(P16)History lists(P17)User access to full bandwidth of disk(P18)(English) dictionary service(P19)Teleconferencing(P20)Audio(P21)User access to full bandwidth of networksOther(X1)Adequate reference documentation(X2)Efficient'' interface for experts(X3)Uniformity in command interface(X4)Self-teaching'' interface for beginners(X5)Good introductory documentationНгОfЯpuТFpupu pu НEpНEОaЄНgТXП(НgО`0 НEО]ьНgП+НgО\TНEОYЭНgП!НEОW╔НgП)НEОUMНgНEОRУНgП'НEОP·НgНEОNFНgП*НEОKННgП'НEОH6rНEОE≈pНgП)НgОDНEОA╪НgП'НgО@7НEО=ЮНgП%НEО;┬НgНEО90НgНEО6ыНgНEО4│НgП)НgО2ЩНEО0╔НgНEО.MНgНEО+ЖНgП$НgО*r НEО(НgНEО%бНgП&НEО#jНgП+НgО!ФП)НEО▐НgП(НgОНEОЁНgНEО[НgНEОНgНEО╛НgП)НEОTНgП'НgОпН+ДОaЄrН+ДО_pН0Н+ДО\ЎН0Н+ДОZfН0П#Н+ДОXН0Н+ДОUЇН0Н+ДОS_Н0Н+ДОQН0Н+ДОN╟Н0Н+ДОLXН0Н+ДОJН0Н+ДОG╗Н0Н+ДОEQН0Н+ДОBЫН0Н+ДО@║Н0Н+ДО>JН0П(Н+ДО;РН0Н+ДО9 Н0П%Н+ДО7BН0Н+ДО4КН0Н+ДО2⌠Н0Н+ДО0;Н0П)Н+ДО,┐rН+ДО)ДpН0Н+ДО'█Н0П#Н+ДО%5Н0Н+ДО"щН0П)Н+ДО ├Н0ЪНE┴*гW┌CATALOG OF PROGRAMMING ENVIRONMENT CAPABILITIES52.2. Virtual machine / programming language(L1)Large virtual address space (>24 bits)(L2)Direct addressing for files(L2a)Segmenting(L2b)An enormous virtual address space (>48bits)(L3)Well-integrated access to large, robust databasesThe issue here is that things should scalesmoothly as programs grow to encompass morefunctions or larger data bases. As matters standnow, the time required tends to grow in predictableways, but when the space (addressing or memory)requirements grow beyond a certain point, radicalredesign of the program is usually required. Asecondary issue is the ability to combine programswithout running into the same kind of hardconstraint on the space taken up by the code.An address space of, say, 224 items would beadequate to hold all the code actually being used,even in a large system, but not adequate for all ofits data (e.g., the American Heritage dictionary);whereas an address space of, say, 248 items would beadequate for all the code and data of a very large,even multi-machine system. We tend to favor theformer, more conservative definition, since we donot understand how to provide an efficient, robustimplementation of the latter (more on the robustnessquestion below). However, we feel that it isessential that a transition across the 224-objectboundary not require the kind of wholesalereorganization of programs that such a transitionrequires in current language systems.System facilities for accessing large, external databases are required for several reasons:Many questions of organization and efficientimplementation can be solved once, rather thanover and over again by applications.The system itself needs data base facilities fortools like the program librarian.Access to externally stored data objects needs tobe smooth for the debugger and other systemfacilities, not just the application programs.Programs normally refer to internal objects withindividual references, but to external data bases withboth individual references and mass queries. Thereare three basic techniques for speeding up referencesto external data:Caches (good for individual references);Using sequentiality properties (good forsearching);Inversion (good for searching).All of these techniques should be available inpackage form.Integrity. A programming environment in which thefile system is viewed as an extension of the addressspace must be extremely robustmuch more so thanany programming system we now have. Our currentpractice is to make the truth'' for a data base be atext file, and not to expend a lot of effort onarmoring the binary version against all imaginableerrors. Notable exceptions are the basic filefacilities; we believe that a system that providesrobustness facilities usable at higher levels wouldhave a lot of advantages.Long-term integrity seems to require some kindof history or redundancy information. To protectagainst cosmic rays,'' it is sufficient to record thisinformation in a form that only the implementingprogram understands. To provide Undo capability,the history must be in a form that makes sense toclients.Another kind of integrity has to do with notlosing information. The following kinds of ideas areimportant in this connection:A computed object (e.g., a Mesa configuration)should keep track of how it got made, in enoughdetail to make it again. The description of theputting-together process should be program-manipulable.Files should be self-identifying in a way that isnot altered by their transfer between storagemedia or locations.It should not be possible to destroy all traces ofa file containing input (as opposed to purelyНЙОfЯpuТFП.НKapНEОaЄsТXП+НEО]ШpНgrtrНEО[єpНgrНgОYLpН┴r НgОVТpН┴rП#trН┴ОUpНEОSpНgrП,НgОQ■Н VОN▄pТBТCНEОL·ТП&ТНEОJ╠ТАТБП%НEОHцТ²Т·rpП&НEОFуТиrpТйНEОDГТуП1НEОBЫТСТТНEОAТ╪ТҐП#НEО?ТPТQНEО=/ТП-Н VО;AТчО;нuО;ApНEО9TТбП,ТцНEО7fТўП3НEО5xТШТЭП#НEО3┼Т▀ Т▄О4uО3┼prpНEО1°Т╛ТґП'НEО/ўТ╦Т╧НEО-юТЮП1НEО+рТ╧Т╨НEО)ДТ└П%Т┘НEО'ВТ)П'Т*НEО& Т>П&Т?О&√uО& pНEО$ТxТy НEО"-ТТП&ТУ НEО ?ТП%Н VОQТ▓Т⌠П#НEОcТП'Н `О[ТП,Н `ОmТ╣ТІН `ОТП$Н `ОwТвТьН `О┴ТП!Н `О │Т╒П.ТёН `О⌠ТыП$ТзН `О ╔ТП.Н+ъОaЄТТН+ъО_фТ▀П+Т▄ Н+ъО]ьТ÷Т═П$Н+ъО[ЙТ┘П5Н+ъОYЭТН-ЪОVТП(Н-ЪОSЛТП(Н-ЪОQЧ Н-ЪОNЖТН+ъОKНТ&Т'П(Н+ъОJТН+щОFЬs pТ┐Т└П'Н+щОE Т║П,Т╒Н+щОCТ─Т│Н+щОA.Т├Т┤Н+щО?AТ Т⌡П(Н+щО=SТЪП/Н+щО;eТнТоП&Н+щО9wТGТHН+щО7┴ТЫТЗН+щО5⌡ТНП3Н+щО3ґТН-УО1©Т╡П.Н+ДО/яТоrpТпН+ДО-ДТЇП3Т╦Н+ДО+ЖТиТйН+ДО*Т╚П1Н+ДО(ТЁТЄН+ДО&,Н-УО$>ТГП(ТХН+ДО"PТ┬П"Т┴Н+ДО bТН-ЪОZТаТбН-ЪОlТ┼Т▀Н-ЪО~Т╟Т╠Н-ЪО▒ТPП+Н-ЪОёН-ЪО⌡ТЁП1Н-ЪОґТ П%ТН-ЪО©ТН-ЪОЇТ÷П/Т═Н-ЪО иТРП#ТС ЪLE ^"│^ґSREQUIREMENTS FOR AN EXPERIMENTAL PROGRAMMING ENVIRONMENT6computed) information. The space requirementscan be kept under control by storing descriptionsof files (such as changes from other files) ratherthan all the bits.Even the dangling reference problem and variousgarbage collection approaches can be viewed asintegrity questions to some extent.(L4)Memory managementobject/page swapping(L5)Object managementgarbage collection,reference countingThese facilities are important for essentially thesame reasons as (L1) through (L3), namely, to freeprogrammers from excessive concern for the sizeand location of their code and data, for bothexplicitly named and dynamically constructedobjects.(L6)Some support for interruptsThe ability to interrupt program execution isessential, at least to gain control of runawayprograms, to allow interaction with long compu-tations, and to provide local multiprocessing; good''facilities are less important. We have no strongreligious feelings about the form of a processmechanism.(L7)Adequate exceptional condition handlingAn integrated mechanism for handling excep-tional conditions is required for clean debugging andfor the construction of robust programs; it helpsclarify program structure by separating normal andexceptional algorithms. Certain mechanisms are re-quired in this area: some way to unwind the stack,some way of catching an unwind, and programcontrol of error processing. What should be pro-vided beyond this is not agreedthe controversiesraging around the Mesa signal'' facilities are areflection of our poor understanding of the problem.(L8)User access to the machine's capability forpacked dataThe ability to pack data is essential to obtainacceptable storage efficiency for large data struc-tures. However, in a system without static (pre-runtime) type checking, the desire to access packedstructures efficiently (without checking or indirectionthrough descriptors) conflicts with the desire toprevent corruption of the storage managementsystem.There was a long discussion of why it is hard toadd packed data to Dorado Lisp, which centeredaround this protection question in the followingguise: how carefully should the system prevent theuser from smashing its underlying data structures.There wasn't much agreement on this point, but itdoes seem to have considerable practical importance,since a highly restrictive attitude makes it difficult tocode low-level parts of the system in itself.(L9)Program-manipulable representation ofprograms(L10)Run-time availability of all informationderivable from source program (e.g., names,types, scopes)These two issues are closely related: underlyingthem is our desire to make it easy to extend the setof tools, to make communication between sub-languages easy, and to break down as many aspossible of the artificial distinctions betweenprograms and their compilers, on one hand, anddata and their programs, on the other.A long discussion led to the conclusion that allthis information is currently available in Mesa,modulo the question of how stable the compiler'sinternal representation of the program as a treeshould be expected to be. Straightforward methods(like the ones used in CLisp) will allow compiledcode to be attached to source in a user-created datastructure, although it is certainly easier to do this inLisp, where interpretation is simple. Not exploredwas the usefulness of an interpreter for a subset ofthe language, such as currently exists in the Mesadebugger.(L11)Statically checked type system(L12)Self-typing data (a la Lisp and Smalltalk), run-time type systemThe primary value of type systems is descriptiveand structuralspecifying the intended properties ofЪНгОfЯpuТFpupu pu НEpН `ОaЄТ Т⌡Н `О_фТ┼Т▀Н `О]ьТ╒ТёН `О[ЙТН@ОXБТЮТАП'Н@ОVТТП.Н@ОUТП#НEОQNНgrТXП&НEОNЖpНgrП%НgОMrН VОJjpТЎТ©П"НEОH|ТўТ╞П&НEОF▌ТРП&ТСНEОD═Т"Т#НEОB╡Т╗П,НEО@еНEО=НgrТXН VО:pТ ТП"НEО8ТKТLП!НEО6(ТЩП#ТЧНEО4:Т┬П7НEО2LТХТИНEО0_Т1П&Т2НEО.q НEО*╦НgrТXП'Н VО'╟pТШП+НEО%бТ┌Т┐П!НEО#тТЙТКНEО!ФТ╪П'ТҐrpНEОЬr pТ╗Т╘НEОТ╗Т╘П)НEОТ ТНEО/ТгТхП!НEОAТиП1НEОSТП0ТНEОeТ┤Т┬НEОґНgrТXП+НgО) Н VО pТэП(ТщНEО 3ТТП,ТУН+ДОaЄТАТБП!Н+ДО_фТ╚Т╛Н+ДО]ьТ┬Т┴П!Н+ДО[ЙТТН+ДОYЭТSП!ТT Н+ДОXН-УОV!Т≥П0Н+ДОT3ТъТЮН+ДОREТП"Т Н+ДОPWТ╣П2Н+ДОNiТвП2Н+ДОL{ТЄП#Т╣ Н+ДОJ█Т┬П4Н+ДОH÷Т┤П9Н+ДОF╡ТП-Н+ДОBЫН0rТXП%Н0ОAuН+ДО?pН0rП(Н0О=≥П+Н0О< Н-УО9 pТ╩П%Т╪ Н+ДО7Т≈П,Т≤Н+ДО51Т#Т$П#Н+ДО3CТП,Н+ДО1UТ⌠П/Н+ДО/hТЙТК Н+ДО-zТП&Н-УО+▄Т╣ТІН+ДО)·Т'Т(Н+ДО'╟ТоТпН+ДО%бТП&Т Н+ДО#тТ²Т·Н+ДО!ФТйТкН+ДОЬТ П"Т⌡Н+ДОТ√П#Т≈Н+ДОТІП*ТЇН+ДО/Т╙П1Т╚Н+ДОAТфП)ТгН+ДОSН+ДО⌡Н0rТXН+ДОCpН0rprН0О©Н-УОЇpТ╒П0Н+ДО иТ▒Т▓p@ ┌*г^┴FCATALOG OF PROGRAMMING ENVIRONMENT CAPABILITIES7one's data, and providing a mechanism for ensuringconsistency between the suppliers and clients of aninterface. Enabling a compiler to generate bettercode is secondary. There are at least two dimen-sions of variability in type systems:whether type information is bound early, as inMesa, or late, as in Lisp and Smalltalk. There isa need to provide the programmer a selectionfrom a spectrum of alternativesMesa providesvariant records, which are a limited form of run-time binding, and Lisp has DeclTran, whichprovides some compile-time binding.whether types form a strict partition of thedata values, a coercion hierarchy, or some evenricher structure. We believe that a richerstructure is desirable. It might include provisionfor generic operators, for type-parameterizedprograms or schemes [Mitchell & Wegbreit,1977], for a more general notion of type assimply a partial specification of the behavior ofan object (perhaps like the Alphard needs'' list[Shaw, et al., 1977]), and for automatic pointwiseextension of operators over collections.It appears feasible to deduce much of the typeinformation for a program automatically, startingfrom the assumption that each variable only takes onvalues of one type [Milner, 1978; Cousot & Cousot,1977]. This would alleviate some of the nuisance ofhaving to write type declarations. Name conven-tions (e.g., capitalization or standard prefixes), ifinterpreted by the compiler, would also eliminatemost of the need for separate specification of typeinformation.This is an area ripe for research. We believethat, at a minimum, both the early-bound Mesa typesystem and the late-bound Lisp/Smalltalk typesystem must be supported (as alternatives) by anEPE.(L13)Encapsulation/protection mechanisms (scopes,classes, import/export rules)(L14)Abstraction mechanisms; explicit notion ofinterface''Abstraction mechanisms are important becausethey make explicit the logical dependencies of onepart of a program on another, while concealingimplementation choices irrelevant to the communi-cation between such parts. Thus, these mechanismsenable the ability to factor the development,debugging, testing, documentation, understanding,and maintenance of programs into manageablepieces, while leaving individual programmers theappropriate freedom to design those pieces.The ability to specify interfaces in the abstract,and to conceal their implementation, is important,but a difficult research area. It is possible to derivethis information about implicit interfaces after thefact using tools like Masterscope. The code pro-duced by an optimizing compiler need not reflectsource-level modularization, if tighter bindingimproves efficiency and the user is willing to pay theprice of more compilations and possibly decreaseddebugging information.We believe one facility in this area is absolutelyessential: it must be possible for a programmer tocontrol which names get exported from a package.In addition, it is important for the system to concealthe distinction between user-defined packages andsystem-provided primitives (types, operations, etc.) atleast as well as Mesa does.(L15)Non-hierarchical control (coroutines,backtracking)Coroutines and generators are essential: theyprovide a natural way to write transducers (programsthat consume a data stream and produce another),which in turn are often the best way to modularize adata transformation algorithm. Lisp has back-tracking, a control discipline sometimes used toexplore alternatives in goal-directed searching, butthere is considerable disagreement over the mecha-nism used to provide it, and its uses can probably becovered by more restricted coroutine and Undomechanisms. Closures are a method of providing awide variety of interesting control and bindingenvironments, but we are not sure whether they canbe implemented efficiently enough, or are structuredenough, to replace the more specialized coroutineconstructs.ЪНЙОfЯpuТFП.НKapНEОaЄТ⌡ Т°П'НEО_фТ╠Т╡НEО]ьТвТьНEО[ЙТцТдП*НEОYЭТП%Н `ОVТТ■П/Н `ОUТ▄П2Н `ОSТвТьН `ОQ+Т╧П$Т╨Н `ОO=Т░Т▒Н `ОMOТ ТН `ОKaТП#Н `ОHYТЕТФН `ОFkТ╣П/Н `ОD}Т6П+Н `ОB▐Т■П)Т∙ Н `О@║ТEП-Н `О>ЁrpТFН `О<фТТН `О:ьТЁП!ТЄН `О8ЙТіТїП)Н `О6ЭТ▓rpТ⌠ Н `О5ТП(Н@О2ТЩ ТЧП$Н@О0ТП1Н@О.*Т─Т│П!Н@О,<Т Т⌡П)Н@О*NТ▓П$Т⌠Н@О(`ТжП#ТвН@О&sТП'Т Н@О$┘ТДТЕН@О"≈Т╧П.Т╨Н@О ╘Н VО╩Тн ТоП$НEОмТ┤П2НEОъТFП-НEОЯТДП-ТЕНEОНEОKНgrТXП,НgОгНEОopНgrП*НgО КН VО ЦpТРП$ТСНEОУТ╩П+Т╪Н+ДОaЄТТН+ДО_фТдП(ТеН+ДО]ьТ°П2Н+ДО[ЙТbТcН+ДОYЭТТН+ДОXТFП+Н+ДОV!ТП,ТН+ДОT3ТП+Н-УОREТ© ТюП'Н+ДОPWТоТпН+ДОNiТ⌠Т■Н+ДОL{ТыТзrpН+ДОJ█ТтП,ТуН+ДОH÷То ТпП%Н+ДОF╡Т╒ТёН+ДОDдТ─Т│Н+ДОBжТхП'Ти Н+ДО@ХТН-УО>ЗТё ТєП$Н+ДО=Т©П"ТюН+ДО;Т╩Т╪Н+ДО90Т▄Т█П'Н+ДО7BТчТъН+ДО5UТ└П"Т┘Н+ДО3gТН+ДО/ўН0rТXП%Н0О.*Н-УО+"pТ ТН+ДО)4Т└Т┘Н+ДО'FТюП0Н+ДО%XТ┐П2Т└Н+ДО#jТ/П.Н+ДО!}ТП-ТН+ДО▐ТэП%ТщН+ДО║Т╣ТІП*Н+ДОЁТ─Т│П,Н+ДОеТТН+ДОвТ÷Т═П%Н+ДОИТ+П'Т,Н+ДОШТ⌠П!Т■Н+ДО Т▀Т▄Н+ДО ТэТщН+ДО2 ┬@ў"│_]^REQUIREMENTS FOR AN EXPERIMENTAL PROGRAMMING ENVIRONMENT8(L16)Adequate run-time efficiencyThe ultimate efficiency criterion is whether asystem can meet its external specifications andconstraints (responsiveness to human users orprogram clients). Computational efficiency equiva-lent to Alto Mesa, coupled with the larger realmemory and faster disk of the Dorado, is adequatefor many projects; for Lisp and Smalltalk, we thinkwe can attain this through internal re-engineering.For other, more computation-intensive systems, atleast another factor of 5 is attainable (based on rawhardware speed).(L17)Inter-language communicationWe believe the best way to attain the benefits ofuniform methods for accessing the machine'sfacilities at the lowest level is for all languagesystems to run under a single operating system thatis carefully constructed not to impose unnecessaryspace or time penalties on its clients. For theDorado, we believe that the Pilot operating systemsatisfies this criterion [Redell, et al., 1979].Inter-language communication at a higher levelhelps reduce duplication of effort and also providesone way of attaining extra efficiency for particularfunctions. Calling Mesa subroutines from Lisp orSmalltalk will probably be adequate. Communi-cation through the network or file system interfacerequires very little work, but is too inefficient. Thegeneral problem seems difficult and less important.(L18)Uniform screen managementUse of the display is pervasive in our interactivesystems. Lack of uniformity leads to duplicatedeffort, often of low quality since an individualbuilder cannot easily draw on all past experience ordevote the time to taking advantage of it. On theother hand, too much central control over screenmanagement may frustrate the desire to experimentwith new paradigms for interaction.We believe that it is possible to virtualize'' thescreen and the user input devicesthat is, requirepeople to write programs on the assumption thatthey will only have access to a subpart of the screenand to a slightly filtered stream of input eventsina way that will not markedly impede our ability toexperiment, and that will have a large payoff interms of the user's ability to construct a screenenvironment containing multiple windows on dif-ferent programs. At a minimum, the user must havedirect access to all the capabilities of RasterOp[Newman & Sproull, 1979], appropriately mapped orconfined to work on a virtual screen.(L19)Inheritance/defaulting (e.g., Smalltalksubclassing)Languages that provide for programmer-controlled defaulting or inheritance reduce the timeand chance for error in the programming process bymaking it unnecessary to write the same code orparameter values over and over again. The basicidea is that one should be able to write programs ina way that only specifies how they differ from somepreviously written program. Examples includedefault standard values for procedure arguments(how does this call differ from a standard'' call?),variant records (how does this particular recorddistinguish itself from the invariant part?), and theSmalltalk subclass concept (how does this class ofobjects differ from some more general class?)We did not discuss this area beyond observingthat it is somewhat related to the schemes questiondiscussed under (L12), and that Smalltalk seems toderive considerable benefit from it.(L20)Ability to extend language (e.g., operatoroverloading)Languages may be extended by users in a varietyof ways. Data structure extension, through user-defined data types and associated operations, makesit possible to write programs in terms of concept-oriented rather than implementation-oriented dataobjects. Syntax extension, through user definition ofnew language constructs, allows the user to definespecialized notations that may be valuable forparticular tasks: this is discussed in detail in (L21).Operator extension, the ability to define meaningsfor basic language constructs such as arithmetic oriteration when applied to user-defined objects,brings some of the benefits of notational extensionwith less drastic consequences in programНгОfЯpuТFpupu pu НEpНEОaЄНgrТXН VО^╛pТШП$ТЭ НEО\ЎТ0Т1НEОZпТoТpНEОXБТ╧Т╨НEОVТТЧТЪНEОUТї Т╗П'НEОSТ·Т÷НEОQ+ТяТрП!НEОO=ТЦП1НEОMOТ²Т·П(НEОKaТНEОG╗НgrТXН VОD═pТ▓ Т⌠П#НEОB╡ТП!Т─ НEО@еТП%ТНEО>вТ╒ТёНEО<ИТяТрНEО:ШТЧТЪНEО9 Т╦П2НEО7ТП"rpН VО51ТоП.НEО3CТ╒П+ТёНEО1UТаТбНEО/hТд ТеП&НEО-zТН ТОНEО+▄ТІТЇНEО)·Т П%Т⌡НEО'╟ТЄП(Т╣ НEО#ЬНgrТXН VО ОpТ П&Т⌡НEОТПТЯП'НEОТП%Т НEО&Т⌡Т°НEО8Т╠П&Т╡НEОJТщ ТчП%НEО\Т╘П1НEОnТП#Н VО─Т╘П!Т╙НEО▓Тд ТеП$НEО ╔ТАП/НEОЇТ▐П*Т░ НEО иТёТєП.Н+ДОaЄТ╙П/Т╚Н+ДО_фТХТИН+ДО]ьТЩП(ТЧН+ДО[ЙТПП*ТЯН+ДОYЭТ│Т┌П"Н+ДОXТТН+ДОV!Т┴П.Т┼Н+ДОT3ТП%Н+ДОPzН0rТXП'Н0ОNЖН-УОKНpТэП&Н+ДОJТїП/Т╗Н+ДОHТ█ Т▌П(Н+ДОF$ТэП'ТщН+ДОD7ТмП&Тн Н+ДОBIТ▒Т▓Н+ДО@[Т▒Т▓П$Н+ДО>mТHТIН+ДО<ТТН+ДО:▒ТЇП.Т╦Н+ДО8ёТП0Н+ДО6╣Т╩П-Т╪Н+ДО4гТоТпН+ДО2зТП-Н-УО0ЛТфП#Тг Н+ДО.ЧТ╘Т╙Н+ДО-ТЁТЄН+ДО+"ТП$Н+ДО'iН0rТXП*Н0О%ЕН-УО"щpТ┬П%Т┴ Н+ДО ОТАП1Н+ДОТёТєН+ДОТгТхН+ДО&ТЬП1Н+ДО8Т├П6Н+ДОJТфП(Тг Н+ДО\Т?П!Т@Н+ДОnТ╞П7Н+ДО─ТоТпН+ДО▓ТаТбН+ДО ╔ТSП&ТTН+ДОЇТІТЇП!Н+ДО иТБП!ТЦЪ"E ┌*г^┴wCATALOG OF PROGRAMMING ENVIRONMENT CAPABILITIES9readability.Data structure extension is accepted as animportant part of all modern programminglanguages. Syntax extension has fallen into disfavorbecause of a lot of bad experience; we believe thishappened partly because the tools did not supportextensions as well as they did the base language.Operator extension is already present in a number oflanguages such as Algol 68: we did not discuss itsmerits. It is interesting to note that Smalltalk isfounded on the notions of data structure andoperator extension, but that the syntax extensionfacilities present in the 1972 version of the languagehave been removed.(L21)Ability to create fully integrated localsublanguagesAll language systems actually have many smallsublanguages for special purposes. For example,Mesa has not only the Mesa language, but theC/Mesa configuration language, the debuggercommand language, the programming language sub-set acceptable to the debugger's interpreter, and thevery small languages used to control the compilerand binder from the Executive command line.Fully integrated,'' as an ideal, means that controland data should be able to pass freely betweensublanguages, and that the facilities (editor,prettyprinter, I/O system, etc.) applicable to theprimary programming language should also beapplicable to the other sublanguages.Lisp is unique in that its dozen or sosublanguages all provide the ability to embedarbitrary Lisp computations in them. For example,in the middle of the editor one can compute (bycalling an arbitrary program) data to be inserted,possibly as a function of the thing being edited, oreven a sequence of edit commands to execute. Thefollowing features of Lisp seem to have made thecreation of integrated sublanguages easier:S-expressions are a simple, standard internalrepresentation of parse trees for all sublanguages.Lisp provides a standard method of sharingnames and passing environments, namely asingle, very simple name environment (atoms)that all sublanguages share. (This has bothadvantages and drawbacks: it leads to the FLG''phenomenon, for example.)Many internal system hooks'' are available tothe sublanguage implementor. (This too has itsdrawbacks: it tends to make sublanguages morefragile.)The standard system contains packages (pretty-printer, table-driven lexical scanner and paren-thesis parser) which make I/O of program-likestructures easy.The sublanguages that don't take advantage of thesecharacteristics, such as CLisp, QLisp, and KRL, findtheir lives a lot more difficult. If we were willing tolimit the complexity of sublanguages to that of S-expressions, i.e., procedures and conditionals, thenwe could devise an S-expression-like representationfor Mesa also. (Extending this to, say, arithmeticexpressions not only involves a complex parser andprettyprinter, but in a statically typed language likeMesa also requires taking type declarations intoaccount to decide what the operators in the sourcetext actually mean. Admittedly, the S-expression-like approach doesn't allow embedding of areasonable subset of Mesa itself in a sublanguage,and it doesn't address the point that some of thehighest payoff comes from the integration oflanguages, like KRL, that don't look like S-expressions.)We also noted that no matter what features thelanguage and environment provided, proper pro-ceduralization of facilities was essential: even Lisphas sublanguagesin particular, the compiler controlsublanguagethat are implemented so as to interactwith the user directly, and that therefore cannot beconsidered integrated.To sharpen our ideas about what integrationmeans, we considered a straw man'': a system inwhich all languages (editor, interpreter, etc.) shareda screen interface (window manager) but wereotherwise entirely separate. This led us to thefollowing observations:This model was proposed as one that imposedminimal requirements on the individual sub-ЪНЙОfЯpuТFП.НKapНEОaЄН VО_фТMТNНEО]ьТ╨Т╩НEО[ЙТ≈П'Т≤ НEОYЭТ╚П#Т╛НEОXТюП1НEОV!ТыТзНEОT3Т│П%Т┌НEОREТ╨П2НEОPWТь ТыП&НEОNiТ2 Т3НEОL{ТЖП1НEОJ█Т■Т∙П!НEОH÷ТНEОDГНgrТXП(НgОCcН VО@[pТоП"Тп НEО>mТНТОНEО<ТП(ТНEО:▒Т²П+НEО8ёТ П!Т⌡ НEО6╣Т÷П5НEО4гТнП(ТоНEО2зТ2Т3НEО0ЛТдТеНEО.ЧТВТЬНEО-Т╠Т╡НEО+"ТТНEО)4ТLТMНEО'FТП%Н VО%XТt ТuНEО#jТFТGНEО!}Т╔П$Ті НEО▐ТмТнНEО║ТъП"ТЮНEОЁТ╙П1Т╚НEОеТ√Т≈НEОвТфП'ТгНEОИТП+Н `ОАТ'П$Т(Н `ОСТ┼П3Н `О КТТН `ОЩТJТKН `О ТПП$ТЯН-ЪОaЄТ П'ТН-ЪО_фТ┌Т┐Н-ЪО]ьТН-ЪОZпТжТвП"Н-ЪОXБТ╚Т╛Н-ЪОVТТ╡П(ТЁН-ЪОUН-ЪОQЧТсТтН-ЪОPТзП)ТшН-ЪОN#ТмТнН-ЪОL5ТН+ъОI-Т■Т∙Н+ъОG?Т▄Т█Н+ъОEQТ┴Т┼П'Н+ъОCcТдП/ТеН+ъОAuТыП!ТзН+ъО?┤Т╪ТҐП!Н+ъО=≥ТкП(Тл Н+ъО;╚Т╙Т╚Н+ъО9ҐТ╙Т╚П!Н+ъО7пТТН+ъО5БТЁТЄН+ъО3ТТжП2Н+ъО2ТsТtН+ъО0ТкТлН+ъО.*ТмП1Н+ъО,<Т[Т\Н+ъО*NТUrpН+ъО(`Н-УО&sТўТ╞П!Н+ДО$┘ТП.Н+ДО"≈ТоТпН+ДО ╘Т└П#Т┘Н+ДО╩Т≤П#Т≥Н+ДОмТ╗П4Н+ДОъТН-УОЯТТ Н+ДОТцТдН+ДОТ╟Т╠Н+ДО(Т4П#Т5Н+ДО:ТТН+ДОLТН-ЪОDТкП+Н-ЪО VТТvE х"│^CbREQUIREMENTS FOR AN EXPERIMENTAL PROGRAMMING ENVIRONMENT10systems, at least if they only dealt with the screenas a sequential character I/O device. This maynot be a proper assumption, however: despitenumerous attempts, no such package has everbeen developed for the Alto, and this may bebecause nobody has been able to develop asatisfactory model for the interface. We agreedthat things become more complex as thesubsystem's view of the display becomes moresophisticated (e.g., an editable document, abitmap).While this model allowed for considerablecommunication (by human transfer of charactersfrom output in one window to input in another),it had two serious deficiencies: it made noprovisions for communication under program,rather than manual, control, and it required thatall transmitted information be in text form.(Note that even transmission of file namesrequires integration in the sense of sharing acommon file system.)While we did not reach any clear conclusions, wewere able to agree on the following:This is an important area for discussion, but itneeds more time than we had available to us.Integration really means a common model forcommunication.The one catalog entry we have now should bebroken down into multiple features of differingpriorities.If all the other Priority A features in the catalogwere provided, Mesa could readily supportsublanguages of the complexity of S-expressions.Adequate proceduralization is necessary for apackage implementing a sublanguage to beusable.A major source of difficulty is the sharing orpassing of environment information betweensublanguages. One part of this difficulty issimply addressing or naming objects to beshared. Another part is making sure that sharedobjects are interpreted the same way (in Mesa,making sure the communicants share the samedeclarations for the objects). One way aroundthis is to have a limited number of globallyagreed-upon structures, such as strings or S-expressions, and then encoding more specializedlanguages within them and interpreting them byconvention or agreement (as Lisp does).We also do not agree on the importance of fullyintegrated sublanguages: a number of Lisp users feelthis item should have very high priority.(L22)User access to the machine's capability for multi-precision arithmeticMany language systems, though implemented onmachines in which multi-precision arithmetic inassembly language is relatively straightforward, makeit impossible for the user to get at these facilities(such as the carry from single-precision addition, orthe double-by-single division that most machinesprovide in hardware). There is no excuse for this,especially on machines with relatively short (16-bit)words.(L23)Good facilities for processes, monitors, interruptsSynchronization between logically asynchronousprocesses is necessary in many programs, either forfunctional reasons (a system should be able to listenfor incoming mail, send a file to be printed, andcarry out interactive editing simultaneously) or forefficiency (overlapping computation with disktransfers). The language system, through an under-lying operating system if necessary, should providemechanisms that help the programmer write pro-grams that involve multiple processes. There are anumber of adequate, though conflicting, models ofthese mechanisms available, such as the Mesa andPilot facilities and the Smalltalk scheduler. We didnot discuss this area at all.(L24)Simple, unambiguous syntax (including infixnotation)While CLisp leaves a very large gap betweenwhat can be precisely defined and what the user canreasonably do, and while Mesa syntax is regrettablycomplex (5 closely-spaced pages), we are willing toНгОfЯpuТFpupu pu НEpН `ОaЄТ─Т│Н `О_фТґТўН `О]ьТЕТФН `О[ЙТГП"ТХН `ОYЭТмП)ТнН `ОXТ Т Н `ОV!ТўТ╞Н `ОT3ТmП"ТnН `ОREТьТыН `ОPWТQТRН `ОNiН `ОKaТd ТeН `ОIsТёП#Тє Н `ОG┘Т▐П"Т░Н `ОE≈Т!Т" Н `ОC╘Т ТН `ОA╪Т²Т·Н `О?нТ%Т&Н `О=ЮТ;П*Н `О;РТПТЯН `О:ТН@О6ЭТфТгП(Н@О5ТП$Н `О2Т©ТюН `О0ТяТрН `О-ТЮП+Н `О+" Н `О(ТцТдН `О&,Т╧Т╨Н `О$> Н `О!6Т≥П3Н `ОHТSП!ТTН `ОZТ║П!Т╒Н `ОRТП'Т Н `ОdТNТOН `ОvН `ОnТэП#Тщ Н `О─ТEП*Н `О▓ТТН `О ╔ТAП&ТBН `ОЇТ■Т∙П(Н `О иТцП(ТдН-ЪОaЄТоТпН-ЪО_фТхП.Н-ЪО]ьТВ ТЬП"Н-ЪО[ЙТТН-ЪОYЭТ╛П/Н-ЪОXТ╔П&ТіН-ЪОV!ТП'Н+ъОSТпТяН+ъОQ+Т┬П/Т┴Н+ъОO=ТП)Н+ДОK└Н0rТXП2Н0ОJН-УОFЬpТ·Т÷Н+ДОE Т+Т,Н+ДОCТ┬Т┴П$Н+ДОA.ТкП*Тл Н+ДО?AТ╒П2ТёН+ДО=SТП'ТН+ДО;eТ╟П"Т╠Н+ДО9wТўТ╞Н+ДО7┴Н+ДО3пН0rТXП3Н-УО0хpТЮП.Н+ДО.зТўТ╞Н+ДО,МТ⌠П&Т■Н+ДО*ЪТпП1Н+ДО)ТйП4Н+ДО'#Т╒П#Тё Н+ДО%5Т÷П,Т═Н+ДО#GТҐП+ТЎН+ДО!YТГП#ТХ Н+ДОkТ╙ Т╚П)Н+ДО}ТҐП.ТЎН+ДО░ТдТеН+ДО╒Т÷Т═П%Н+ДОЄТН+ДОШН0rТXП+Н0ОwН-УОopТГП#ТХН+ДО │Т┼П&Т▀Н+ДО⌠Т╒П'ТёН+ДО ╔ТЁП$ТЄЪb@ ^*г^ґNCATALOG OF PROGRAMMING ENVIRONMENT CAPABILITIES11tolerate problems of this sort under the assumptionthat the primary users of the system will be experts,and that novices will be able to learn a useful subseteasily.(L25)Control over importation of namesAs discussed under (L13) and (L14), importcontrol seems less important than export control.The reason is that the implicit use of an interfacecan be deduced locally by nothing what names areused; for export, the issue is global and not undercontrol of the provider of the package without someexplicit specification.(L26)User packages as first-class citizens''We would like user-defined packages to functionas first-class citizens'' on a par with built-inprimitives (types, operations, etc.) However, theEuclid experience seems to indicate that this is verydifficult [Popek, et al., 1977]. In Smalltalk, this goalhas been achieved except for some I/O issues, at theexpense of not having static type structure in thelanguage at all.(L27)ClosuresSee (L15) for discussion.(L28)Full-scale inter-language communication(L29)User microprogrammingThe ability to share data and pass control freelybetween programs written in any of the majorlanguages depends on carefully coordinated use ofcertain basic resources such as the peripheral devicesand the machine's address space. We think this isless urgent than the more restricted facilities of(L17): the primary motivation for changinglanguages in mid-program is increased efficiency,and dropping into Mesa from Lisp or Smalltalkprovides this, although it does not address thesecondary motivation, which is the ability to takeadvantage of work already done (or moreconveniently done) in another language.In cases requiring extreme speed, it may benecessary to give the programmer a way to writeapplication-dependent microcode and link it to thesystem in a way that provides at least some checkingthat it will not destroy the rest of the system. Wedid not discuss this.(L30)Clean data and control trapping mechanismsThere was a long and inconclusive discussion.Apparently we don't really know what this point isabout. At one extreme of data trapping'' there is asimple address trap, as on early machines. At theother extreme is KRL. No one was willing toespouse either extreme. We noted that:Programming with data abstractions can helpwith this problem, since there is then a betterhandle on when data is being changed.Checking some predicate at periodic intervals(e.g., on every control transfer) may be quiteadequate when data trapping is being used tocatch core smashing'' types of bugs. Mesaalready has this facility.Many interesting cases can probably be handledby using the primitive trapping facilities of themapping hardware.(L31)Good'' exceptional condition handlingAs discussed above, we really don't know whatthis would mean. Roy Levin's thesis, among otherpublished papers, may be relevant [Levin, 1977].2.3. Tools(T1)Fast turnaround for minor program changes(less than 5 seconds)Our concern with fast turnaround comes fromthe observation that programming should be thinkbound, not compute bound. There are severalknees'' (points of substantial non-linearity) in one'sperception of response delays. One such knee is inthe vicinity of 3 to 5 seconds. We believe that it isessential to reduce the system time for minorprogram changes to below this point.НЙОfЯpuТFП.НJ╠pНEОaЄТ╙П3НEО_фТ■П,Т∙НEО]ьТ┤Т┬НEО[ЙНEОX2НgrТXП!Н VОU*pТТНEОS<ТПТЯНEОQNТюП)Та НEОO`ТўТ╞П*НEОMrТ╡ТЁНEОK└Т░Т▒НEОI√ТНEОEчНgrТXП)Н VОBжpТ■Т∙П"НEО@ХТ?П$Т@ НEО>ЗТЫТЗНEО=Т⌡Т°НEО;Т█Т▌rpП!НEО90Т├Т┤НEО7BТрТсНEО5UТНEО1°НgrН VО.■pНEО*шНgrТXП'НEО(└pНgrН VО%|pТё ТєП#НEО#▌ТП&ТНEО!═ТхП.ТиНEО╡Т┴П6НEОдТ╟П$Т╠ НEОжТТП"НEОХТ╠ Т╡НEОЗТЩТЧНEОТЬТЫНEОТТНEО1ТыП-ТзНEОCТ╚Т╛ НEОUТП'Н VОgТП(Т НEО yТжТвНEО▀ТҐП.ТЎН+ДОaЄТ┤Т┬П+Н+ДО_фТ╙П(Т╚Н+ДО]ьТН+ДОZ Н0rТXП*Н-УОWpТГТХН+ДОU*Т╙Т╚Н+ДОS<Т▄П6Н+ДОQNТЇТ╦Н+ДОO`ТЖТВН+ДОMrТП'Н-ЪОJjТП+Н-ЪОH|ТнТоН-ЪОF▌ТП%Н-ЪОC├ТП-Н-ЪОA≤ТЙТКН-ЪО?╙ТзТшН-ЪО=╪ТП&ТН-ЪО;оТН-ЪО8фТ╘П.Н-ЪО6ыТаТбН-ЪО4КТН+ДО12Н0rТXП'Н-УО.*pТ╪ТҐН+ДО,<Т╛П%ТґН+ДО*NТЫТЗН+ДО%÷sТX Н+ДО!ФpН0rП)Н0О bН-УОZpТэП&ТщН+ДОlТгП*ТхrН+ДО~pТ-Т.rpН+ДО▒Т П/Т⌡Н+ДОёТ°Т²Н+ДО╣Т≈Т≤Н+ДОгТ1П'Т2Н+ДОыТП$Ъ 4ED"│_г$REQUIREMENTS FOR AN EXPERIMENTAL PROGRAMMING ENVIRONMENT12(T2)Compiler/interpreter available with lowoverhead at run timeThe issues here are similar to those in (L9-10),namely, to reduce the mental and execution gear-shifting'' overhead caused by artificial divisionsbetween compilation and execution environments.A sufficiently fast compiler is just as good as aninterpreter for executing typed-in programs orprograms constructed on-the-fly by other programs.However, it is essential that one be able to savesome form of compiled code, for applications thatembed procedures in data structures.(T3)Cross-reference/annotation capability(T4)PrettyprinterThese capabilities contribute substantially to thereadability of programs, which in turn has a largeeffect on the ease of maintenance. A simple batch''cross-reference facility is essential; more sophis-ticated facilities, such as those of Masterscope, areless urgent.(T5)Consistent compilation(T6)Version controlConsistent compilation is an efficiency issue: toget the right thing to happen without blindlyrecompiling and reloading everything. Versioncontrol is more fundamental. It has two majoraspects: history and parameterization.Under history, we want to be able to tell exactlyhow a particular system or component wasconstructed, and what it depends on (e.g., microcodeversion, interface definition or whatever). Further-more, we want to be able to reconstruct a com-ponent automatically. This requires that everycomputation involved in its original constructionmust record all its inputs, and be prepared to repeatitself from this record. Since the inputs may be(references to) files, it is also necessary to have anaming scheme for files that is unique over thewhole universe, and a guarantee that no file willever be destroyed (unless the rule for reconstructingit is saved, together with all the required inputs).Under parameterization, we want a systematicway of specifying the construction of a system thatnever existed before (e.g., it is for a new microcodeversion, or different implementations of the sameinterfaces are combined in a new way). We agreedthat we don't aspire to solve this problem in the fullgenerality required by IBM.Replacing code in an existing system is inprinciple a special case of consistent compilationthe general question is when a complete butexpensive procedure (recompilation, reloading, etc.)can be bypassed. We note that replacing code is inpractice not just an efficiency issue, since getting thesystem back to the exact current state is not possiblein general. The reason is that the current statedepends on user program execution, and the userprogram cannot be counted on to follow the rulesmentioned under history, which we impose on thesystem programs that make up the environment.(T7)Librarian, program-oriented filing system(including Browser)Coordinating access by multiple maintainers to aprogram made up of many packages requires someautomation to avoid loss of consistency or evenvaluable information. For example, a librarianallows programmers to check out'' (in the sense ofa library book) a module for modification; othertools can assist in re-integrating versions of modulesthat have been modified separately. A system richlyendowed with packages also needs some automationto catalog them and their documentation in a waythat actively aids users in finding what they need.(T8)Source-language debuggerIt is essential that the programmer be able todebug using the same language constructs andconcepts used in writing the original program. Thisis facilitated by a minimum of distinctions betweencompile-time and run-time environmentssee also(L10) and (T2).ЪНгОfЯpqТFpqpq pq НEpНEОaЄНgrТXП'НgО`0Н VО](pТ╩П'Т╪НEО[:Т╣П2НEОYLТ;П2НEОW^ТЩТЧНEОUpТьТыНEОS┌ТYТZНEОQ■Т╡ТЁНEОOїТчТъНEОM╧ТдТеП%НEОKкТП$НEОHНgrТXП%НEОE╩pНgrН VОB╡pТІТЇНEО@еТцП!ТдНEО>вТ─Т│П$НEО<ИТ'П+Т(НEО:ШТдТеНEО9 ТНEО5UНgrТXНEО2ЩpНgrН VО/УpТ╩П.Т╪НEО.Т4Т5НEО,Т=П%Т>НEО*+ТЖТВНEО(=ТП&Н VО&OТ∙П$Т√НEО$aТ▌П$Т▐НEО"sТ┴П#Т┼НEО ├ТЄП,Т╣НEО≤ТАП)ТБНEО╙Т'Т(НEО╪ТП$ТНEОнТ▄rpТ█П&НEОЮТвТьНEОРТлП+Тм НEОТОТПНEОТэП'Тщ НEО)Т≈П&Т≤НEО ;ТрТсП(Н-УОaЄТЖТВН+ДО_фТўТ╞П-Н+ДО]ьТ°Т²П(Н+ДО[ЙТА ТБП&Н+ДОYЭТ·П1Н+ДОXТ┼Т▀П)Н+ДОV!ТН-УОT3Т- Т.Н+ДОREТ©П3Н+ДОPWТDП+Н+ДОNiТаП.ТбН+ДОL{Т≈П3Н+ДОJ█Т▌rpТ▐П$Н+ДОH÷Т▀Т▄Н+ДОF╡ТИТЙП%Н+ДОDдТяП&ТрН+ДОBжТЎП0Н+ДО@ХТ©П/Н+ДО>ЗТШТЭН+ДО;AН0rТXП)Н0О9ҐН-УО6╣pТ П.Т⌡Н+ДО4гТўТ╞Н+ДО2зТТН+ДО0ЛТТ rН+ДО.ЧpТ÷Т═Н+ДО-ТДП*ТЕН+ДО+"Т≤Т≥П&Н+ДО)4Т▀П&Т▄ Н+ДО'FТ≤Т≥Н+ДО%XТ╪ТҐН+ДО#jТцТдН+ДО╡Н0rТXН-УО╙pТьП.Н+ДО╪Т2Т3Н+ДОнТ√П.Т≈Н+ДОЮТ╚Т╛Н+ДОРrpТrpТН+ДОТfEТ*г[KCATALOG OF PROGRAMMING ENVIRONMENT CAPABILITIES13(T9)Dynamic measurement facilitiesThese facilities are necessary to understand thebehavior of complex programs under conditions ofactual use. Smalltalk and Mesa have a Spy,'' whichworks by sampling the program counter, and Lisphas Breakdown. The Smalltalk and Mesa facilitiesare relatively little used: the Mesa facilities arepoorly documented and supported, and the natureof Smalltalk is such that there is often littlemeaningful tuning one can do. Available for Mesaprograms area facility for counting frequency and timebetween any pair of breakpoints;a facility for writing an event in a log, either byprocedure calls, or by action to be taken at abreakpoint; anda transfer trap'' mechanism that logs data atevery control transfer, together with somestandard ways of reducing this data to producethe same kind of information that a Spyproduces.We agree that something as good as Breakdown isgood enough.(T10)Checkpoint, establishing a protectedenvironmentCheckpointing is needed to be able to protectoneself against unexpected machine or systemfailures. The weakness of the facilities in all threecurrent systems was noted: file state is not saved,nor is there any check that it hasn't changed on arestart. Protected environment means the ability toinstall a new version of something in a system andstill be able to revert to the old version verycheaply; cheap checkpoints can provide this. Cheapcheckpoints can be done in a paged system withcopy-on-write techniques.(T11)History and undoingHistory refers to the system keeping a typescriptfile, the ability to feed information from thetypescript back to the system, and the ability to havea handle on the values returned as well. This is anattribute of the interactive interface: its value comesfrom the observation that the operations oneperforms often are similar to, or use the results of,the operations one has recently performed.An undoing mechanism should cover bothsystem-implemented actions such as edits, and a wayfor users to supply a procedure that will undo theeffects of another specified procedure. This can bea very inexpensive alternative to checkpointing as away to give the user the ability to experiment withalternatives without imposing the burden ofmanually saving and restoring the relevant state.(T12)Editor integrated with language systemEditing is just one function of a language system,carried out using a particular sublanguage. (In fact,we believe it may be the appropriate model for themajor sublanguage presented to the user at theterminal.) As such, it should be integrated with therest of the language system in thatthe user doing editing can call on arbitraryprograms to compute commands or data neededfor the editing process, including the ability topass selections from the thing being edited to thecomputation as arguments;any program can call on the editor as a package.The latter seems very useful and relatively easy toachieve. We agree the former is also valuable, butthere is disagreement over whether it is merelyvaluable or extremely important.(T13)More optimizing compiler if user willing to bindmore tightlywith full compatibilityA recurring source of difficulty in programmingis the generality/efficiency tradeoff: when it is timeto tune a system for better performance, it istraditionally necessary to make major logic changesas well. An alternative is to keep the logicalstructure of the program the same, but have acompiler that can do the necessary rearrangementsas part of the compilation process: the programmerinstructs it as to what kinds of flexibility ormodularity should be sacrificed, and the criticalchoices to be made in the representation of dataЪНЙОfЯpqТFП.НJ╠pНEОaЄНgrТXН VО^╛pТиТйНEО\ЎТҐП-ТЎНEОZпТ┐П/Т└НEОXБТдТеНEОVТТ╧ Т╨П#НEОUТТНEОSТхП(ТиНEОQ+Т<Т=НEОO=ТєП1НEОMOТН `ОJGТLП%ТMН `ОHYТН `ОEQТ⌡П$Т°Н `ОCcТяП)ТрН `ОAuТН `О>mТЕТФН `О<ТvТw Н `О:▒Т╪ТҐП!Н `О8ёТOП'Н `О6╣Н@О3ґТЇТ╦П"Н@О1©ТНEО.НgrТXП$НgО,┐ Н VО){pТвТьНEО'█ТbТcНEО%÷Т╞П0Т╟НEО#╠ТмП,ТнНEО!цТ╣ТІП"НEОуТЇ rpТ╦НEОГТ╚П%Т╛НEОЫТП*ТНEОТ▐П&Т░НEОТщТчНEО0ТНEОwНgrТXН VОopТ═Т║ НEО │ТEТFНEО⌠Т└П.Т┘НEО ╔Т≥П)Т Н+ДОaЄТ≤Т≥П'Н+ДО_фТZТ[П$Н+ДО]ьТ╛ТґН+ДО[ЙТП*Н-УОYЭТirpТjН+ДОXТ┴П3Н+ДОV!ТІП$ТЇ Н+ДОT3Т╒ТёН+ДОREТіТїП.Н+ДОPWТ╙П.Т╚Н+ДОNiТ╒П!Тё Н+ДОL{ТЪП!ТН+ДОHцН0rТXП&Н-УОE╩pТ├ Т┤П(Н+ДОCмТ≈Т≤П#Н+ДОAъТ═П$Т║ Н+ДО?ЯrpТТ Н+ДО>Т∙Т√Н+ДО<ТП#Н-ЪО9 ТТН-ЪО7ТёТєН-ЪО51ТгТхП*Н-ЪО3CТ┤П2Н-ЪО1UТН-ЪО.MТ▒Т▓П!Н+ъО+EТҐП+ТЎН+ъО)WТ╗Т╘Н+ъО'iТ ТН+ъО%|ТН+ДО!цН0rТXП0Н0О ?П$Н-УО7pТ╛ТґН+ДОIТ╔П.ТіН+ДО[Т!П.Н+ДОmТ╡П+ТЁН+ДОТТН+ДО▒Т Т Н+ДОєТдТеН+ДОІТіТїП+Н+ДО хТ=Т>П#Н+ДОзТТН+ДО ЛТщТч░@ ^"│^ґUREQUIREMENTS FOR AN EXPERIMENTAL PROGRAMMING ENVIRONMENT14structures. The Lisp block compiler'' is oneexample of this idea; the Mesa in-line procedure isanother. We did not discuss this area except inpassing.(T14)Aids for incremental development (stubs,outstanding task list)Top-down programming, or independent devel-opment of modules in a system, often benefits fromthe ability to replace as yet unavailable moduleswith stubs which have the same functional behaviorbut simpler (and presumably less efficient)implementation. This and other aids for keepingtrack of the status of parts of a large project havebeen used successfully in many system developmentefforts.(T15)Regression testing system(T16)Random testing aidsBoth regression testingkeeping a record ofstandard tests and results with a program module,and automatically checking them after a change tothe moduleand testing with random data haveproven to be worthwhile methods for checkingprograms too large or complex to verify or describeanalytically.(T17)(high capability) MasterscopeAny facility like Masterscope, which maintains anup-to-date data base of relations among parts of aprogram, must be integrated into the system at afundamental level. Our discussion revealed that thefundamental aspect is the need for a single funnelfor changes to the system (Mesa pretty much hasthis now, but Lisp does not). Relation to the filesystem was discussed, and it was agreed that manualuse of the file system should be outlawed. Aconsequence is that the programming environmentmust do recovery at least as well as the file systemdoes. Of course, having a reliable file system under-neath makes this much easier. A variety oftechniques are possible, which we did not explore indetail.(T18)Access to on-line documentation (Helpsys)Good on-line documentation, both for referenceand for learning, can greatly reduce the need fortime spent studying an enormous manual, canprovide instant cross-linking of related subjects in away that hardcopy cannot, and can use one's currentcontext to implicitly locate relevant materialLisp'sHelpsys facility is unique in these respects.However, creating and maintaining such documen-tation is a tremendous amount of work, even if theprocess is partly automated.(T19)Static analyzers: verifier, performance predictorWe agree that, especially for programs used bymany people in low-tolerance environments, anounce of prevention is worth a pound of cure: effortexpended on eliminating bugs or bottlenecksbeforehand can save a lot of time and troublelocating them afterward. Unfortunately, verificationtechnology is still unable to accommodate programsof significant size written in languages of realisticcomplexity, and very little has been done onderiving performance information from the programtext (in contrast to analytic models of systems at agross level, of which there are many).2.4. PackagesBeyond the virtual machine and programminglanguage, which are forced on all users, and thetools, which should be applicable to all users, thequality of a programming environment is largelydetermined by the presence of packages that providefunctional capabilities useful to many applications.We cannot stress too strongly that, from ourexperience, the only way to ensure the necessaryhigh quality for such packages is to have a verysmall group (one to four people) with the finalauthority and responsibility for deciding whichpackages are to be incorporated in the system in away that makes them readily available to all.ЪНгОfЯpqТFpqpq pq НEpНEОaЄТ/Т0НEО_фТ╗П3НEО]ьТщТчНEО[ЙНEОX2НgrТXП(НgОVўН VОSіpТяП$ТрНEОQ╦Т≈Т≤НEОOйТОП)ТПНEОMэТ║rpТ╒П"НEОKНТеТфНEОJТвТьНEОHТЇТ╦П,НEОF$Т°П%Т²НEОD7НEО@~НgrТXНEО>&pНgrН VО;pТ'П+НEО90Тг ТхП#НEО7BТ╪ТҐНEО5UТЩП"ТЧ НEО3gТ#Т$П#НEО1yТ²П3НEО/▀НEО+рНgrТXН VО(йpТ┌П$Т┐НEО&эТЎП2НEО$НТуП$ТжНEО#Т≈П+Т≤НEО!ТҐТЎrpНEО%ТнТоНEО7Т╨П*Т╩НEОIТ█ Т▌П)НEО[ТТНEОmТоП#ТпНEОТ╗Т╘НEО▒Т└П#Т┘НEОєТ9 Т:НEОІТ▀П1Т▄НEО хН+ДОaЄН0rТXП)Н-УО^╛pТўП.Н+ДО\ЎТуП$ТжН+ДОZпТ8П+Н+ДОXБТёТєН+ДОVТТ┴Т┼П"Н+ДОUТїТ╗Н+ДОSТ▄Т█Н+ДОQ+ТхП!Ти Н+ДОO=Т╒ ТёП'Н+ДОMOТН+ДОI√Н0rТXП1Н-УОF▌pТ╪ ТҐН+ДОD═Т2П*Т3Н+ДОB╡Т├Т┤Н+ДО@еТ┐Т└Н+ДО>вТТ Н+ДО<ИТ÷П5Н+ДО:ШТёТєН+ДО9 ТвТьН+ДО7Т=Т>Н+ДО51Т П%Т⌡Н+ДО3CТЁТЄП,Н+ДО1UТП&Н+ДО,іsТXН-УО)·pТМ ТНН+ДО'╟ТЕТФП!Н+ДО%бТйП$ТкН+ДО#тТЖП/Н+ДО!ФТ┤Т┬Н+ДОЬТжП4Н+ДОТDП,Н+ДОТЕТФН+ДО/ТщП!ТчН+ДОAТВТЬН+ДОSТFП/Н+ДОeТ╟П-Т╠Н+ДОwТП-Ъ юE │*гZ┼-CATALOG OF PROGRAMMING ENVIRONMENT CAPABILITIES15(P1)Text objects and images(P2)Line objects and images(P3)Scanned (bitmap) objects and images(P4)Formatted document filesThe manipulation of images is of primaryconcern to us in our experimental systems. We candivide these manipulations into two categories:Manipulation of abstract objects such asformatted documents, forms, line drawings, andcontinuous-tone images. The operations on theseobjects are defined by the semantics of theobjects, not by their representation on a medium.Manipulation of the images of these objects ondisplays or printers. These operations must takethe nature of the medium into account.In the first category we might find editing operationson document files such as insert, replace, search; ondrawings and pictures such as scale, rotate, reflect,clip, shade, connect points with a spline curve. Inthe second we find operations for mapping objectsonto media in a variety of ways, some of which mustbe reversible (e.g., when a user makes a selection inthe displayed image of a document, that selectionreally refers to the data in the document itself).We believe that enough experience has beengained in these areas that it is possible to constructpackages that will be useful in a wide range ofprograms, and that will markedly decrease the effortrequired to write programs that use them.An interesting area that we have not discussedper se is the general notion of annotation ofdocuments (or data structures): formattinginformation can be considered an annotation to thetext, comments to a program, meta-descriptions inthe KRL sense to a slot or another description.Pilot, for example, provides a notion of subsequencesof a byte stream, which can easily be used torepresent formatting information in a way thatuninterested programs can ignore.(P5)More elaborate screen managementIn addition to the basic screen managementcapabilities mentioned under (L18), there are someadditional facilities (scrollable windows, for example)that many programs will want to share. Again, webelieve there will be a payoff from the presence ofsome carefully designed packages in theenvironment.(P6)Remote file storageThe manual transfer of files between machines isa significant source of errors and wasted time. Suchtransfers are necessary either because of spaceproblems or because one machine has a capability(such as a printer or high-performance display) notpossessed by all.(P7)Small data base managerAs a goal, we believe that the well-integratedaccess to large data bases mentioned under (L3) hasa potentially enormous payoff, since many tools aswell as experimental programs will benefit from it.However, if it turns out that we can't figure out howto provide this, then we will need a well-designeddata base package for managing locally stored data.(P8)Message transmission systemMessage transmission is a useful paradigm formany kinds of inter-machine communication.(P9)Remote procedure callThe ability to call a procedure on anothermachine as though it were on one's local machine isa different, less well understood communicationparadigm.(P10)Event loggingEvent logging is a useful technique forredundancy and crash protection, for gatheringstatistics, and for reducing the cost of updating adata base in response to events affecting it.ЪНЙОfЯpqТFП.НJ╠pНEОaЄНgrТXНEО_\pНgrНEО]pНgrП#НEОZґpНgrН VОW╔pТMТNНEОUЇТ√Т≈П"НEОSиТП/Н `ОPаТ╘П(Н `ОNсТҐТЎН `ОLЕТ└Т┘Н `ОJВТТН `ОI Т└П$Т┘Н `ОFТ╧Т╨Н `ОDТ Т⌡Н `ОB%ТП&Н@О?Т─Т│П*Н@О=/Т∙П!Т√Н@О;AТюТаН@О9TТ╟Т╠П(Н@О7fТ╦ Т╧П'Н@О5xТ─П%Т│ Н@О3┼Т√П2Т≈Н@О1°ТпТяН@О/ўТПТЯН VО-юТТНEО+рТ╔П)ТіНEО)ДТНТОНEО'ВТ░Т▒П'НEО& ТП)Н VО$ТиТй НEО"-rТ5pТ6r pНEО ?Т&Т'НEОQТіТїП#НEОcТмТнНEОuТСТТНEО┤Т┴ Т┼rНEО pТ ТНEО╛Т+П)Т,НEОЎТП!Н+ДОaЄН0rТXН-УО^╛pТТН+ДО\ЎТЇТ╦Н+ДОZпТ├П!Т┤Н+ДОXБТ╘П1Н+ДОVТТїТ╗Н+ДОUТП#ТН+ДОSН+ДОO`Н0rТXН-УОLXpТ▐П-Т░Н+ДОJjТ▀Т▄Н+ДОH|Т9Т:П"Н+ДОF▌ТцП%Тд Н+ДОD═ТґП/ТўН+ДОB╡ТН+ДО>ЗН0rТXН-УО;РpТГТХН+ДО:Т√П/Т≈Н+ДО8Т╧Т╨Н+ДО6(ТІТЇН+ДО4:Т┘П-Т├Н+ДО2LТюТаП"Н+ДО0_ТїП3Н+ДО,іН0rТXН-УО)·pТАТБН+ДО'╟ТП*Н+ДО#ЬН0rТXН-УО ОpТ,Т- Н+ДОТ▐П(Т░ Н+ДОТ%П/Н+ДО&Н+ДОmН0rТXН-УОepТ Т⌡Н+ДОwТAТBН+ДО┴ТтП3Н+ДО⌡ТП-Р@T"│YЇREQUIREMENTS FOR AN EXPERIMENTAL PROGRAMMING ENVIRONMENT16(P11)Background processingIn an interactive system with enough realmemory, both external communication (sending andreceiving mail, printing) and computation (recom-pilation, Masterscope data base maintenance) canmake effective use of time when the user is thinking.(P12)Generalized cacheMany applications can benefit from a cachemechanism that provides local copies of moreremote data, e.g., copies in memory of data from thedisk, or copies on a local machine of files storedremotely. A package could keep track of whichitems had been used least recently, schedulerewriting of changed items, and deal with locks andtimeouts.(P13)Document editingUnderlying document editing and manipulationfacilities have been re-implemented time after time,because insufficient thought was given to organizingthem as a general-purpose package. There is nogood technical reason for this.(P14)Forms(P15)Menus and other standard user interfacesPackages that provide standard user interfacetools such as forms, menus, selection, etc. aredesirable both in the interests of uniformity andsimply to save work.(P16)History listsPrograms should be able to take advantage of thesame mechanisms used by the system to provide thehistory and undoing capabilities discussed in (T11).(P17)User access to full bandwidth of diskData base manipulations and code overlayingrequire brief bursts of high-bandwidth disk activity.The system should not prevent the programmerfrom using the disk's full bandwidth, and a packageshould make it easy.(P18)(English) dictionary serviceOffice applications involving documents canbenefit from easy access to an English dictionary(for spelling correction, hyphenation, and thesaurusapplications, for example).(P19)TeleconferencingInter-person communcation should play more ofa role in our future experiments; we need a packageto handle the mechanics of keeping several users'views of the screen, cursor, etc., consistent.(P20)AudioWe have hardware support for capturing andplaying back audio information, but hardly anysoftware support. Something like the current audiomessage system ought to be a very small project.(P21)User access to full bandwidth of networksAs in (P17), the system should not obstruct theprogrammer's access to the machine's full I/Obandwidth in experimental situations.2.5. Other(X1)Adequate reference documentationReference documentation must be complete andreasonably well organized and indexed. The Inter-lisp manual is a shining example of how well anentire environment can be documented. It alsodemonstrates that keeping this documentation up todate is a lot of work.ЪНгОfЯpqТFpqpq pq НEpНEОaЄНgrТXН VО^╛pТXТYП$НEО\ЎТ°Т²НEОZпТЦП1НEОXБТЫП0НEОVТТ─Т│НEОS<НgrТXН VОP4pТТНEОNFТ?П$Т@НEОLXТ└П#Т┘НEОJjТяП%ТрНEОH|ТЦП%ТДНEОF▌ТiТjНEОD═Т П)Т⌡ НEОB╡НEО>ЗНgrТXН VО;РpТяТрНEО:Т╘П4НEО8Т П&Т⌡ НEО6(ТшП/НEО4:ТНEО0┌НgrНEО.*pНgrТXП(Н VО+"pТП-НEО)4Т.П+Т/НEО'FТОП-ТПНEО%XТНEО!═НgrТXН VО≤pТ│Т┌НEО╙Т▐П%Т░НEО╪Т╡П*ТЁ НEОНgrТXП%Н VОШpТП+НEО ТїП&Т╗НEО ТП,НEО2Т≈Т≤НEОDТН+ДОaЄН0rТXН-УО^╛pТZТ[Н+ДО\ЎТАП1Н+ДОZпТЇП4Н+ДОXБТН+ДОU*Н0rН-УОR"pТїП%Т╗Н+ДОP4Т▀Т▄Н+ДОNFТтТуН+ДОLXТП.Н+ДОH÷Н0rН-УОE≈pТУТЖП#Н+ДОC╘ТП*ТН+ДОA╪Т═Т║П!Н+ДО?нТуТжН+ДО<Н0rТXП)Н-УО9 pТ╠Т╡Н+ДО7Т4П$Т5Н+ДО51ТП%Н+ДО0┌sТX Н+ДО,иpН0rН-УО)аpТ╚Т╛Н+ДО'сТґП'Тў Н+ДО%ЕТяП'ТрН+ДО#ЬТШТЭН+ДО" Т÷Т═П!Н+ДО ТЪ dEЩ*г\нCATALOG OF PROGRAMMING ENVIRONMENT CAPABILITIES17(X2)Efficient'' interface for expertsFor experts, the desire for common operations torequire a minimum of human effort often rightlytakes precedence over the desire for the greatestpossible uniformity or simplicity in the humaninterface. However, such interfaces are too oftenconstructed without paying any attention to the fewprinciples of interface design that we do know. Webelieve it is important to consider consciously thedesign of certain key command interfaces (editing,debugging, screen management).(X3)Uniformity in command interfaceIn the process of using interactive programs, suchas the tools listed in the previous major section, theuser will inevitably accumulate perceptions, opin-ions, and models of the programs, and conjectures asto their workings. The net effect of these percep-tions is referred to as the user illusion. The intent isto allow the user to see the programs only inrelation to his own needs and purposes, and nothave to concern himself with the internal workingsof the programs. What is important about astandard user interface package is that the user beable to confidently predict the general manner ofinteraction with a program that uses the package,even though he hasn't experienced it yet; and that,by and large, the user will be right. This has beencalled the Law of Least Astonishment.The concept of a consistent user interface alsosimplifies the design and coding of any program thatinteracts with the user. By adopting the conventionsand making use of the facilities, it is a relativelysimple matter to create useful interactive programs,because the programmer can concern himself withthe algorithm rather than with creating his own userinterface.We believe that, in addition to consistency,another important goal to pursue in the design ofthe user interface might be called the Principle ofNon-Preemption. Individual interactive programsshould operate in a non-intrusive manner withrespect to the user's activities. The system does notusurp the attention and prerogatives of the user. Aprogram responds to the user's stimuli, but thenquietly retains its context and logical state until theuser elects to interact with the program again, not(for example) monopolizing the resources of thecomputer.(X4)Self-teaching'' interface for beginners(X5)Good introductory documentationSince we are concerned with a programmingenvironment primarily for CSL, and secondarily forthe rest of the local research community, we feelthat concern for novices should have low priority,since the rate at which new people join thecommunity is low and most of them are alreadysophisticated.НЙОfЯpqТFП.НJ╠pНEОaЄНgrТXП#Н VО^╛pТ▄П0НEО\ЎТвТьНEОZпТОП(ТПНEОXБТ)П$Т* НEОVТТыП,ТзНEОUТ═Т║НEОSТ∙П&Т√НEОQ+ТяП#ТрНEОO=ТхП(Ти НEОMOТНEОI√НgrТXН VОF▌pТ┌Т┐П!НEОD═Т П)Т⌡НEОB╡ТТТУНEО@еТ│Т┌НEО>вТЇТ╦НEО<ИТ┬Т┴ rpНEО:ШТТП%НEО9 ТЮТАНEО7ТЁТЄНEО51Т&Т'НEО3CТ╩П+Т╪НEО1UТжП1НEО/hТвТьНEО-zТ╙ Т╚П%НEО+▄Т═П&Т║ НEО)·ТП%Н VО'╟ТоТпНEО%бТ┌ Т┐П&НEО#тТ┬Т┴НEО!ФТвП$ТьНEОЬТ╡П*ТЁ НEОТйП/НEОТ░Т▒НEО/ Н VОAТ+П,НEОSТдТеНEОeТбП0ТцНEОwТЪТНEО┴Т+П(Т,НEО⌡Т≈ Т≤П,НEОўТ П+Т⌡НEО юТОП+ТПНEОрТіТїН+ДОaЄТ©ТюН+ДО_фТП/Н+ДО]ьН+ДОZ Н0rТXП)Н+ДОWхpН0rН-УОTюpТТН+ДОRрТёТєН+ДОPДТуТжН+ДОNЖТкП2Н+ДОMТ@ТAН+ДОKТАТБН+ДОI- rE▀"│_─²193. Priority ranking and interrelation of capabilitiesWe arrived at a priority ranking for capabilitiesby giving each member of the working group 100votes to be divided among the capabilities on thelist. The vote total below is simply the sum of thevotes of the 5 members who actually voted,identified by their initials: Deutsch, Horning,Lampson, Morris, and Satterthwaite. (As a check,we also ranked the capabilities according to themedian rather than the total, and the results wereessentially the same.) We found that a naturaldivision into 5 priority groups emerged from theranking. The reader should be aware that we wereranking capabilities on their utility if present insome reasonable form, not on the value of doingresearch into how to improve what we now knowabout providing them.We were able to reach a consensus about howfundamental each capability was, in the sense ofhow difficult it would be to add that capability if itwere not allowed for in the initial system design. Indoing this we drew heavily on the experience gainedfrom the three existing language systems. Thisconsensus is expressed below according to thefollowing code:FFundamental, much harder if not allowed fororiginallyIIntermediate, somewhat harder if not allowed forAAdd-on, difficulty does not depend significantlyon pre-planning (although it may be intrinsicallyhard anyway)<==24 bits)ЪНBqОG9pНОA╣qТiП5НО>ґpТЁТЄНО<©ТбП*ТцНО:рТйТкНО8ДТ║П)Т╒ НО6ЖТSТTНО5ТvП/НО3ТаТбНО1,ТЧТЪП)НО/>ТдТеП%НО-PТЗТШНО+bТДП,ТЕНО)uТ║Т╒НО'┤ТЧТЪНО%≥ТрТсНО#╚ТфП$ТгНО!ҐТНОоТцТдНОАТЛП0НОСТ П0Т⌡НОТ┬Т┴П"НОТ┼П3НО*ТТ НО<Т;Т<НОNТНОFН ТКП+Н О X НО PН Т▀Т▄НОHН Т╧П"Т╨ Н ОZТ Т⌡Н ОlТНwОd1Н%╣О>ґТQТRrpН#єО<©Т@ТAП#Н#єО:рТ╧ rpТ╨П%Н#єО8ДТ╚ rpТ╛Н#єО6ЖТП%Н%╣О5Т╟П'Т╠ Н#єО3Т5Т6Н#єО1,ТсТтН#єО/>Т┼Т▀П"Н#єО-PТмП0ТнН#єО+bТП)ТН#єО)uТП-Н%©О&l Н%©О$[Н%©О"JН%©О 9Н%©О(ТІТЇН'ъО:Н#єО┼sТXН%╣О┌pТ≈П!Т≤Н#єО■ТЎ Т©П'Н#єОїТ╔П%ТіН#єО╧Т╟П'Т╠ Н#єОкТэТщН#єО щТюП#rpН#єООТUТVН#єОТП$Ъ @╦#HS≥НОЖp$НОrqТ─ Н ИpНgНБН]НьНSНОН┴Н╘Н ИrНgНБН]НьНSpНнТЁП7НО бН┴Н╘Н ИrНgНБН]НьНSpНнТНОjН┴Н╘Н ИrНgНБН]НьНSpНнП&НО Н┴Н╘Н ИrНgНБН]НьНSpНнП8НО╩Н┴Н╘Н ИrНgНБН]НьНSpНнП+spНОcН┴Н╘Н ИrНgНБН]НьНSpНIНЖО╪q pП#НОdН┴Н╘Н ИrНgНБН]НьНSpНнsp БЇ&=QнREQUIREMENTS FOR AN EXPERIMENTAL PROGRAMMING ENVIRONMENT20<== Н┴Н╘Н ИrНgНБН]НьНSpНнНЖОQQу║PRIORITY RANKING AND INTERRELATION OF CAPABILITIES21<==48 bits)(L22)A100User access to the machine's capabilityfor multi-precision arithmetic(L23)I202Good facilities for processes, monitors,interruptsenabled by (L6) Some support for interruptsenabled by (A15) Abstraction mechanisms(L24)F120Simple, unambiguous syntax(including infix notation)(L25)F302Control over importation of namesenabled by (A15) Abstraction mechanisms(L26)F331User packages as first-class citizens''(L28)F333Full-scale inter-languagecommunicationenabled by (L17) Inter-languagecommunication(L29)A222User microprogramming<==<Q:▀ЭREQUIREMENTS FOR AN EXPERIMENTAL PROGRAMMING ENVIRONMENT22(L30)?333Clean data and control trappingmechanismsenabled by (L6) Some support for interruptsenabled by (L23) Good facilities for processes,monitors, interruptsenabled by (L31) Good'' exceptional conditionhandling(L31)?333Good'' exceptional conditionhandlingenabled by (L7) Adequate exceptionalcondition handlingenabled by (L13) Encapsulation/protectionmechanismsenabled by (L14) Abstraction mechanismsenabled by (L15) Non-hierarchical controlstructuresTOOLS(T14)A222Aids for incremental development(stubs, outstanding task list)enabled by (L9) Program-manipulablerepresentation of programs(T15)A222Regression testing systemenabled by (L9) Program-manipulablerepresentation of programs(T16)A333Random testing aids(T17)F022(High capability) Masterscope(T19)A333Static analyzers: verifier, performancepredictorenabled by (L9) Program-manipulablerepresentation of programsPACKAGES(P5)A022More elaborate screen management(P7)A221Small data base manager(P11)F323Background processing(P16)A011History lists(P17)I111User access to full bandwidth of disk(P18)A222(English) dictionary service(P19)A222Teleconferencing(P20)A222Audio(P21)A111User access to full bandwidth ofnetworksOTHER(X4)F222Self-teaching'' interface for beginners(X5)I222Good'' introductory documentation3.2 Discussion of difficulty estimatesIn this section we discuss the difficulty estimatesfor the highest-priority features. Nearly all thesefeatures fall into one of three difficulty patterns:Considerably easier in Mesa than in either Lispor Smalltalk (e.g., L11, L13, T5).Considerably easier in either Lisp or Smalltalkthan in Mesa (e.g., L5, T1, L12).Comparable in difficulty in all three systems(e.g., L4, L3, T8).This is not terribly surprising, given the underlyingphilosophical similarities between Lisp andSmalltalk.Priority A(L5)030Object managementgarbage collection,reference countingReference counting, which relies almost entirelyon local information, and garbage collection, whichneeds a global map of all potentially traceable data,present quite different problems for Mesa. Forreference counting, it might be adequate to add anattribute to the Mesa type system so that referencecounting or transaction queuing can occur when theprogram stores into a pointer that might point to anautomatically managed object, and arrange for auser-supplied finalization procedure to be calledwhen a count becomes zero. A further refinementmight be automatic generation of the procedure bythe compiler based on declarations. All this wouldbe difficulty level 2.Garbage collection in Mesa is more difficult, fortwo reasons:The type information needed to locate allpointers is not present in the actual data, butmust be derived from the symbol table producedby the compiler.ЪН┤О^┐ptТFptpt pt НpНОYFН'Н8НЗТXНЗОWб Н'ОVr pН'ОTsr pП$Н ═ОRОН'ОQHr pП$Н ═ОOдНОM&Н'Н8НЗНЗОK║Н'ОIЗr pН ═ОHvН'ОFоr pН ═ОEK Н'ОCёr pН'ОAЭr pН ═О@x НО=MtНО:ўpН'Н8НЗНЗО9*Н'О7┐r pН ═О5ЪНО3aН'Н8НЗН'О1╧r pН ═О05НО-≈Н'Н8НЗНО*ЫН'Н8НЗНО(ZН'Н8НЗП'НЗО&жН'О%/r pН ═О#╚НО ─tНОАpН'Н8НЗНОCН'Н8НЗНО╔Н'Н8НЗНОН'Н8НЗНОhН'Н8НЗП%НОйН'Н8НЗНО,Н'Н8НЗНО█Н'Н8НЗНООН'Н8НЗНЗОkН#÷ОYFtН#єОV╗pН'фН)вН,≥П)Н#єОT Н'фН)вН,≥П#Н#єОOZsП&Н%╣ОLRpТ⌡Т°П$Н#єОJdТшТэП-Н#єОHvТГТХН%©ОEnТўТ╞Н%©ОC─ТП"Н%©О@xТяП"ТрН%©О>┼ТП!Н%©О;┌ТТН%©О9■ТН#÷О6▄ТґТўП.Н#÷О4·ТП+Н#÷О2╟ Н#єО.krТX Н#єО*╡pН'фН+ХrП%Н+ХО).Н%╣О&&pТ╧П0Н#єО$8Т╡rpП%ТЁН#єО"JТ÷rpТ═П'Н#єО \ТЗП*ТШН#єОnТ╛П/ТґН#єО─ТўТ╞П'Н#єО⌠Т≤Т≥Н#єО╔Т▒Т▓Н#єОЇТЪП-ТН#єОиТП*ТН#єОшТ╞П0Н#єОМТґП.ТўН#єОЪТ╗П-Т╘Н#єО ТН%╣О#Т²П"Т·Н#єО 6ТН%©О-ТOТPП!Н%©О@ТыТзН%©ОRТ▄П%Т█Н%©ОdТ Ж@n*г_²)PRIORITY RANKING AND INTERRELATION OF CAPABILITIES23The presence of LOOPHOLEs, pointer arithmetic,overlaid variants, and relative pointers makes itimpossible for a garbage collector to find or traceall pointers to structure to be saved.The former problem is only one of efficiency: oneway around it might be to arrange for the compilerto generate a tracing procedure for each structurethat might participate in garbage collection. Thelatter, however, is a fundamental difficulty. Webelieve that the proper approach to overcoming it isto discover a subset of the Mesa language that doesnot use any of the LOOPHOLE-like featuresmentioned above, and find a way to draw aprotection boundary around a program written inthis subset so that it can have automatically manageddata. This is a hard problem.(L11)203Statically checked type systemThe basic problem with static type checking inboth Lisp and Smalltalk is that very little is knownat compile time about the referents of names.Lisp currently has a facility called DeclTran,which uses embedded declarations (both of typesand of arbitrary predicates) to check the types ofoperands at runtime and to generate more efficientcode within an individual function. This facilityapplies to both interpreted and compiled code, butis somewhat machine-dependent and does not existfor the Alto/Dorado Lisp system. Also, it has noability to deal with static checking of interfacesbetween user-defined functions (as opposed to theinterface from user-defined functions to built-inoperations like arithmetic). If mechanisms, such asthose of (L13) and (L14), were added to Lisp tocontrol exporting and linkage of names, it is likelythat DeclTran could be extended to inter-functiontype checking. We are inclined to think that this isnot a good approach in the long run and that thetype system should be more tightly integrated withthe underlying language system, but it seems like aworkable way to obtain the desired result.Smalltalk has no facilities at all for staticdeclaration of types. Furthermore, because everyoperation is decoded at execution time by the objectthat is its first operand (even elementary operationssuch as +''), there is in principle no way ofknowing what code will actually get executed inadvance of execution time without some combi-nation of type declarations and searching the entiresystem to discover what classes implement whatoperations. The situation is complicated bySmalltalk's subclass structure, which makes it verydesirable that, for example, a method requiring anargument of type Number should accept values oftype Integer (a subclass of Number). Smalltalk hasa fairly simple compiler and name structure, but alot of new machinery would have to be built, someof which would require careful thought about whattype'' means in the Smalltalk environment.(L4)000Memory managementobject/pageswappingLisp and Mesa already use a straightforwardpaging scheme, and Smalltalk an object-swappingscheme.(L14)302Abstraction mechanisms; explicit notionof interface''As discussed under (L13) below, Lisp currentlyhas only a very weak mechanism for explicitlydealing with interfaces between a package and itsclients. In addition, Lisp has no mechanism fortaking a group of functions and controlling how itsimported names are to be linked: such a facility isnecessary if interfaces are to be separated from theirimplementations.Smalltalk is somewhat better off since itsinvocation mechanism does hide the implementationfrom the caller. A type system for Smalltalk, asdiscussed under (L11) above, would also go fartowards providing an explicit notion of interface,since the current Smalltalk notion of abstract class''can be viewed as either a type or an interfacedescription.(T1)020Fast turnaround for minor programchanges (less than 5 seconds)Lisp has an interpreter, and a fully integratededitor. (We have discussed replacing the interpreterwith a high-speed, low-code-quality compiler, whichalready exists for the Alto.) Smalltalk has acompiler which we believe will run fast enough onН╩О^┐ptТFП1НBqpН ОYFТ╠tpН ОWXТ©П1Н ОUjТ┌ Т┐П%Н ОS|ТП&НОPtТ╣П1НОN├Т·Т÷НОL≤ТрП2НОJ╚ТчТъНОHҐТСП.ТТНОFоТ■П4НОDАТ Т⌡П&НОBСТ▐ Т░tp НОAТ6П"Т7НО?ТъП/НО=)Т─ Т│П'НО;;ТНО7┐Н'НIrТXНО4{pТцП.НО2█Т╔П+ТіНО0÷ТП-НО.╠ТП.НО,цТИП)ТЙНО*уТрТсНО(ГТўТ╞НО&ЗТИП2НО%Т╠ Т╡П(НО#ТЁП0НО!0Т╪П!ТҐНОBТТП#НОTТкТлНОfТ%П1НОxТ╚Т╛НО┼ТжП,ТвНО²ТЄП'Т╣НО╞ТоТпНОаТ≤П2Т≥НОсТЇТ╦П+НО ЕТЁТЄНОВТ╗П3НО ТП*НОТHТIНО-ТЮП+ТАНО@Т▄П!Т█НОRТ╔ТіНОdТ ТН#єОYFТРП#ТСН#єОWXТТН#єОUjТ╗Т╘Н#єОS|ТП.Н#єОQ▌ТtТuН#єОO║ТоП%Тп Н#єОMЁТ╪ТҐП#Н#єОKеТ©ТюН#єОIвТ═Т║П$Н#єОGИТЇП0Т╦Н#єОEШТ═П"Т║Н#єОD Т╙П1Н#єОBТП,Н#єО>gН'фН+ХrТXН+ХО<ЦН%╣О9шpТ П+Н#єО7МТРТСН#єО5ЪН#єО2FН'фН+ХrТXП'Н+ХО0бН%╣О-╨pТюТаН#єО+лТП-Н#єО)чТтП!ТуН#єО'ЯТЦП"ТД Н#єО&Т╗П3Н#єО$Т╟П'Т╠Н#єО"'Т▐П+Т░ Н#єО 9Н%╣ОKТcТdН#єО]Т⌠Т■Н#єОoТвТьН#єО│ТТН#єО■ТНТОН#єОіТ▐П%Т░Н#єО╦ТТП(Н#єОйН#єО Н'фН+ХrТXП!Н+ХО█Н%╣О┘pТэП$Тщ Н#єО≈Т▓Т⌠П$Н#єО╘Т║П3Н#єО╪Т1Т2Н#єОнТґТўч@n"__²eREQUIREMENTS FOR AN EXPERIMENTAL PROGRAMMING ENVIRONMENT24the Dorado, and an integrated editor.Mesa offers several medium-size obstacles to fastturnaround for changes:Since the present editor is not integrated or evenproperly packaged, considerable machine andhuman overhead is involved in getting in and outof it. We recommend replacing it by a packagededitor available in the programming environ-ment.The compiler is not designed to compileanything smaller than an entire module. Werecommend some work to modularize thecompiler (it is already broken up quite well) andto make sure enough information is available forit to be able to compile single procedures.The current Mesa system does not provide forsafe, incremental replacement of modules orprocedures by new versions without losingexecution state. This feature must be provided.(L16)?0?Adequate runtime efficiencyThe Lisp instruction set is actually quite similarto that of Mesa: for example, it can use the Doradoinstruction fetch unit. Sources of additionaloverhead include the fact that all data aredoublewords, and considerable runtime type-checking is required. We believe that even thepresent Lisp system will perform adequately on theDorado. Further significant gains in efficiencywould be possible with some redesign that woulduse the Dorado processor stack, and with theextensions required for (L11), static type checking.The Smalltalk instruction set, in principle, is alsosimilar to that of Lisp and Mesa. In addition todoubleword data and runtime type-checking,Smalltalk also suffers somewhat from substantiallyless ability to compile things like arithmetic andstructure access in-line, and the requirement fordoing some kind of hash lookup on each invocation.We believe that Smalltalk could also be brought upto acceptable efficiency through a high-performancedesign.(L1)002Large virtual address space (>24 bits)Lisp and Mesa already provide 24-bit addressspaces. The difficulty code for Smalltalk reflectsDan Ingalls' estimate that the current system couldbe modified (without changing its basic structure) in3 to 6 months.Priority B(L13)302Encapsulation/protectionmechanismsexport controlLisp already has one mechanism for controllingthe export of names from a group of functions: theblock compiler. However, this mechanism has manydisadvantages:Using it requires giving up a good deal ofdebugging capability, since non-exportedfunction and variable names are completely lost.It is not compatible with either the interpreter orthe normal compiler.Its application is limited to a single level, e.g., apackage cannot use this mechanism to havesubfunctions local to an individual interiorfunction or group of functions.We believe that adding export control to Lisp wouldrequire introducing notions of nested or otherwisecontrolled lexical name scopes similar to those ofMesa; we would expect this to have ramificationsthroughout the system, and some impact on userprograms that take advantage of the fact that there isa single space of names that encompasses both all ofthe system, their own programs, and their own data.(We note that in the past, the lack of export controlhas often been seen as an advantage, since it made iteasy for a somewhat knowledgeable user to extendor modify the system as desired, but we believe thisis outweighed by the problems it causes.)Smalltalk has two different export controlmechanisms. For variables, there is a dual lexicalhierarchy based on lifetime (method variables,instance variables, and static class variables) and onspecialization (subclassing). For operations, eachclass defines the names of operations it will accept.ЪН┌О]"ptТFptpt pt НpНОWЕТП%НОUВТ√Т≈НОT ТНОQТ█Т▌П)НОOТ$П+НОM%Т─П,Т│НОK7Т┬П/НОIJТП,НОG\НОDTТoП'НОBfТГТХНО@xТxТyНО>┼Т░Т▒НО<°Т▓Т⌠НО:ўТП+НО7іТиТйНО5╦Т'П(Т(НО3йТ`ТaНО1эТ╚Т╛НО.$Н"НDrТXНО+pТўТ╞НО).Т▓Т⌠НО'@ТiТjНО%RТ{П+НО#dТ╦Т╧ НО!vТРП!ТС НО┬ТіТїП&НО Т"П0НОґТтТуНО©Т2Т3НОяТдТеНОЦТ▓П,Т⌠НОУТиТйНОТфТгНОТзП$Тш НО+ТРП#ТСНО=ТП!Т НО PТ▀П!Т▄НОbТ²П2НОtТ╔ТіНО├Н#÷ОWЕН'аН+ЦrТXurН%╟ОTщpТЙТКП$Н#÷ОRОТАП*ТБН#÷ОQТ╠Т╡Н#÷ОOТ░ Т▒П*Н#÷ОM%Т Н#÷ОHЮrТX Н#÷ОE'pН'аН+ЦrН+ЦОCёН%╟О@⌡pТЇТ╦Н#÷О>ґТ² Т·П(Н#÷О<©Т┤Т┬Н#÷О:я Н%╨О7иТТП"Н%╨О5шТKТLН%╨О3МТ║Т╒П$Н%╨О0ЕТ▀П0Т▄Н%╨О.ВТН%╨О+ОТ═Т║Н%╨О*ТП!ТН%╨О(Т\П,Н%╨О&&ТН# О#Т┴П3Н# О!0ТнТоН# ОBТыТзН# ОTТсТтН# ОfТАТБН# ОxТ│П3Т┌Н# О┼Т┴Т┼П#Н# О°Т▓Т⌠П"Н# ОўТ▒Т▓П-Н# ОаТ┌Т┐Н# ОсТЇП&Т╦ Н# О ЕТ■Т∙Н# ОВТП)Н%╟О ТxТyН#÷ОТюТаП'Н#÷О-ТUТVН#÷О?ТіТїП#Н#÷ОQТП3Н#÷ОdТ╘Т╙Ъ>E о*г^CТжТвП!Н#÷О░Т Н+щО<ИН-УО;┬Т▌Т▐П#Н-УО:'Т▀П(t Т▄Н-УО8фТ┼Т▀П#sН-УО7fН+щО5ЎТН-УО4^Т╚Т╛Н-УО2ЩТТ tН-УО1°Т╧П$Т╨s Н-УО0;Н+щО.■ТН-УО-3Т╚П/Т╛ Н-УО+рТ!П&Т"Н-УО*rТ Н+щО(й Н-УО'iТТН-УО& ТдtТеsН-УО$╗ТН+щО# tsН-УО!═ТўТ╞П$Н-УО ?Т&П&Т' Н-УОчТП&Н+щО7Н-УОжТ╩Т╪П-Н-УОuТ:П!Т;tН-УОТўsТ╞Н-УОЄТН+щОН-УО╛Т╛ТґtН-УОKТ┬Т┴sН-УОЙ(Eг"VDqREQUIREMENTS FOR AN EXPERIMENTAL PROGRAMMING ENVIRONMENT28[Popek, et al., 1977]G. J. Popek, J. J. Horning, B. W. Lampson, J. G. Mitchell,and R. L. London, Notes on the Design of Euclid,''Sigplan Notices, vol. 12 no. 3, March 1977.[Redell, et al., 1979]D. Redell, Y. Dalal, T. Horsley, H. Lauer, W. Lynch, P.McJones, H. Murray, and S. Purcell, Pilot: an OperatingSystem for a Personal Computer,'' Proceedings of theSeventh Symposium on Operating System Principles,December 1979.[Shaw, et al., 1977]Mary Shaw, William A. Wulf, and Ralph L. London,Abstraction and Verification in Alphard: Defining andSpecifying Iteration and Generators,'' Communications of theACM, vol. 20 no. 8, August 1977.[Stoneman, 1980]Stoneman: Requirements for Ada Programming SupportEnvironments'' (John N. Buxton, ed.), U. S. Department ofDefense, February 1980.[Teitelman, 1977]Warren Teitelman, A Display-oriented Programmer'sAssistant,'' Proceedings of the 5th International JointConference on Artificial Intelligence, pp. 905-915, August1977.[Teitelman, 1978]Warren Teitelman, et al., Interlisp Reference Manual,''Bolt, Beranek & Newman and Xerox Palo Alto ResearchCenter, 1978.[Thacker, et al., 1979]C. P. Thacker, E. M. McCreight, B. W. Lampson, R. F.Sproull, and D. R. Boggs, Alto: a Personal Computer,''Computer Structures: Readings and Examples (Siewiorek,Bell, and Newell, eds.), 1979.ЪНгОfЯpsТFpsps ps НEpН>ОaвsТtsН VО`vТ┴П-Т┼Н VО_ТЕП'ТФН VО]╣tТsН>О\tsН VОZґТ╞ Т╟П-Н VОYLТ╛П#ТґН VОWКТ ТtН VОV┼ТjТksН VОU*Т Н>ОS┌tsН VОR"ТН ТОП&Н VОPаТЛТМП&Н VОO`Т└П't Т┘Н VОMЪsТН>ОLXН VОJВТсТтН VОI√Т░Т▒Н VОH6ТН>ОF▌Н VОE-ТcТdН VОCмТ7t Т8Н VОBlТуТжsН VОAН>О?dТН VО>ТХtТИsП!Н VО<╒Т╦П3Н VО;AТН>О9 tsН VО89ТІТЇН VО6ыТаТбН VО5xtТЙП*sН VО4ТЪh>3Т*г4РЪ HELVETICAЪ HELVETICA Ъ HELVETICAЪMATH Ъ HELVETICAЪ HELVETICA Ъ HELVETICA ЪLOGOЪ TIMESROMAN Ъ TIMESROMAN Ъ TIMESROMANЪ TIMESROMAN Ъ TIMESROMAN Ъ TIMESROMANЪ TIMESROMAN Ъ TIMESROMANЪ TIMESROMAN Ъ TIMESROMANЪ TIMESROMAN Ъ TIMESROMAN ЪMATH Ъ TIMESROMANЪ TIMESROMAN Ъ TIMESROMANЪ TIMESROMAN Ъ TIMESROMAN Ъ TIMESROMAN Ъ TIMESROMANЪ TIMESROMAN Ъ TIMESROMAN Ъ TIMESROMANЪMATH Ъ TIMESROMAN Ъ TIMESROMAN Ъ TIMESROMANЪMATH Ъ TIMESROMAN Ъ TIMESROMANЪ TIMESROMAN Ъ TIMESROMANЪ TIMESROMANm> кЩ #│)ґ4╨?╒J┴V·a╡l эv╣│╚▄ с√ А═2╗c╟ з╧©┌ф во⌡з╩ЕїП▐Ш▐ (+ea.e╪ ЁЩ-ekdh-eserЙ~dчeКe╪ dvТ╙ dvЙ~d©d╟e)dщыSud┌Яd█d┌Й~dЮd╪f]dЧ┌─d©d╚d≥С▌Й~d╪╪гdЮd╪d╪dЧdк0dС'?e ТiТ▄Й~faf\Ґ≤жҐєжТ▄Ґ╗d╪dУжdУСжЙ~dЮ╪гҐ≤жdЁNЙ~f\Т▄хҐ╗СжdиdЮj/ ЪЪ≥!IAЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪЪepeReport.pressTaft.PA30-May-82 14:38:09 PDT: