{"title":"The scheme of things: standardization at Snowbird","authors":"William D. Clinger","doi":"10.1145/1317250.1317254","DOIUrl":"https://doi.org/10.1145/1317250.1317254","url":null,"abstract":"About fifty Schemers came a day early for the 1988 ACM Conference on Lisp and Functional Programming, which was held in late July at Snowbird, Utah. They devoted the Sunday before the conference to revising once again the Revised Report on the Algorithmic Language Scheme [1], or R3RS for short. Three days later, after the conference, the IEEE/MSC/P1178 Working Group on Scheme met for the first time. A two-day meeting of ISO/IEC JTC1/SC22 WG-16 that followed made it a good week for alphabet soup.","PeriodicalId":262740,"journal":{"name":"ACM SIGPLAN Lisp Pointers","volume":"87 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1988-10-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"122746467","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"The symbolic programming environment (SPE#8482;): a common Lisp development environment for Sun workstations","authors":"Aaron Endelman, Steve Gadol","doi":"10.1145/1317250.1317251","DOIUrl":"https://doi.org/10.1145/1317250.1317251","url":null,"abstract":"The constructs provided in the Common Lisp Language provide a very powerful and flexible representation mechanism. The language alone, however, does not create an efficient work environment. Without tools that explicitly attack the problems of program organization, editing, and debugging, it remains a difficult task to exploit these advantages fully. What is needed is a collection of tools which, with knowledge about the relationship of the components in Lisp and a model of how Lisp programs are developed, encapsulates the tasks that constitute the Lisp programming process. Building such a programming environment in Lisp is a more tractable problem than in most conventional languages (such as C, FORTRAN, and Pascal) because the flexibility of Lisp allows programs to be operated on as data by other Lisp programs. This gives rise to the potential for a much tighter integration of tools than has typically been available.","PeriodicalId":262740,"journal":{"name":"ACM SIGPLAN Lisp Pointers","volume":"17 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1988-10-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"123941313","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Common EVAL","authors":"H. Lieberman, C. Fry","doi":"10.1145/1317232.1317234","DOIUrl":"https://doi.org/10.1145/1317232.1317234","url":null,"abstract":"We propose that the Common Lisp standard be extended by adding to the language specification a short program, itself written in Common Lisp, to implement the EVAL function. We call this Common EVAL. The interpreters for every correct implementation of Common Lisp would be required to match the semantics of Common EVAL on valid Common Lisp expressions. It should treat other expressions as errors or as implementation dependent extensions.\u0000 There are three cogent reasons for including a Common EVAL in the standard: First, since EVAL definitively specifies the behavior of Lisp programs, Common EVAL would insure uniformity of program semantics across implementations. Second, it would aid validation efforts, since the behavior of a particular implementation could always be compared to the behavior of Common EVAL. Third, it would facilitate the creation of debuggers and other program-manipulating programs that could be ported across Common Lisp implementations.","PeriodicalId":262740,"journal":{"name":"ACM SIGPLAN Lisp Pointers","volume":"9 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1988-07-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"116667898","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Readings in scheme","authors":"Ozan Yigit","doi":"10.1145/1317232.1317240","DOIUrl":"https://doi.org/10.1145/1317232.1317240","url":null,"abstract":"This is the first edition of Readings in Scheme, an irregular column featuring a comprehensive bibliography on Scheme. The core of this bibliograpy was shamelessly snarfed from [56], and has been growing ever since, thanks to further additions by Dan Friedman, Ken Dickey and Mark MacLennan.","PeriodicalId":262740,"journal":{"name":"ACM SIGPLAN Lisp Pointers","volume":"22 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1988-07-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"130619267","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Dynamic extent objects","authors":"C. Queinnec","doi":"10.1145/1317232.1317233","DOIUrl":"https://doi.org/10.1145/1317232.1317233","url":null,"abstract":"Lisp objects are heap- rather than stack-allocated because their extent is generally indefinite. Since stack-deallocation is performed without running the garbage collector, speed improvements are expected. Dedicated hardware can stack-allocate objects associated with reference counters or microcode daemons such that one can exactly know the status of the object to be deallocated and perform whatever appropriate treatment (usually a copy in the heap) according to its reachability. However such a solution is not efficient on stock hardware. This paper presents and analyses a new technique to efficiently solve this problem. It creates first class dynamic extent objects (DEO) that are stack-allocated, permits to access them only while they are in the stack and prevent to follow up dangling pointers. Every usual indefinite extent object has its counterpart as a DEO associated with the same set of operators. Finally DEO do not require dedicated hardware and may be properly compiled. The technique can be used within other programming languages. Some performance figures are discussed at the end of the paper.","PeriodicalId":262740,"journal":{"name":"ACM SIGPLAN Lisp Pointers","volume":"192 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1988-07-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"126216966","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"The scheme of things: exact and inexact numbers","authors":"William D. Clinger","doi":"10.1145/1317232.1317238","DOIUrl":"https://doi.org/10.1145/1317232.1317238","url":null,"abstract":"Numbers are one of the greatest achievements of humanity. They are the product of many thousands of years of effort by the best minds of history---and prehistory. That effort continues, for our concept of numbers is, and will remain, unfinished.","PeriodicalId":262740,"journal":{"name":"ACM SIGPLAN Lisp Pointers","volume":"127 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1988-07-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"115830426","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Recursive hidden-line elimination on an infinite surface","authors":"P. Greenspun, J. Little","doi":"10.1145/1317232.1317237","DOIUrl":"https://doi.org/10.1145/1317232.1317237","url":null,"abstract":"Algorithms that display a piece of an arbitrary, infinite surface with a vector display or pen plotter are well-known (Figure 1). Iterative algorithms can be time-consuming to implement in Fortran or PL/1. We designed, coded and debugged a substantially more perspicuous implementation in Common Lisp in about two hours on a Symbolics 3670.","PeriodicalId":262740,"journal":{"name":"ACM SIGPLAN Lisp Pointers","volume":"25 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1988-07-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"121437212","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"The scheme of things: portability","authors":"William D. Clinger","doi":"10.1145/1317224.1317228","DOIUrl":"https://doi.org/10.1145/1317224.1317228","url":null,"abstract":"A reader has asked for suggestions on how to write Common Lisp programs so that they can in the future be translated into Scheme without too much difficulty. Someone else wants to write programs in Scheme that might eventually be translated into Common Lisp. These are interesting questions, but a related question is more immediate: How do you write programs in Scheme that can easily be translated to run in other implementations of Scheme?","PeriodicalId":262740,"journal":{"name":"ACM SIGPLAN Lisp Pointers","volume":"46 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1988-04-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"122549332","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Lisp hardware architecture: the Explorer II and beyond","authors":"Patrick H. Dussud","doi":"10.1145/1317224.1317226","DOIUrl":"https://doi.org/10.1145/1317224.1317226","url":null,"abstract":"Lisp is a run-tlme typed language. Variables do not have a type; the type of a variable depends on the object it refers to. The type information has to be kept along with the object reference or within the object itself. During execution, the machine must maintain this typing information. There can be multiple references to an object but there is only one stored representation of this object. Typically, Lisp execution requires more references movement than data movement.","PeriodicalId":262740,"journal":{"name":"ACM SIGPLAN Lisp Pointers","volume":"19 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1988-04-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"134498507","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Compacting garbage collection with ambiguous roots","authors":"J. Bartlett","doi":"10.1145/1317224.1317225","DOIUrl":"https://doi.org/10.1145/1317224.1317225","url":null,"abstract":"Many modern garbage collectors [4] recover space by copying. Using an initial \"root\" set of pointers which are stored in known locations, all accessible objects are copied into a \"new space\". Two of the attractive properties of such a collector are that it results in memory compaction and it can have a running time proportional to the amount of accessible storage [2]. However, such schemes place a large burden on the underlying system as all pointers to the objects must be found and changed.","PeriodicalId":262740,"journal":{"name":"ACM SIGPLAN Lisp Pointers","volume":"31 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1988-04-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"124914098","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
求助内容：
应助结果提醒方式：
京公网安备 11010802042870号
