An Overview of Eulisp

Total Page:16

File Type:pdf, Size:1020Kb

An Overview of Eulisp LISP AND SYMBOLIC COMPUTATION An International Journal c Kluwer Academic Publishers Manufactured in The Netherlands An overview of EuLisp JULIAN PADGET japmathsbathacuk University of Bath School of Mathematical Sciences Bath BA AY United Kingdom GREG NUYENS nuyensilogcom Ilog Inc Landings Drive Mountain View CA USA HARRY BRETTHAUER bretthauergmdde German National Research Centre for Computer Science GMD POBox W Sankt Augustin FRG Keywords Lisp mo dules concurrency ob jectoriented programming conditions re ection Abstract This pap er is an abstracted version of the EuLisp denition As such it emphasizes those parts of the language that we consider the most imp ortant or note worthy while we just mention without much detail the elements that are included for completeness This is reected in the structure of the pap er which describ es the mo dule scheme the ob ject system and supp ort for concurrent execution in the main part and consigns the ma jority of the datatyp es to an app endix Intro duction EuLisp is a dialect of Lisp and as such owes much to the great b o dy of work that has b een done on language design in the name of Lisp over the last thirty years The distinguishing features of EuLisp are i the integration of the classical Lisp typ e system and the ob ject system into a single class hierarchy ii the complementary abstraction facilities provided by the class and the mo dule mechanism iii supp ort for concurrent execution Here is a brief summary of the main features of the language Classes are rstclass ob jects The class structure integrates the prim itive classes describing fundamental datatyp es the predened classes and userdened classes Mo dules together with classes are the building blo cks of b oth the EuLisp language and of applications written in EuLisp The mo dule This work has b een supp orted by to o many organisations and programmes to name them individu al ly here although sp ecial mention should b e made of the Commission of the Europ ean Communities and Jean Omnes of DG XI I I Information technology directorate A complete list of acknowledgements app ears in Section PADGET NUYENS BRETTHAUER system exists to limit access to ob jects by name That is mo dules allow for hidden denitions Each mo dule denes a fresh empty lexical environment Multiple control threads can b e created in EuLisp and the concur rency mo del has b een designed to allow consistency across a wide range of architectures Access to shared data can b e controlled via lo cks semaphores Eventbased programming is supp orted through a generic waiting function Both functions and continuations are rstclass in EuLisp but the latter are not as general as in Scheme b ecause they can only b e used in the dynamic extent of their creation That implies they can only b e used once A condition mechanism which is fully integrated with b oth classes and threads allows for the denition of generic handlers and which supp orts b oth propagation of conditions and continuable handling Dynamically scop ed bindings can b e created in EuLisp but their use is restricted as in Scheme EuLisp enforces a strong distinc tion b etween lexical bindings and dynamic bindings by requiring the manipulation of the latter via sp ecial forms EuLisp do es not claim any particular Lisp dialect as its closest relative although parts of it were inuenced by features found in Common Lisp InterLISP LELISP LISPVM Scheme and T EuLisp b oth intro duces new ideas and takes from these Lisps It also extends or simplies their ideas as necessary But this is not the place for a detailed language comparison That can b e drawn from the rest of this text EuLisp breaks with LISP tradition in describing all its typ es in fact classes in terms of an ob ject system This is called The EuLisp Ob ject System or TELOS TELOS incorp orates elements of the Common Lisp Ob ject System CLOS Ob jVLisp Oaklisp MicroCeyx and MCS Language Structure The EuLisp denition comprises the following items Level comprises all the level functions macros and sp ecial forms which is this text minus App endix B The ob ject system can b e extended by userdened structure classes and generic functions Level extends level with the functions macros and sp ecial forms de ned in App endix B The ob ject system can b e extended by user AN OVERVIEW OF EuLisp dened classes and metaclasses The implementation of level is not necessarily written or writable as a conforming level program A level function is a generic function dened in this text to b e part of a conforming pro cessor for level A function dened in terms of level op erations is an example of a level application Much of the functionality of EuLisp is dened in terms of mo dules These mo dules might b e available and used at any level but certain mo dules are required at a given level Whenever a mo dule dep ends on the op erations available at a given level that dep endency will b e sp ecied EuLisplevel is provided by the mo dule eulisplevel This mo dule imp orts and reexp orts the mo dules sp ecied in Table Table Mo dules comprising eulisplevel Mo dule Sections character A collection A compare A condition convert A copy A doublefloat A elementaryfunctions A event fixedprecisioninteger A formattedio A function lock null A number A object pair A stream A string A symbol A syntax table A thread vector A PADGET NUYENS BRETTHAUER This denition is organized in three parts Sections describ es the core of level of EuLisp covering mo dules simple classes ob jects and generic functions threads conditions con trol forms and events These sections contain the information ab out EuLisp that characterizes the language App endix A describ es the additional classes required at level and the op erations dened on instances of those classes The app endix is organized by class in alphab etical order These sections contain in formation ab out the predened classes in EuLisp that are necessary to make the language usable but is not central to an appreciation of the language App endix B describ es the reective asp ects of the ob ject system and how to program the metaob ject proto col and some additional con trol forms Prior to these sections dene the scop e of the text and error denitions and typ ographical and layout conventions used in this text Scop e This text sp ecies the syntax and semantics of the computer programming language EuLisp by dening the requirements for a conforming EuLisp pro cessor and a conforming EuLisp program the textual representation of data and algorithms This text do es not sp ecify The size or complexity of a EuLisp program that will exceed the capacity of any sp ecic conguration or pro cessor nor the actions to b e taken when those limits are exceeded The minimal requirements of a conguration that is capable of sup p orting an implementation of a EuLisp pro cessor The metho d of preparation of a EuLisp program for execution or the metho d of activation of this EuLisp program once prepared The metho d of rep orting errors warnings or exceptions to the client of a EuLisp pro cessor The typ ographical representation of a EuLisp program for human reading AN OVERVIEW OF EuLisp The means to map mo dule names to the ling system or other ob ject storage system attached to the pro cessor To clarify certain instances of the use of English in this text the following denitions are provided must a verbal form used to intro duce a required prop erty All conforming pro cessors must satisfy the prop erty should A verbal form used to intro duce a strongly recommended prop erty Implementors of pro cessors are urged but not required to satisfy the prop erty Error Denitions Errors in the language describ ed in this denition fall into one of the fol lowing three classes dynamic error An error which is detected during the execution of a EuLisp program or which is a violation of the dened dynamic b ehaviour of EuLisp Dynamic errors have two classications Where a conforming processor is required to detect the erroneous sit uation or b ehaviour and rep ort it This is signied by the phrase an error is signal led The condition class to b e signalled is sp eci ed Signalling an error consists of identifying the condition class related to the error and allo cating an instance of it This instance is initialize d with information dep endent on the condition class A conforming EuLisp program can rely on the fact that this condition will b e signalled Where a conforming processor might or might not detect and rep ort up on the error This is signied by the phrase is an error A pro cessor should provide a mo de where such errors are detected and rep orted where p ossible environmental error An error which is detected by the conguration supp orting the EuLisp pro cessor The pro cessor must signal the corre sp onding dynamic error which is identied and handled as describ ed ab ove static error An error which is detected during the preparation of a Eu Lisp program for execution such as a violation of the syntax or static semantics of EuLisp by the program under preparation PADGET NUYENS BRETTHAUER NOTE The violation of the syntactic or static semantic requirements is not an error but an error might b e signalled by the program p erforming the analysis of the EuLisp program All errors sp ecied in this denition are dynamic unless explicitly stated otherwise Conventions This section denes the conventions employed in this text how denitions will b e laid out the typ eface to b e used the metalanguage used in de scriptions and the naming conventions App
Recommended publications
  • Equal Rights for Functional Objects Or, the More Things Change, The
    ACM OOPS Messenger 4,4 (Oct. 1993), 2-27. Equal Rights for Functional Objects1 or, The More Things Change, The More They Are the Same2 Henry G. Baker Nimble Computer Corporation 16231 Meadow Ridge Way, Encino, CA 91436 (818) 986-1436 (818) 986-1360 FAX August, October, 1990, October, 1991, and April, 1992 This work was supported in part by the U.S. Department of Energy Contract No. DE-AC03-88ER80663 We argue that intensional object identity in object-oriented programming languages and databases is best defined operationally by side-effect semantics. A corollary is that "functional" objects have extensional semantics. This model of object identity, which is analogous to the normal forms of relational algebra, provides cleaner semantics for the value-transmission operations and built-in primitive equality predicate of a programming language, and eliminates the confusion surrounding "call-by-value" and "call-by-reference" as well as the confusion of multiple equality predicates. Implementation issues are discussed, and this model is shown to have significant performance advantages in persistent, parallel, distributed and multilingual processing environments. This model also provides insight into the "type equivalence" problem of Algol-68, Pascal and Ada. 1. INTRODUCTION Parallel, distributed and persistent programming languages are leaving the laboratories for more wide-spread use. Due to the substantial differences between the semantics and implementations of these languages and traditional serial programming languages, however, some of the most basic notions of programming languages must be refined to allow efficient, portable implementations. In this paper, we are concerned with defining object identity in parallel, distributed and persistent systems in such a way that the intuitive semantics of serial implementations are transparently preserved.
    [Show full text]
  • The Evolution of Lisp
    1 The Evolution of Lisp Guy L. Steele Jr. Richard P. Gabriel Thinking Machines Corporation Lucid, Inc. 245 First Street 707 Laurel Street Cambridge, Massachusetts 02142 Menlo Park, California 94025 Phone: (617) 234-2860 Phone: (415) 329-8400 FAX: (617) 243-4444 FAX: (415) 329-8480 E-mail: [email protected] E-mail: [email protected] Abstract Lisp is the world’s greatest programming language—or so its proponents think. The structure of Lisp makes it easy to extend the language or even to implement entirely new dialects without starting from scratch. Overall, the evolution of Lisp has been guided more by institutional rivalry, one-upsmanship, and the glee born of technical cleverness that is characteristic of the “hacker culture” than by sober assessments of technical requirements. Nevertheless this process has eventually produced both an industrial- strength programming language, messy but powerful, and a technically pure dialect, small but powerful, that is suitable for use by programming-language theoreticians. We pick up where McCarthy’s paper in the first HOPL conference left off. We trace the development chronologically from the era of the PDP-6, through the heyday of Interlisp and MacLisp, past the ascension and decline of special purpose Lisp machines, to the present era of standardization activities. We then examine the technical evolution of a few representative language features, including both some notable successes and some notable failures, that illuminate design issues that distinguish Lisp from other programming languages. We also discuss the use of Lisp as a laboratory for designing other programming languages. We conclude with some reflections on the forces that have driven the evolution of Lisp.
    [Show full text]
  • Balancing the Eulisp Metaobject Protocol
    Balancing the EuLisp Metaob ject Proto col x y x z Harry Bretthauer and Harley Davis and Jurgen Kopp and Keith Playford x German National Research Center for Computer Science GMD PO Box W Sankt Augustin FRG y ILOG SA avenue Gallieni Gentilly France z Department of Mathematical Sciences University of Bath Bath BA AY UK techniques which can b e used to solve them Op en questions Abstract and unsolved problems are presented to direct future work The challenge for the metaob ject proto col designer is to bal One of the main problems is to nd a b etter balance ance the conicting demands of eciency simplicity and b etween expressiveness and ease of use on the one hand extensibili ty It is imp ossible to know all desired extensions and eciency on the other in advance some of them will require greater functionality Since the authors of this pap er and other memb ers while others require greater eciency In addition the pro of the EuLisp committee have b een engaged in the design to col itself must b e suciently simple that it can b e fully and implementation of an ob ject system with a metaob ject do cumented and understo o d by those who need to use it proto col for EuLisp Padget and Nuyens intended This pap er presents a metaob ject proto col for EuLisp to correct some of the p erceived aws in CLOS to sim which provides expressiveness by a multileveled proto col plify it without losing any of its p ower and to provide the and achieves eciency by static semantics for predened means to more easily implement it eciently The current metaob
    [Show full text]
  • Comparative Studies of 10 Programming Languages Within 10 Diverse Criteria
    Department of Computer Science and Software Engineering Comparative Studies of 10 Programming Languages within 10 Diverse Criteria Jiang Li Sleiman Rabah Concordia University Concordia University Montreal, Quebec, Concordia Montreal, Quebec, Concordia [email protected] [email protected] Mingzhi Liu Yuanwei Lai Concordia University Concordia University Montreal, Quebec, Concordia Montreal, Quebec, Concordia [email protected] [email protected] COMP 6411 - A Comparative studies of programming languages 1/139 Sleiman Rabah, Jiang Li, Mingzhi Liu, Yuanwei Lai This page was intentionally left blank COMP 6411 - A Comparative studies of programming languages 2/139 Sleiman Rabah, Jiang Li, Mingzhi Liu, Yuanwei Lai Abstract There are many programming languages in the world today.Each language has their advantage and disavantage. In this paper, we will discuss ten programming languages: C++, C#, Java, Groovy, JavaScript, PHP, Schalar, Scheme, Haskell and AspectJ. We summarize and compare these ten languages on ten different criterion. For example, Default more secure programming practices, Web applications development, OO-based abstraction and etc. At the end, we will give our conclusion that which languages are suitable and which are not for using in some cases. We will also provide evidence and our analysis on why some language are better than other or have advantages over the other on some criterion. 1 Introduction Since there are hundreds of programming languages existing nowadays, it is impossible and inefficient
    [Show full text]
  • Ccured Type-Safe Retrofitting of Legacy Code
    CCured Type-Safe Retrofitting of Legacy Code George C. Necula Scott McPeak Westley Weimer University of California, Berkeley {necula, smcpeak, weimer}@cs, berkeley, edu Abstract While in lhe 1970s sacrificing lype safely for flexibilily and perfbrmance mighl have been a sensible language design In lhis paper we propose a scheme lhai combines type in- choice, today lhere are more and more siiuaiions in which ference and run-time checking to make exisiing C programs type safety is jusi as imporiani as, if noi more importani type saI~. }V~ describe lhe CCured type sysiem, which ex- lhan, performance. Errors like array oui-of:bounds accesses lends lhat of C by separaiing poinier types according to lead boih lo painful debugging sessions chasing inadverieni lheir usage. This type sysiem allows boih poiniers whose memory updaies and lo malicious atiacks exploiiing buft>r usage can be verified siaiically to be type saI>, and poiniers overrun errors in security-criiical code. (Almost g0% of re- whose sai>ty musi be checked ai run lime. }V~ prove a type ceni CERT advisories resuli fi'om security violaiions of this soundness resuli and lhen we preseni a surprisingly simple kind [29].) Type safety is desirable for isolaiing program type inference algoriihm lhai is able lo infer lhe appropriaie componenis in a large or exiensible sysiem, wiihoui lhe loss poinier kinds for exisiing C programs. of performance of separaie address spaces. II is also valu- Our experience wiih lhe CCured sysiem shows lhai lhe able for inter-operaiion wiih sysiems wriiien in type-saf> inference is very eft~ciive for many C programs, as ii is able languages (such as type-saf> Java naiive meihods, for exam- io infer ihai most or all of the pointers are statically ver- pie).
    [Show full text]
  • The Embeddable Common Lisp
    ACM Lisp Pointers 8(1), 1995, 30-41 The Embeddable Common Lisp Giuseppe Attardi Dipartimento di Informatica, Universit`adi Pisa Corso Italia 40, I-56125 Pisa, Italy net: [email protected] Abstract The Embeddable Common Lisp is an implementation of Common Lisp designed for being embeddable within C based applications. ECL uses standard C calling conventions for Lisp compiled functions, which allows C programs to easily call Lisp functions and viceversa. No foreign function interface is required: data can be exchanged between C and Lisp with no need for conversion. ECL is based on a Common Runtime Support (CRS) which provides basic facilities for memory management, dynamic loading and dumping of binary images, support for multiple threads of execution. The CRS is built into a library that can be linked with the code of the application. ECL is modular: main modules are the program development tools (top level, debugger, trace, stepper), the compiler, and CLOS. A native implementation of CLOS is available in ECL: one can configure ECL with or without CLOS. A runtime version of ECL can be built with just the modules which are required by the application. 1 Introduction As applications become more elaborate, the facilities required to build them grow in number and sophistica- tion. Each facility is accessed through a specific package, quite complex itself, like in the cases of: modeling, simulation, graphics, hypertext facilities, data base management, numerical analysis, deductive capabilities, concurrent programming, heuristic search, symbolic manipulation, language analysis, special device control. Reusability is quite a significant issue: once a package has been developed, tested and debugged, it is un- desirable having to rewrite it in a different language just because the application is based in such other language.
    [Show full text]
  • Some Non-Standard Issues on Lisp Standardization
    Some Non-standard Issues on Lisp Standardization Takayasu IT0 * Taiichi YUASA Introduction Lisp was born about 25 years ago as an A1 language with a precise operational semantics. Since then many Lisp dialects have been proposed, implemented and used. In 1960's Lisp 1.5 was a kind of Lisp standard, although there were many Lisp 1.5 dialects which depend on 1/0 and computer systems. In 1970's various Lisp dialects were spawned to respond to the need of more powerful Lisp systems for A1 research and symbolic computation. Among them we know that Lisp 1.6, Interlisp and Maclisp had big influences in the development of Lisp; especially, Maclisp brought us various interesting successors, including Franzlisp, Scheme, Zet alisp and Common Lisp. Common Lisp [STEELE] may be taken as a result of standardization activities of Maclisp and its successors, and Scheme is one of the first steps to try to settle and resolve some syntactic and semantic incompatibilities in Maclisp families. Eulisp [PADGET] may be taken to be another attempt along with this line with greater ambition for Lisp standardization, employing the design philosophy of extensible languages based on "leveling of languages". Various design and standardization issues have been considered and examined in the course of designing Common Lisp and Eulisp. The current standardization activities in US and Europe are mainly placed on "clean-upn of Common Lisp and "refinement and development" of Eulisp, in addition to efforts of designing object-oriented features in Lisp systems. In a sense major (standard) issues in Lisp standardization have been considered in these efforts of clean-up of Common Lisp and design of Eulisp.
    [Show full text]
  • Programming Language Eulisp
    Programming Language Eulisp Version 0.99 Programming Language EuLisp, version 0.99 Contents Page Foreword :::::::::::::::::::::::::::::::::::::::::::::::::: 1 Introduction ::::::::::::::::::::::::::::::::::::::::::::::: 2 1 Language Structure :::::::::::::::::::::::::::::::::::::: 2 2 Scope :::::::::::::::::::::::::::::::::::::::::::::::::: 3 3 Conformance Definitions :::::::::::::::::::::::::::::::::: 3 4 Error Definitions :::::::::::::::::::::::::::::::::::::::: 3 5 Compliance ::::::::::::::::::::::::::::::::::::::::::::: 4 6 Conventions :::::::::::::::::::::::::::::::::::::::::::: 4 6.1 Layout and Typography ::::::::::::::::::::::::::::::::: 4 6.2 Meta-Language :::::::::::::::::::::::::::::::::::::::: 6 6.3 Naming ::::::::::::::::::::::::::::::::::::::::::::: 6 7 Definitions :::::::::::::::::::::::::::::::::::::::::::::: 6 8 Syntax ::::::::::::::::::::::::::::::::::::::::::::::::: 9 8.1 Whitespace and Comments ::::::::::::::::::::::::::::::: 9 8.2 Objects ::::::::::::::::::::::::::::::::::::::::::::: 9 9 Modules :::::::::::::::::::::::::::::::::::::::::::::::: 10 9.1 Directives :::::::::::::::::::::::::::::::::::::::::::: 10 9.2 Export Directive ::::::::::::::::::::::::::::::::::::::: 10 9.3 Import Directive ::::::::::::::::::::::::::::::::::::::: 10 9.4 Expose Directive :::::::::::::::::::::::::::::::::::::: 11 9.5 Syntax Directive ::::::::::::::::::::::::::::::::::::::: 11 9.6 Definitions and Expressions :::::::::::::::::::::::::::::: 11 9.7 Module Processing ::::::::::::::::::::::::::::::::::::: 12 9.8 Module Definition ::::::::::::::::::::::::::::::::::::::
    [Show full text]
  • Oaklisp: an Object-Oriented Scheme with First Class Types
    Oaklisp: an Object-Oriented Scheme with First Class Types Kevin J. l,ang and llarak A. Peaflmutter Department of Computer Science Carnegie-Mellon University Pittsburgh, PA 15213 Abstract several implications that are not immediately obvious. Because • The Scheme papers demonstrated that lisp could be made simpler function can be applied at a point distant in time and space from ilz and more expressive by elevating functions to the level of first class point of origin, it must be able to remember the bindings of any objects. Oaklisp shows that a message based language can derive variables that were visible when it was made. This additional similar benefits from having first class types. complexity is offset by the ability to write many previously primitive control structures at the user level and by the fact that the special Introduction mechanisms that lisp ordinarily uses for defining and applying Oaklisp is a message based, multiple inheritence dialect of lisp. functions can be dispensed with. Programs are written using lisp syntax, and traditional lisp data types In lisp, the car position of a function call is treated as the name of a coexist with a Smalltalk style class hierarchy. This paper assumes that function which is looked up in a special table and then applied to the the reader is familiar with one of the many object-oriented lisp dialects values obtained by evaluating the arguments of the call. In Scheme, the of this sort. and will therefore concentrate on the unique aspects of car of a call is an evaluated position. Although any expression can Oaklisp which are mostly due to the influence of Scheme.
    [Show full text]
  • Einführung in LISP
    Einführung in LISP Simon Lutz, Frank Preiswerk “Real Programmers don't write in LISP. Only idiots' programs contain more parenthesis than actual code.” “Lisp is worth learning for the profound enlightenment experience you will have when you finally get it; that experience will make you a better programmer for the rest of your days, even if you never actually use Lisp itself a lot.” 04/19/06 Seminar 10 Programmiersprachen - Lisp/Scheme - Simon Lutz, Frank Preiswerk 1 Zeitlicher Überblick 1958: Lisp wurde von John McCarthy am MIT speziell für nicht-numerische Probleme designed und von Steve Russell auf einer IBM 704 Maschine implementiert. Der Name bedeutet “List Processing Language”. 1968: Erster Lisp Compiler geschrieben in Lisp von Tim Hart und Mike Levin. 1968-70: Implementation von SHRDLU mittels Lisp, berühmtes AI-System. 1970er Jahre: Performanz von bestehenden Lisp-Systemen wird zum Thema, es entstehen optimierte Lisp-Maschinen. Heute wieder verschwunden. 1980er – 1990er Jahre: Bemühungen für eine Vereinheitlichung der vielen bestehenden Lisp-Dialekte: Common Lisp entsteht. 1994: ANSI veröffentlicht Common Lisp Standard. Dies zu einem Zeitpunkt, als der Weltmarkt für Lisp viel kleiner war als in den früheren Zeiten. 04/19/06 Seminar 10 Programmiersprachen - Lisp/Scheme - Simon Lutz, Frank Preiswerk 2 Lisp heute Nach einem Rückgang in den 90er Jahren ist das Interesse seit 2000 wieder gestiegen, massgeblich im Rahmen von Open Source Implementationen von Common Lisp. 2004: Peter Seibel’s “Practical Common Lisp” ist für kurze Zeit an zweiter Stelle von Amazon’s populärsten Programmierbüchern. April 2006: Tiobe Software rankt Lisp auf Platz 14 der populärsten Programmiersprachen. Neue “Lisper” beschreiben die Sprache gerne als “eye-opening experience” und behaupten, in Lisp deutlich produktiver zu sein als in anderen Sprachen.
    [Show full text]
  • New Model for VDT Associated Visual Comfort in Office Spaces
    Niloofar Moghbel New Model for VDT Associated Visual Comfort in Office Spaces Dissertation Department of Architecture Karlsruhe Institute of Technology (KIT) New Model for VDT Associated Visual Comfort in Office Spaces Zur Erlangung des akademischen Grades eines Doktor-Ingenieurs von der Fakultät für Architektur des Karlsruher Instituts für Technologie (KIT) genehmigte Dissertation von Niloofar Moghbel Tag der mündlichen Prüfung: 19. April 2012 Referent: Prof. Dipl.-Ing. Andreas Wagner, Karlsruhe Korreferent: Prof. Dr. Sc. nat. Christoph Schierz, TU Ilmenau Weiteres Mitglied: Prof. Dr. Ing. Rosemarie Wagner Vorsitzender: Prof. Dipl.-Ing. Matthias Pfeifer 2 Acknowledgements This thesis has been carried out during my tenure at the Fraunhofer Institute for Solar Energy Systems (ISE) in Freiburg, Germany. I am indebted to the Fraunhofer ISE for providing me with an excellent scientific environment, financial support and research facilities. I appreciate Prof. Weber, Dr. Henning, S. Herkel. T. Kuhn and J. Wienold for their support to realize and conduct this work. My Ph.D. thesis has been conducted within the framework of a DFG funded project (QUANTA). I acknowledge the QUANTA partners, Fraunhofer Institute for Solar Energy Systems (Freiburg) and department of Architecture at the Karlsruhe Institute of Technology (KIT). I want to thank Prof. Andreas Wagner for accepting me as a Ph.D. student at the department of Architecture of the Karlsruhe Institute of Technology (KIT), Germany and for supervising my Ph.D. thesis. Many thanks to Prof. Christoph Schierz (TU Ilmenau, D) for accepting to be the co-advisor of my thesis, for all his kind support and advice whilst conducting this research including performing the experimental procedure in person described in chapter 5 which provided valuable insight.
    [Show full text]
  • A Bibliography of Publications in ACM SIGPLAN Notices, 1980–1989
    A Bibliography of Publications in ACM SIGPLAN Notices, 1980{1989 Nelson H. F. Beebe University of Utah Department of Mathematics, 110 LCB 155 S 1400 E RM 233 Salt Lake City, UT 84112-0090 USA Tel: +1 801 581 5254 FAX: +1 801 581 4148 E-mail: [email protected], [email protected], [email protected] (Internet) WWW URL: http://www.math.utah.edu/~beebe/ 20 June 2019 Version 3.26 Title word cross-reference 1 [1625, 1284, 1078]. 1/83 [509]. 100 [1190]. 11 [95, 390, 139, 393]. 11/780 [139]. 1100 [58]. 16-bit [1828]. 164 [721]. 1838 [1612]. 1978 [39]. 1980 [1943, 245]. 1980's [760]. 1981 [1946, 312, 311, 345, 354]. 1982 [1948]. #16G [797]. 1983 [1952, 1953]. 1984 [1955, 1956]. 1985 [1142]. 1986 [1960, 1961, 1962, 18, 19]. 1987 ∗ 3 + [1637]. 2 [1822]. = [328, 1637]. [1586]. [20, 25, 1239, 1357]. 1989 [39]. 198x TM 8 [1105]. [1827]. Ada [140]. [1850]. λ [39, 1388]. [1887]. n [1108]. N ≤ 8 [998, 1145, 1011]. ! 0 [1914]. [1637]. 2' [832, 1004, 941, 1383, 918, 1191, 1500, 1006, 1193, 919, 920, 949, 1007, 1145, 1196, * [918]. 950, 1376, 526, 843, 1158, 837, 1633, 800, 782, 913, 748, 1155, 1149, 791, 790, 1554, -calculus [1887]. -dimensional [1822]. 452, 634, 459, 1183, 966, 688, 842, 967]. 2000 -ively [1521]. [1833, 1844, 1847]. /information [195]. 3 [1924, 1477]. 32 [375, 371]. 32-bit [1828]. 370 [1203]. 0-201-17928-8 [1614]. 002R [1356]. 1 2 432 [650, 387]. 4381 [1269]. ACM-SIGPLAN [1943]. ACM/SIGPLAN [1971]. Acore [1645]. 6 [619]. 68 [513, 66, 107].
    [Show full text]