DOCSLIB.ORG

A Bibliography of Publications in ACM SIGPLAN Notices, 1980–1989

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read 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]. 6th [768]. acquisition [1751]. acronym [1691]. Action [559, 1564]. actions 74 [408]. 754 [11, 1939, 1142]. 754-1985 [683, 1204, 1205, 1423]. Active [1316, 1596]. [1938, 1142, 1939]. 77 [340, 1227]. 780 [139]. activities [191, 1686]. actor [1020, 1639, 1643, 1644, 1645]. Actors 80 [687, 1033, 1640, 1641, 1642, 1037, 1021]. [1066, 1640, 1804, 1273, 1064, 1667, 493, 1334, Actra [1646]. ad [1912, 1912]. ad-hoc 1100, 1794, 1111, 1065, 1087, 1524, 1522]. [1912]. Ada '81 [1950]. '82 [1948]. '83 [1952, 760, 1954]. [1943, 1809, 523, 127, 918, 64, 236, 65, 235, '84 [1958]. '86 [1960, 1962, 1963, 424, 1069]. 115, 254, 1313, 169, 246, 245, 247, 100, 149, '87 [1964, 1966]. '88 [1967, 1968, 1356, 36]. 438, 135, 151, 343, 154, 742, 322, 323, 744, 121, 88-002R [1356]. 8800 [1281]. '89 140, 1108, 144, 250, 659, 102, 324, 150, 1697, [1972, 1973, 1974, 1977, 1980]. 8X [22, 13, 440, 132, 131, 949, 148, 129, 124, 133, 950, 39, 31, 29, 28, 24, 32, 21, 30, 35, 14, 1483]. 153, 910, 138, 356, 85, 143, 152, 141, 145, 243, 1188, 1123, 241, 341, 106, 130, 108, 134, 256, = [787, 491]. 387, 137, 1702, 1451, 139, 136, 244, 700, 147, 1186, 329, 320, 338, 142, 1003, 665, 319, 370]. abandon [496, 443]. ABCL [1625, 1078]. Adding [1626, 1429, 902, 1558]. Addison ABCL/1 [1625, 1078]. Abelson [1161]. [1614]. Addison-Wesley [1614]. Addition ABF [1230]. abridgement [30]. absolute [270]. address [1267, 1341, 1400]. [789]. Abstract [1422, 217, 663, 713, 1033, addressable [1828]. addressing 656, 1818, 1923, 1191, 1034, 678, 1035, 1486, [1274, 1789, 382]. ADE [1130]. adequacy 1036, 1181, 1921, 252, 1918, 1897, 1038, 1196, [1891]. ADTs [1158]. advanced 1920, 1853, 1040, 73, 1041, 1895, 1042, 948, [454, 607, 700]. advancement [1687]. 1860, 1043, 1099, 1044, 1929, 1453, 1454, advances [1335]. advice [255]. after 1045, 1149, 69, 1047, 352, 1048, 1049, 1182, [631, 632]. again [1191, 652]. against 957, 1050, 966, 967, 1051, 675, 1037, 229]. [121, 1699, 479, 1182, 966, 967]. agent Abstracting [642]. Abstraction [650, 176, [1774]. agents [1775]. ages [1774]. 558, 223, 1538, 1452, 1730, 192, 643, 1500, aggregate [973]. ahead [983]. AI [1652]. 658, 554, 1917, 1869, 205, 209, 1341, 1400, aid [612]. Aided [706]. aids [289, 469, 1889]. 567, 551, 178, 222, 226, 1877, 227, 540, 857]. Aldus [1780]. Alex [954, 1113]. algebra Abstractions [860, 520, 1546, 201, 568]. [574, 336, 542, 859, 1779]. algebraic abundance [1415]. abuse [581]. acce [781]. [1080, 1031, 1035, 645, 514, 98, 1367]. acce-specifications [781]. Accelerator algebras [230]. ALGOL [1082]. acceptance [928]. accepted [957]. [66, 107, 513, 1424, 441]. Algol68 [168]. Acceptive [575, 671]. access algorithm [1717, 206, 1633, 1179, 1739, 278]. [498, 234, 1136, 236, 1513, 298, 1753, 414, 495, access-control [278]. accesses [1435]. 328, 1011, 777, 55, 712, 1511, 1548, 1755]. according [927]. ACM Algorithmic [1105, 1585]. Algorithms [1943, 1946, 1955, 1954, 1945, 1976, 1959, [147, 233, 1550, 5, 982, 1249, 1171, 1498, 689]. 1978, 1957, 1965, 1969, 1953, 1950, 1970, alias [1911]. aliases [1874]. allocated 1944, 1958, 1979, 1947, 1971, 246]. [1903]. Allocation 3 [794, 442, 398, 1738, 416, 1432, 739, 1234, 1224, 1644, 52, 209, 1158, 946, 215, 1329, 377, 1737, 995, 692, 996, 1440, 70, 1511]. 1339, 732, 1766, 1166, 560, 1541, 1135, 1768, allows [421]. alone [1524]. Alonzo [1761]. 630, 1809]. Approaches [1051, 1264, 842]. Alternate [785, 29, 334]. alternative Approximations [1359]. April [1, 378, 896, 1204, 1205, 516, 1097, 1098, 169, [1955, 1975, 1957]. APSE [121, 1612]. 801, 636]. Alternatives [838]. Alto arbitrary [983]. ARC [783]. Arcadia [1962, 1965, 1963]. Ambiguities [1589]. Architectural [452, 1478, 1183, 771]. Ambiguity [1975, 1261, 384, 378, 389, 726, 394, 1276]. [370, 474]. ambiguous [1706]. American Architecture [1834, 396, 156, 1079, 1282, [39, 1142]. Amit [894]. Amoeba [1562]. 1072, 970, 1263, 1204, 1205, 374, 1278, 1754, among [185, 744, 647]. AMPL [775]. 1071, 390, 1010, 388, 1589, 1647, 476, 1270]. analog [1471]. analogy [1167]. analyser architectures [659]. analysers [1507]. Analysis [1648, 1649, 1672, 901, 1262, 384, 1259]. [10, 850, 677, 1545, 1452, 1369, 322, 986, Arcturus [700]. area [85, 556]. aren't 1437, 1571, 1136, 1902, 1364, 942, 1604, 537, [1185]. argument [455]. Arguments 854, 1438, 1439, 1911, 1901, 1360, 1577, 1164, [490, 491]. Arithmetic [7, 9, 11, 1939, 1941, 263, 1716, 1180, 1449, 980, 751, 1295, 1754, 8, 1937, 1873, 485, 1940, 1936, 1938, 1142]. 735, 1862, 556, 1487, 899, 59, 392, 624, 533, array [1483, 1482, 1578, 972, 1905, 636]. 1896, 1860, 1887, 1227, 1903, 1910, 1457, arrays [959, 1837, 45]. arrow [255]. article 1450, 168, 391, 612, 1714, 1889, 937, 731]. [113]. artificial [175]. Arun [635]. ascent analytic [1093]. analyzer [1471]. Aspects [1749, 431]. Aspen¨as [476]. [417, 51, 136, 1114]. Analyzing assembler [451, 1485, 238]. assembly [1678, 729, 427]. Anatomy [1443, 951]. [729, 663]. Assertions [56, 1621]. assessed Andrew [1614]. Angeles [1821]. assessment [1689, 469, 868]. [231, 1950, 1944, 1947]. Animated [1532]. assessments [827]. assigning [498]. ANNA [143, 1702]. annotated [302]. assignment [1909, 1883]. assignments annotating [143]. Annual [1878, 787]. assist [1260]. assistance [611]. [1964, 1972, 1973]. anomalies [1739]. assistant [1598, 1681]. assisted [608]. anomaly [1822]. Anonymous [1842]. ANS associate [1535]. Associating [208]. [771]. ANSI [577, 1938, 1939, 1142]. assumptions [326, 75]. astro [1257]. ANSI/IEEE [1938, 1142, 1939]. answer Asynchronous [1837, 1549, 1905, 1460]. [267, 268]. anybody [769]. APL Atlanta [1968]. atomic [555]. attainable [483, 1550, 273, 927, 447, 959, 400, 168]. [686]. attitudes [97]. Attribute APLOMB [400]. Application [531, 848, 553, 733, 1902, 1713, 440, 424, 723, [186, 1760, 349, 643, 1130, 590, 1679, 1780, 978, 1724, 973, 623, 724, 734, 423, 1600, 74, 1072, 1091, 1904, 222, 1520, 1012, 1082]. 977, 1290, 1910, 1725, 1455, 1548]. Applications attributed [630]. Attributes [1960, 1494, 11, 1521, 1977, 192, 132, 1138, [847, 498, 530, 536, 853, 1133, 1289, 1540]. 1653, 1283, 1071, 1749, 1910, 168, 1524, 1971]. attribution [1601, 1290]. Augmentation applicative [1099]. August [18]. Austin [1972, 1973]. [1553, 1495, 470, 434, 1427, 1216]. Applying authorization [1429]. AUTO [1616]. [1330]. Appraising [1866]. Approach automata [1845]. Automated [809, 708, 601, 1899, 1641, 942, 78, 1446, 817, [17, 330, 1199]. Automatic [740, 1855, 1486, 199, 1577, 607, 290, 5, 554, 1091, 1449, 591, 1718, 727, 1570, 978, 728, 1441, 1887, 469, 4 1206, 1379, 128, 778, 1377, 1134, 1778, 412]. [92, 316, 15]. Binary [1938, 1939, 1142, automatically [1456, 737, 931]. 1941, 8, 499, 263, 1940, 830, 98, 1288, 1936]. Automating [1690]. automation [563]. Binding [1857, 1198, 1887]. Bindings autonomy [101]. available [246]. [1389]. BINS [811]. birds [144]. AVA N C E [1533]. average [1740]. avoid Bisimulation [1898, 1935]. Bit [484]. avoids [33]. AW B [1130]. [117, 1828, 359]. blackbox [1587]. BLAS AWB-ADE [1130]. AW K [649]. [906]. BLAZE [1633]. Blit [616, 617]. Axiomatic [211, 221]. Axioms [1851]. Block [1028, 1041, 1204, 1205, 285]. block-and-actions [1204, 1205]. B [486, 815, 905]. back [1733, 1463, 1464]. block-structured [285]. blocks [1240, 841]. background [302, 1285]. backing [1788]. Bn [891]. BNF [125]. BOF [1343, 1402]. backtracking [1525]. Backus [1172]. Book [1809, 1614, 940, 1239]. books backward [761]. backward-directed [761]. [280, 321, 353, 361, 272, 312, 311, 345, 354]. bad [1770, 1185]. Banquet [1352, 1411]. Boolean [1096]. Boston base [189, 1127, 207, 228]. Based [1943, 1948, 1975, 1969]. bottom [1864]. [1976, 1978, 1798, 1452, 1563, 1557, 429, bottom-up [1864]. bound [678]. boundary 1034, 1081, 1696, 1306, 1767, 101, 1174, 739, [1068]. boxcharts [1248]. bracketed [637]. 1594, 1059, 1523, 424, 1724, 1793, 696, 1074, Bracketing [264]. branches [263]. 701, 253, 694, 1146, 1598, 1681, 824, 1754, breaking [297]. Brevity [333]. brigade 73, 426, 1085, 526, 843, 1875, 1564, 586, 545, [1687]. BrouHaHa [1326]. bucket [1687]. 863, 1841, 1329, 1339, 935, 1786, 1685, 1254, bucket-brigade [1687]. BUFFERS [477]. 1461, 1200, 840, 1394, 587, 1541, 716, 278, bug [1702]. bugs [579]. build [1312, 1546]. 1592, 1519, 288, 792, 1516, 1310, 1635, 1852, builder [1698, 788]. Building 1694, 1687, 1636, 968, 571, 546, 864, 87, 225]. [399, 1072, 1525, 435, 1479, 648, 1770, 898]. bases BURS [1904]. Butterfly [1493]. bypass [188, 640, 208, 210, 218, 226, 1119, 217]. [1744]. bytecodes [1063]. Basic [1027, 1043, 234, 835, 577, 521].
Load more

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]
  • 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]
  • Dynamically Typed Languages
    Dynamically Typed Languages Laurence Tratt [email protected] Bournemouth University, Poole, Dorset, BH12 5BB, United Kingdom. Mar 13, 2009 Dynamically typed languages such as Python and Ruby have experienced a rapid grown in popularity in recent times. However, there is much confusion as to what makes these languages interesting relative to statically typed lan- guages, and little knowledge of their rich history. In this chapter I explore the general topic of dynamically typed languages, how they differ from statically typed languages, their history, and their defining features. 1 Introduction As computing is often split into software and hardware, so programming languages are often split into dynamically and statically typed languages. The traditional, simplified, definition of dynamically typed languages are that they do not enforce or check type- safety at compile-time, deferring such checks until run-time. While factually true, this definition leaves out what makes dynamically typed languages interesting|for example that they lower development costs [Ous98] and provide the flexibility required by specific domains such as data processing [MD04]. For many people, dynamically typed languages are the youthful face of a new style of programming introduced in the past few years. In fact, they trace their roots back to the earliest days of high-level programming languages in the 1950's via Lisp [McC60]. Many important techniques have been pioneered in dynamically typed languages from lexical scoping [SJ75] to Just-In-Time (JIT) compilation [Ayc03], and they remain a breeding ground for new ideas. Systems programming { seen as `serious' and thus demanding statically typed lan- guages { is often contrasted with scripting programming { seen as `amateurish' and thus needing little more than dynamically typed languages [Ous98].
    [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]
  • 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
    [Show full text]
  • Object Oriented Programming (OOP) Imperative Programming
    Object Oriented Programming (OOP) IIIA o New programming paradigm o Actions Æ Objects o Objects Å Actions o Object-oriented = Objects + Classes + Inheritance TAPIA 2005-2006 Imperative programming IIIA o OOP (Object-Oriented Programming) related o Local state, delegation, inheritance o History (Norvig,465): Algol 60 Æ SIMULA o Lisp extensions: o Smalltalk (69) o Flavors (79) o New Flavors (81) o Common Loops (88) o CLOS (91): standard TAPIA 2005-2006 History IIIA Dahl 1966 Algol60 Simula Classes single inheritance Nygaard LISP world Kay 1969 Smalltalk Goldberg Ingalls Steele 1976 LAMBDA Cannon 1979 Flavors multiple inheritance method combination Weinreb Symbolics 1981 New Flavors generic functions Xerox 1982 CommonLoops multimethods AT&T 1986 C++ Bell labs Meyer 1988 Oaklisp Eiffel Lang 1988 Perlmutter CLOS Steele 1991 JAVA TAPIA 2005-2006 AOP vs. OOP (Shoham) IIIA OOP AOP Basic unit Object (passive) Agent (active) State without restriction belief, commitment, competence, preferences, … Computation Message passing, methods Message passing, methods Type of messages without restriction Inform, request, offer, promise, reject, … Message no Honesty, consistency, rationality, restrictions … TAPIA 2005-2006 Nomenclature IIIA o Object: encapsulated local state and behavior o Class: describes similar objects with the same behavior and structure. o Instance: object belonging to a class. o Class Variable: variable shared by all the members of a class. o Instance Variable: encapsulated variable of an object. o Generic Function: its behavior depends on the types or classes of the arguments. TAPIA 2005-2006 Nomenclature IIIA o Message: Action name. Equivalent to a generic function. o Method: Specialization of a generic function. o Delegation: an object passes a task to another object.
    [Show full text]
  • Model Transformations in Converge. In: 2Nd Workshop in Software Model Engineering (Wisme 2003), October 2003, San Francisco
    Middlesex University Research Repository An open access repository of Middlesex University research http://eprints.mdx.ac.uk Tratt, Laurence and Clark, Tony (2003) Model transformations in converge. In: 2nd Workshop in Software Model Engineering (WiSME 2003), October 2003, San Francisco. [Conference or Workshop Item] This version is available at: https://eprints.mdx.ac.uk/5911/ Copyright: Middlesex University Research Repository makes the University’s research available electronically. Copyright and moral rights to this work are retained by the author and/or other copyright owners unless otherwise stated. The work is supplied on the understanding that any use for commercial gain is strictly forbidden. A copy may be downloaded for personal, non-commercial, research or study without prior permission and without charge. Works, including theses and research projects, may not be reproduced in any format or medium, or extensive quotations taken from them, or their content changed in any way, without first obtaining permission in writing from the copyright holder(s). They may not be sold or exploited commercially in any format or medium without the prior written permission of the copyright holder(s). Full bibliographic details must be given when referring to, or quoting from full items including the author’s name, the title of the work, publication details where relevant (place, publisher, date), pag- ination, and for theses or dissertations the awarding institution, the degree type awarded, and the date of the award. If you believe that any material held in the repository infringes copyright law, please contact the Repository Team at Middlesex University via the following email address: [email protected] The item will be removed from the repository while any claim is being investigated.
    [Show full text]
  • Programming Language Eulisp, Version 0.99
    Programming Language Eulisp Version Programming Language EuLisp version Contents Page Foreword Intro duction Language Structure Scop e Conformance Denitions Error Denitions Compliance Conventions Layout and Typ ography MetaLanguage Naming Denitions Syntax Whitespace and Comments Ob jects Mo dules Directives Exp ort Directive Imp ort Directive Exp ose Directive Syntax Directive Denitions and Expressions Mo dule Pro cessing Mo dule Denition Ob jects System Dened Classes Single Inheritance Dening Classes Dening Generic Functions and Metho ds Sp ecializin g Metho ds Metho d Lo okup and Generic Dispatch Creating and Initializi ng Ob jects Accessing Slots Concurrency Threads Lo cks Conditions Condition Classes Condition Handling ii Programming Language EuLisp version Expressions Denitions and Control Forms Simple Expressions Functions creation denition and application Destructive Op erations Conditional Expressions Variable Binding and Sequences Events Quasiquotation Expressions Summary of Level Expressions and Denitions Syntax of Level dening forms Syntax of Level expressions Syntax of Level macros Annexes ALevel Mo dule Library A Characters A Collections A Comparison A Conversion A Copying A Double Precision Floats A Elementary Functions A Floating Point Numbers A Fixed Precision Integers
    [Show full text]
  • The Oaklisp Language Manual
    The Oaklisp Language Manual October 21, 2002 Barak A. Pearlmutter Dept of Computer Science, FEC 313 University of New Mexico Albuquerque, NM 87131 [email protected] Kevin J. Lang NEC Research Institute 4 Independence Way Princeton, NJ 08540 [email protected] Copyright c 1985, 1986, 1987, 1988, 1989, 1991. by Barak Pearlmutter and Kevin Lang. Contents 1 Introduction 3 2 Types and Objects 6 2.1 Fundamental Types . 6 2.2 Operations on Objects . 7 2.3 Operations on Types . 7 2.4 Defining New Types . 7 2.5 Type Predicates . 8 2.6 Constants . 8 2.7 Standard Truth Values . 8 2.8 Coercion . 9 2.9 Mixing Types . 9 3 Methods and Scoping 10 3.1 Methods . 10 3.2 Scoping . 10 3.3 Functional Syntax . 11 3.4 Dispatching to Supertypes . 11 3.5 Rest Args . 12 4 Side Effects 13 4.1 Assignment . 13 4.2 Locatives . 13 4.3 Operation Types . 14 4.4 Modification Forms . 14 5 Evaluation and Locales 15 5.1 Evaluation . 15 5.2 Installing Names in a Locale . 15 5.3 Structuring the Namespace . 16 5.4 Variables . 17 5.5 Macros . 17 5.6 Compilation . 18 1 6 Dynamic State 19 6.1 Fluid Variables . 19 6.2 Non-local Exits . 19 6.3 Error Resolution . 21 6.3.1 Signaling Errors . 21 6.3.2 Restart Handlers . 21 6.3.3 Error Handlers . 22 6.3.4 Operations on Errors . 22 6.3.5 Error Types . 23 7 Control 24 7.1 Simple Constructs . 24 7.2 Mapping Constructs .
    [Show full text]
  • Modular Object-Oriented Programming with Units and Mixins
    Mo dular Ob ject-Oriented Programming with Units and Mixins Rob ert Bruce Findler Matthew Flatt Department of Computer Science Rice University Houston, Texas 77005-1892 class languages follow from a single language design prin- Abstract ciple: specify connectionsbetween modules or classes sepa- Mo dule and class systems haveevolved to meet the demand rately from their de nitions. for reuseable software comp onents. Considerable e ort has The shared principle of separating connections from def- b een invested in developing new mo dule and class systems, initions makes units and mixins synergistic. When units and in demonstrating howeach promotes co de reuse. How- and mixins are combined, a programmer can exploit the en- ever, relatively little has b een said ab out the interaction of capsulation and linking prop erties of units to control the these constructs, and how using mo dules and classes together application of mixin extensions (e.g.,tochange the class can improve programs. In this pap er, we demonstrate the extended by a particular mixin). synergy of a particular form of mo dules and classes|called In Section 5, we motivate in more detail the design b e- units and mixins, resp ectively|for solving complex reuse hind MzScheme's units and mixins, but their synergy is b est problems in a natural manner. demonstrated with an example. The bulk of this pap er therefore presents an in-depth example, showing how the synergy of units and mixins solves an old extensibility prob- 1 Intro duction lem [7, 40] in a natural manner. Section 2 describ es the extensibili ty problem, and Section 3 develops a rough solu- Mo dule and class systems b oth promote co de reuse.
    [Show full text]
  • On the Notion of Inheritance [Pdf]
    On the Notion of Inheritance ANTERO TAIVALSAARI Nokia Research Center One of the most intriguing—and at the same time most problematic—notions in object-oriented programming is inheritance. Inheritance is commonly regarded as the feature that distinguishes object-oriented programming from other modern programming paradigms, but researchers rarely agree on its meaning and usage. Yet inheritance is often hailed as a solution to many problems hampering software development, and many of the alleged benefits of object-oriented programming, such as improved conceptual modeling and reusability, are largely credited to it. This article aims at a comprehensive understanding of inheritance, examining its usage, surveying its varieties, and presenting a simple taxonomy of mechanisms that can be seen as underlying different inheritance models. Categories and Subject Descriptors: D.1.5. [Programming Techniques]: Object- Oriented Programming; D.3.2. [Programming Languages]: Language Classifications object-oriented languages; D.3.3. [Programming Languages]: Language Constructs and Features General Terms: Languages Additional Key Words and Phrases: Delegation, incremental modification, inheritance, language constructs, object-oriented programming, programming languages 1. INTRODUCTION only currently well-developed and widely accepted area seems to be the A characteristic feature of object-ori- theory of inheritance in terms of denota- ented programming is inheritance. In- tional semantics [Cook 1989a; Cook and heritance is often regarded as the fea- Palsberg 1989; Reddy 1988]. ture that distinguishes object-oriented Despite the fact that much effort has programming from other modern pro- been targeted on research into inheri- gramming paradigms, and many of the tance in the past years, it seems that alleged benefits of object-oriented pro- inheritance is still often inadequately gramming, such as improved conceptual understood.
    [Show full text]