DOCSLIB.ORG

N O T I C E This Document Has Been Reproduced From

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
N O T I C E This Document Has Been Reproduced From N O T I C E THIS DOCUMENT HAS BEEN REPRODUCED FROM MICROFICHE. ALTHOUGH IT IS RECOGNIZED THAT CERTAIN PORTIONS ARE ILLEGIBLE, IT IS BEING RELEASED IN THE INTEREST OF MAKING AVAILABLE AS MUCH INFORMATION AS POSSIBLE to LABORATORY FOR MASSACHUSETTS INSTITUTE OF COMPUTER SCIENCE TECHNOLOGY MIT/LCS/TM-203 N81-29802 (N ASA -CR-11 64uo7) MALLISP LvII-N.;WNS 72 1; (tidssaci► usetts 111st. of Tech.) dC AJ4/M,F AU1 CSCL 09J (Inciab GI/u1 21171 MACLiSP EXTENSIONS Alan Bawden "Y Glenn S. Burke Carl W. Hoffman iR. r' D DEN'' R. 00 1 -N'O' I OW] '0 - Suly 1981 545 TECHNOLOGY SQUARE, CAMBRIDGE, MASSACI-1-JSETTS 02139 0 MIT/LCS/TM-203 MACLISP EXTENSIONS Alan Bawden Glenn S. Burke Carl W. Hoffman July 1981 Support for this research was provided in part by National Institutes of Health grant number 1 POI LM 03374-03 from the National Library of Medicine, the Advanced Research Projects Agency of the Department of Defense under Office of Naval Research contract numbers NG0014 -75-C- s 0661 and N00014-77-C-0641, the National Aeronautics and Spa e Administration under grant NSG 1323, the U.S. Department of Energy under grant ET- 78-C-02-4687, and the U.S. Air Force under Vp tCo'P(NAC`C fix= r49620-79-C-020. Madisp Extensions July 1981 Alan Bawden Glenn S. Barks Carl W. Hoffman This report describes research done at the laboratory for Computer Science of the Massachusetts Institute of Technology. Support for this research was, provided in part by National Institutes of Health grant number 1 P01 LM 03374-03 from the National Library of Medicine, the Advanced Research Projects Agency of the Dei; ^rtment of Defense under Office of Naval Research Contract numbers N00014.75-C-0661 and N000.14-77-C-0641, the National Aeronautics and Space Administration under grant NSG 1323, the U. S. Department of Energy under grant Vl'-78-C-02- 4687, and the U. S. Air Force under grant' F49620-79-C-020. MASSACHUSETTS INSTITUTE OF 'ITRCHNOLOGY LABORATORY FOIL COMPUTER SCIENCE CAM131U GF. MASSACIIUSFATS 02139 a Abstract This document describes a common subset of selected facilities available in Maclisp and its derivatives: Pi)P-10 and Muitics Maclisp, Lisp Machine Lisp (letalisp), and NIL. The object of this document is to aid people in writing code which can run compatibly in more than one of these environmeats. AcknowkfgeineNs Much of the documentation presented here is drawn from pre-existing sources and modified to be presentable in this context. The documentation on sharpsign is derived from that written by Richard S. Lamson as a Multics online help segment. The descriptions of backquote and defstruct are derived from existing online documentation. The documentation on format shares some portions with the Lisp Machine Manual; text has been exchanged in both directions. The description of defmacro also draws heavily on the existing documentation in the Lisp Machine Manual. 1'he lisp Machine Manual is authored by 'Daniel Weinreb and David Moon, and the format documentation therein was contributed to greatly by Guy Steele; they have all thus indirectly contributed a great deal to this paper, as have innumerable others who aided in the preparation of the Lisp Machine Manual. We would like to thank Joel Moscs for providing the motivation to bring Lisp up-to-date on Multics, and Peter Srolovits, under whose auspices this document was produced. Note Any comments, suggestions, or criticisms will be welcomed. Please send Arpa network mail to MACLISP-EX'I'T NSIONSGMIT-ML. Those not on the Arpanet may send U.S. mail to Glenn S. Burke Laboratory for Computer Science 545'I'echnology Square Cambridge, Mass. 02139 0 Copyright by the Massachusetts instiuite of 'Technology; Cambridge, Mass, 02139 All riots rewrved. Maclisp Extension% Table of Contents Table0^^^N^^ ~°N^^^»mmmm^Nm^^ of lLIntroduction , , ~ . .^ , , ^ ^ ^^^ ~ ^ ^ ^ ' ` ^ ' ^ ` ^ ` ^ ' ' ^ ` ^ ^ ^ ` ^ ' ` ' ^ ^ ^ ` ^ I 1 ^ 1 Compatibility ,^,' , , , ^ ... , . ,., , , , , ^ , , . ~ ° . ° .. ~. & 1 ^2 Conventions , , . ' ' ' ^ ^ ^ ^ ^ ' ^ , , ^ ' ^ , ^ . ^ . , ~ , . ^ , . ^ , , . - , ~ . & ]L Backquote , ,'. ~..^ ° , , .`.. ^ ^ ' ^ ^' ^ ^ ' ^ ' ' ^ ' ' ' ' ^ ' ^ ^ ' ' ^ ^' ' ^ ^ ^ 2 ]L Sharpsign , , ^ , . .. ^ . ^ . .^^ ^ ` ' ' ' ^^ ` ' ' ` ^ ~ ` ` ' ' ^ ' ^ ^ ' ' ^ ' ' ^ ' ` ° 5 4, E*tmmdedDeffin . .^ . , . ,'^ , ` , , . ' ' ^ ' . ^ ^ ^ ^ , ^ ' ^ ^ ^ ^ ' ' , , ^ ' ` ' ^ 8 5iI)wftmmnmN . , , .. .. , . - ,. ^ ^ ~ ,. ° . ~ , . , , . , . - . ~ . ^ . .mN &i Other Definition Facilities. , . ° " , . ^ , ^ ^ . , . ^ . ^ . , - . ^ . , . , , . ^13 7. SekE ^ ^ . , , . - . ^ . ^ ^ . , ^ ` ' ' ' ' ' ' ` ^ ^ ^ ' ` ° ` ` ` ^ ' ' ^ ^ ` ^ ^ ^ ^ ^ ` 15 0[ New Functions and Special Forms . , , . ^ ` ' , . ~ . , . , , . , , ^ . .17 8.8 Bit Hacking ° . ' - . , ° ^ ^ . ^ ~ . ^ , - . , . , . ,K7 8.8.1 Boolean Operations ^ . ^ . , . ^ . , . ' . , . , , . ^ . .17 8.1.2 Byte Manipulation . , ^ . ^ - . ^ . , . ^ . ' . ~ ^ . , , ,uw 8.1.3 Testing . , . , . , . , ^ . ^ . ^ ^ . , , . ' . - .&s 8.2 Predicates . , ^ . ' . ' ' ^ ~ . ' ^ ' ` ' ` ' ' ` ' ` ' ^ ' ` ' ^ - ^ ' ^ ^ ' ^ ^ ' -18 8.3 Lists , , . , , . ^ ' ' ^ ' . ' ' ' ` - ' ^ ' ' ' ' ^ ^ ' ' ^ ' ^ ' ^ ' ~ ' ' ' ' '»9 8.4 Vmrimblmm. ^ ~ . ^ . , ° ^ ^ ' . , . , , . ' . , , . , , ^ ^ . ^ . ^20 8.5 Flow wfControl , . ~ . ^ . , . ~ , . ^ . , , . .2X 0.5.1 Conditionals . , . , , . " , , . - , . ^ . , , . , . , . .2u 8.5.2 SeL—cdon . , . , . ' . ' . ' ^ . ^ ` ^ - ' ' ' ^ ^ ' ' ' ' ` ' ' ' ' ' ' ' - ^ ` '22 8,5L1^ Itmrmtiom. , ' . ^ . , . ^ ^ ^ . , . ^ ^ . ^ ~ . ^ . , . , . , . .23 8.5,4 Nmn'&oc*30xits ^ . , . , . , ' . ^ . ' ^ . , . , , , , . ^ ,2w 8,6 Miscellaneous . , ^ . , . , . , . ^ . , ^ ` ^ . ~ , ^ . ^ ^ . ^ . ^ ^ . 25 §L Delstruct. , ^ . ^ ^ . , , . - , , ' . , , . , ~ , . , . , . ° . .@6 9\1 Kntmwdu*Kior . , . ^ . , ,^, _ ^ . , , ^ ^ . , , , , . , , . _ . , . ,26 9.2 /kSimple F.xample , . , . , . , , . , . ^ . , . , ^ , , . , , . , , ^ ,26 9.3 Syntax of defstruct . , . ' , . , . ' . ' ^ ' ' ^ ' ` , - ' ' . - ' ' ^ ' ' ^ ` ` '27 9.4 Options tmdefstroCt. , . ' ~ ' ' ` ' ' ' ' ' ' ' ^ ' ' ° ` ^ ` ' ' ^ ` ` - ^ ` ^28 9,4.1^.^ pm, , . ' ^ . ^ . ' ^ ' ' ' ' ' ' ' ` ' ' ^ ^ ^ ` ' ^ ` ' ` ' ^ ^ 20, 9.4.2rm.2 mmnmt pto ^ . .. , . ' , . , . ^ . , ^ , , , . , , , . ^ , , , , , 30 9,4.3 mltmnmnt . ^ ^ . , ^ . ` . ^ . ^ . ^ . .3& 9*4 dm . , ^ . ' ' ' . ' ^ . ' ' ° ` ' ^ ' ' ' ' ^ ^ ^ ' ' ' ' ' ' ` ' ' ' ' ' ` - '»2 9*5 cmmc-narne . , ^ , . , . ^ , . ^ ^ ^ . ^ ^ . , . ,D3 9.4.6 include . ^ . ^ . , , . , ^ ^ . ^ . .DD 9,4.7 nammd. ^ . , . , . _ . , . ^ . ^ , . .35 ^49A.8 makc-array . ^ . , . , ' ' . ^ . , . ^ . ^ . .35 9,4.9 xfa'fumnctiom . ' , ^ ^ . _ . ^ ' ^ . .35 9.4,10^^ ofa'mmnmc. ' . , . ^ ^ . 36 9.4-11.11 r*tcrma-ptr, . ^ . ^ . ^ ^ ` . ' . ^ . 36 ` ^4 12 nnhm\. ^ . ` ` . ^ ^ . , ^ ^ ' ^ ^ ^ . .36 9.4.13 $hz.c-macro . , . .36 9,4.14 hidzd-offset . , . " . ` . ^ . , . ^ . ' . .3h 2l'J[1I/0\ ^ I'ablemf Contents Maclisp Extensions ^ 9.4.15 but-first. , . , , ^ . ^ . ° , ^ ' , , ^ ^ , , . , , , , , . , , . ^ ^ , . 37 9.4.16 ,^, ' . ^ ,^^^ ^ ^^ `'^ ^ ' ^ '^ ^ ^ `'' ^ ^^^^ °^^ ^^` 37 ^ 9A.17 ewal-when . , , , - ^ , . , . , ~ , , . ~ , ^ ~ ^ ' ^ ° ^ ^ ' ' ^ ^ - ` ` ^ ^ ` ^ ^ ` ^ 37 ^ 9.4.08 property ^ , ^ . , . ,` . ~ ^ . ^ . ^ , , . , ^ , , ^ , , , , , , , , , ^ , ° , , 38 ^ 9A_19 A Tv^^^^^^N^^^^^^^^. , ^ , ^ ^ , . ^ ^ ^ ` ^ , ^ ^ ^ ' " ` ` ' ^ ^ ^ ^ ^ ' ' 38 ' - ' ^ ^^^0Other Options . , , ^ . , ,.. ^ , , ^ ' ' ^ ^ , ^ ^ ` ` ^ ^ ~ ^ ' ^ ^ ° ' ^ ° ` ^^ r 9.5 ll_.pu-^F^^^. , , , . , , ° . ^ . , . , ° , . , . , . , , ~ , , , ~ . , ~ ~ ~ ` , ^ ' - ^ 38 9.6 ANoxt_-_-^-_ ~ . , _' , ^ . , . ^ . , , ^ , ` ^ . ' , ~ , ^ ' ' , ° ~ ^ ^ ` . ^ ^ ` 40 ^ 9JThe Structure - . , , . , ^ , . - ^ , . ^ ^ . ^ ^ . , , . ^ , , , ^ , 41 ^ 9j8 Bkmn$iommtodeKstrxct , . , , . , . , . , , , . ~ ° , ^ , ~ ~ . , . , , . , , , . , , 42 9,8.1 A Simple Example . , . , , , . , . , . - ^ , . , . , , ^ . , ^ ^ ^ ^ , , , ' ' ' 42 9.8.2 Syntax of . , . - . ^ , , , ^ ' ' ' . ` , ' ^ ' ~ . ' ^ ' ` ^ ^ ^ ^ 43 9.8.3 Options to , .'. , ~ . ^ . ^ ^ . ' , . ^ ^ ° ^ ^ ^ , ^ ' , ^ ^ ^ ^ 43 9.8.3.1 cons . , , . ~ . , . ~ . ' . , , . , - , , ^ ^ ^ . ^ ^ ^ ^ ^ ' . , , ^ ^ . ^ 43 9.8.3.2 ref . , . - , . , , . ° . ^ ^ ^ , ^ , ^ ^ . , ° . , . , ° . , . , , ° ^ , ^ 44 9.8.3.3 overhead , , . ^ . , , . , . , . , , . , , . , . ^ , . , ^ , ' ^ ^ ^ ^ ^ ^ ` , , ° 45 9.8.3.4 named , . , . , . , , , . , ^ , . , ~ . ^ ^ , ^ ^ . ^ , ^ , , ~ , . , , , , ~ 45 9.0.3.5 keywords , . , , . , . ~ , ^ ^ ` , ` ^ ^ ` ' - . ^ ' ^ ' ` , ` ^ ^ ` ` ` ^ . ^ ^ 45 10.Fortimwt. , - , , . , , . , . ° . , . ^ , . , ~ ^ ^ , , . ' ^ . ^ , ~ 47 10,1 The OperMors ^ , ^. , ^. ^, .. , ..,. ^ ° , ^ . ., , ^.~ ^ ,^ ^^ ^.~ ^^ . 40 20.2 Other Entries ^ . ... ,'. ^ . ,.^^. , . .,,^ ' , `^^ ^ ^^^~ .`^. .^ 54 10i3 Defining your own ,^ ' . ~ ° ,^ ' . ' ' ^^ '^ ^ ^ ' ' '^ ^ ' `'^ ` ^` ^ ' ^`' ^`^ 54 t0AU-ormmmkand Strings. , . , ° , . , , . , , , . , . ^ , . - , . , , ` ~ ^ ^ ~ ^ 57 8X. System Differences , . , . , . - . , . , . , . S8 11,1 PDP-10, ^ . ^ . , , ^ - , ^ , ^ ^ . ^ . ^ , . , ^ . , , . ^ . ^ , , , ~ ^ ^ . , 59 11.1.1 WhermTmF^dK^, . , . ... ... ^ .. ^ ,.^ . .. , ,, ' ., , 58 11. 1.2 '11fing«To Watch Out Fon. .,, ^ ' .. ... , . .., . ^ . ^ ,-., ^ . 59 1 .1.13 I^wnthenDocwmmentation. , . .. , ^ ^ . , . ^ , , . , . ~ . ^ . ^ , 59 13 .7,NNultics , . , , , ' ^ ^ ° ^ ' ^ , ' ` , ^ ' ' ^ ' ` , . ^ ^ ^ ^ ^ ' ^ ^ ^ ^ ^ ^ ^ ^ ' ^ , ' ' 59 1l^.&WNve^:^mF^dUk, . , . .. ^ .. , , , , . , , . ^ . , , - ^ 59 11 .2.2 'Ibing«'rw Watch Out For . ,,.. .`. ., ^ - ., ., . , ,.. ,,. ,. ~.,. 60 112.3 Fxmrt6cYDocumentation . , ^ . , , ^. ^ . ~ ,.
Load more

Recommended publications
  • A Brief Introduction to Aspect-Oriented Programming
    R R R A Brief Introduction to Aspect-Oriented Programming" R R Historical View Of Languages" R •# Procedural language" •# Functional language" •# Object-Oriented language" 1 R R Acknowledgements" R •# Zhenxiao Yang" •# Gregor Kiczales" •# Eclipse website for AspectJ (www.eclipse.org/aspectj) " R R Procedural Language" R •# Also termed imperative language" •# Describe" –#An explicit sequence of steps to follow to produce a result" •# Examples: Basic, Pascal, C, Fortran" 2 R R Functional Language" R •# Describe everything as a function (e.g., data, operations)" •# (+ 3 4); (add (prod 4 5) 3)" •# Examples" –# LISP, Scheme, ML, Haskell" R R Logical Language" R •# Also termed declarative language" •# Establish causal relationships between terms" –#Conclusion :- Conditions" –#Read as: If Conditions then Conclusion" •# Examples: Prolog, Parlog" 3 R R Object-Oriented Programming" R •# Describe " –#A set of user-defined objects " –#And communications among them to produce a (user-defined) result" •# Basic features" –#Encapsulation" –#Inheritance" –#Polymorphism " R R OOP (cont$d)" R •# Example languages" –#First OOP language: SIMULA-67 (1970)" –#Smalltalk, C++, Java" –#Many other:" •# Ada, Object Pascal, Objective C, DRAGOON, BETA, Emerald, POOL, Eiffel, Self, Oblog, ESP, POLKA, Loops, Perl, VB" •# Are OOP languages procedural? " 4 R R We Need More" R •# Major advantage of OOP" –# Modular structure" •# Potential problems with OOP" –# Issues distributed in different modules result in tangled code." –# Example: error logging, failure handling, performance
    [Show full text]
  • The Machine That Builds Itself: How the Strengths of Lisp Family
    Khomtchouk et al. OPINION NOTE The Machine that Builds Itself: How the Strengths of Lisp Family Languages Facilitate Building Complex and Flexible Bioinformatic Models Bohdan B. Khomtchouk1*, Edmund Weitz2 and Claes Wahlestedt1 *Correspondence: [email protected] Abstract 1Center for Therapeutic Innovation and Department of We address the need for expanding the presence of the Lisp family of Psychiatry and Behavioral programming languages in bioinformatics and computational biology research. Sciences, University of Miami Languages of this family, like Common Lisp, Scheme, or Clojure, facilitate the Miller School of Medicine, 1120 NW 14th ST, Miami, FL, USA creation of powerful and flexible software models that are required for complex 33136 and rapidly evolving domains like biology. We will point out several important key Full list of author information is features that distinguish languages of the Lisp family from other programming available at the end of the article languages and we will explain how these features can aid researchers in becoming more productive and creating better code. We will also show how these features make these languages ideal tools for artificial intelligence and machine learning applications. We will specifically stress the advantages of domain-specific languages (DSL): languages which are specialized to a particular area and thus not only facilitate easier research problem formulation, but also aid in the establishment of standards and best programming practices as applied to the specific research field at hand. DSLs are particularly easy to build in Common Lisp, the most comprehensive Lisp dialect, which is commonly referred to as the “programmable programming language.” We are convinced that Lisp grants programmers unprecedented power to build increasingly sophisticated artificial intelligence systems that may ultimately transform machine learning and AI research in bioinformatics and computational biology.
    [Show full text]
  • Continuation Join Points
    Continuation Join Points Yusuke Endoh, Hidehiko Masuhara, Akinori Yonezawa (University of Tokyo) 1 Background: Aspects are reusable in AspectJ (1) Example: A generic logging aspect can log user inputs in a CUI program by defining a pointcut Login Generic Logging id = readLine(); Aspect Main CUI Aspect cmd = readLine(); pointcut input(): call(readLine()) logging return value 2 Background: Aspects are reusable in AspectJ (2) Example: A generic logging aspect can also log environment variable by also defining a pointcut Q. Now, if we want to log environment variable (getEnv) …? Generic Logging Aspect A. Merely concretize an aspect additionally Env Aspect CUI Aspect pointcut input(): pointcut input(): Aspect reusability call(getEnv()) call(readLine()) 3 Problem: Aspects are not as reusable as expected Example: A generic logging aspect can NOT log inputs in a GUI program by defining a pointcut Login Generic Logging void onSubmit(id) Aspect { … } Main void onSubmit(cmd) GUI Aspect { … } pointcut Input(): call(onSubmit(Str)) logging arguments 4 Why can’t we reuse the aspect? Timing of advice execution depends on both advice modifiers and pointcuts Logging Aspect (inner) Generic Logging abstract pointcut: input(); Aspect after() returning(String s) : input() { Log.add(s); } unable to change to before 5 Workaround in AspectJ is awkward: overview Required changes for more reusable aspect: generic aspect (e.g., logging) two abstract pointcuts, two advice decls. and an auxiliary method concrete aspects two concrete pointcuts even if they are not needed 6 Workaround in AspectJ is awkward: how to define generic aspect Simple Logging Aspect 1. define two pointcuts abstract pointcut: inputAfter(); for before and after abstract pointcut: inputBefore(); after() returning(String s) : inputAfter() { log(s); } 2.
    [Show full text]
  • “An Introduction to Aspect Oriented Programming in E”
    “An Introduction to Aspect Oriented Programming in e” David Robinson [email protected] Rel_1.0: 21-JUNE-2006 Copyright © David Robinson 2006, all rights reserved 1 This white paper is based on the forthcoming book “What's so wrong with patching anyway? A pragmatic guide to using aspects and e”. Please contact [email protected] for more information. Rel_1.0: 21-JUNE-2006 2 Copyright © David Robinson 2006, all rights reserved Preface ______________________________________ 4 About Verilab__________________________________ 7 1 Introduction _______________________________ 8 2 What are aspects - part I? _____________________ 10 3 Why do I need aspects? What’s wrong with cross cutting concerns? ___________________________________ 16 4 Surely OOP doesn’t have any problems? ___________ 19 5 Why does AOP help?_________________________ 28 6 Theory vs. real life - what else is AOP good for? ______ 34 7 What are aspects - part II?_____________________ 40 Bibliography _________________________________ 45 Index ______________________________________ 48 Rel_1.0: 21-JUNE-2006 Copyright © David Robinson 2006, all rights reserved 3 Preface “But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub” Paul Graham 1 This paper is taken from a forthcoming book about Aspect Oriented Programming. Not just the academic stuff that you’ll read about elsewhere, although that’s useful, but the more pragmatic side of it as well.
    [Show full text]
  • Understanding AOP Through the Study of Interpreters
    Understanding AOP through the Study of Interpreters Robert E. Filman Research Institute for Advanced Computer Science NASA Ames Research Center, MS 269-2 Moffett Field, CA 94035 rfi[email protected] ABSTRACT mapping is of interest (e.g., variables vs. functions). The I return to the question of what distinguishes AOP lan- pseudo-code includes only enough detail to convey the ideas guages by considering how the interpreters of AOP lan- I’m trying to express. guages differ from conventional interpreters. Key elements for static transformation are seen to be redefinition of the Of course, a real implementation would need implementa- set and lookup operators in the interpretation of the lan- tions of the helper functions. In general, the helper functions guage. This analysis also yields a definition of crosscutting on environments—lookup, set, and extend—can be manip- in terms of interlacing of interpreter actions. ulated to create a large variety of different language fea- tures. The most straightforward implementation makes an environment a set of symbol–value pairs (a map from sym- 1. INTRODUCTION bols to values) joined to a pointer to a parent environment. I return to the question of what distinguishes AOP lan- Lookup finds the pair of the appropriate symbol, (perhaps guages from others [12, 14]. chaining through the parent environments in its search), re- turning its value; set finds the pair and changes its value A good way of understanding a programming language is by field; and extend builds a new map with some initial val- studying its interpreter [17]. This motif has been recently ues whose parent is the environment being extended.
    [Show full text]
  • Open Modules: Modular Reasoning About Advice
    Open Modules: Modular Reasoning about Advice Jonathan Aldrich December 2004 CMU-ISRI-04-141 Institute for Software Research International School of Computer Science Carnegie Mellon University 5000 Forbes Avenue Pittsburgh, PA 15213-3890 This technical report is an expanded version of a paper submitted for publication. It supercedes Carnegie Mellon University Technical Report CMU-ISRI-04-108, published in March 2004 and revised in July 2004. This work was supported in part by the High Dependability Computing Program from NASA Ames cooperative agreement NCC-2-1298, NSF grant CCR-0204047, and the Army Research Office grant number DAAD19-02-1-0389 entitled ”Perpetually Available and Secure Information Systems.” Abstract Advice is a mechanism used by advanced object-oriented and aspect-oriented programming languages to augment the behavior of methods in a program. Advice can help to make programs more modular by separating crosscutting concerns more effectively, but it also challenges existing ideas about modu- larity and separate development. We study this challenge using a new, simple formal model for advice as it appears in languages like AspectJ. We then add a module system designed to leave program functionality as open to extension through advice as possi- ble, while still enabling separate reasoning about the code within a module. Our system, Open Modules, can either be used directly to facilitate separate, component-based development, or can be viewed as a model of the features that certain AOP IDEs provide. We define a formal system for reasoning about the observational equivalence of programs under advice, which can be used to show that clients are unaffected by semantics-preserving changes to a module’s implementation.
    [Show full text]
  • Aspectj Intertype Declaration Example
    Aspectj Intertype Declaration Example Untangible and suspensive Hagen hobbling her dischargers enforced equally or mithridatise satisfactorily, is Tiebold microcosmical? Yule excorticated ill-advisedly if Euro-American Lazare patronised or dislocate. Creakiest Jean-Christophe sometimes diapers his clipper bluely and revitalized so voicelessly! Here is important to form composite pattern determines what i ended up a crosscutting actions taken into account aspectj intertype declaration example. This structure aspectj intertype declaration example also hold between core library dependencies and clean as well as long. Spring boot and data, specific explanation of oop, it is discussed in aop implementation can make it for more modular. This works by aspectj intertype declaration example declarative aspect! So one in joinpoints where singleton, which is performed aspectj intertype declaration example they were taken. You only the switch aspectj intertype declaration example. That is expressed but still confused, and class methods and straightforward to modular reasoning, although support method is necessary to work being a pointcut designators match join us. Based injection as shown in this, and ui layer and advice, after and after a good to subscribe to a variety of an api. What i do not identical will only this requires an example projects. Which aop aspectj intertype declaration example that stripe represents the join point executes unless an exception has finished, as a teacher from is pretty printer. Additional options aspectj intertype declaration example for full details about it will be maintained. The requirements with references to aspectj intertype declaration example is essential way that? Exactly bud the code runs depends on the kind to advice.
    [Show full text]
  • Aspect-Oriented Extensions to HEP Frameworks ¡ P
    Aspect-Oriented Extensions to HEP Frameworks ¡ P. Calafiura , C. E. Tull , LBNL, Berkeley, CA 94720, USA Abstract choose to use AspectC++[2], an aspect oriented extension to c++, modeled on the popular aspectJ language[3]. The In this paper we will discuss how Aspect-Oriented Pro- AspectC++ compiler, ac++, weaves aspect code into the gramming (AOP) can be used to implement and extend original c++ sources, and emits standard c++ with a struc- the functionality of HEP architectures in areas such as per- ture suitable for component-based software development. formance monitoring, constraint checking, debugging and ac++ is an open-source, actively developed and supported memory management. AOP is the latest evolution in the project which is near to its first production release1. line of technology for functional decomposition which in- cludes Structured Programming (SP) and Object-Oriented Programming (OOP). In AOP, an Aspect can contribute to Overview of ac++ syntax the implementation of a number of procedures and objects There are several excellent introductions to AOP and is used to capture a concern such as logging, memory concepts[4] and to AspectC++ in particular[5]. Here we allocation or thread synchronization that crosscuts multi- can only provide a quick overview of ac++ syntax, and in- ple modules and/or types. Since most HEP frameworks troduce its fundamental concepts: are currently implemented in c++, for our study we have ¤¦¥§¦©¦ used AspectC++, an extension to c++ that allows the use ¤¦¥¨§¦©¦ ¨ An captures a crosscutting concern. of AOP techniques without adversely affecting software Otherwise behaves very much like a c++ class, defining a performance.
    [Show full text]
  • Good Advice for Type-Directed Programming
    Good Advice for Type-directed Programming Aspect-oriented Programming and Extensible Generic Functions Geoffrey Washburn Stephanie Weirich University of Pennsylvania {geoffw,sweirich}@cis.upenn.edu ABSTRACT of type-directed combinators to “scrap” this boilerplate. For Type-directed programming is an important idiom for soft- example, L¨ammeland Peyton Jones’s Haskell library pro- ware design. In type-directed programming the behavior of vides a combinator called gmapQ that maps a query over programs is guided by the type structure of data. It makes an arbitrary value’s children returning a list of the results. it possible to implement many sorts of operations, such as Using gmapQ it becomes trivial to implement a type-directed serialization, traversals, and queries, only once and without function, gsize, to compute the size of an arbitrary value. needing to continually revise their implementation as new gsize :: Data a => a -> Int data types are defined. gsize x = 1 + sum (gmapQ gsize x) Type-directed programming is the basis for recent research into “scrapping” tedious boilerplate code that arises in func- However, this line of research focused on closed type- tional programming with algebraic data types. This research directed functions. Closed type-directed functions require has primarily focused on writing type-directed functions that that all cases be defined in advance. Consequently, if the are closed to extension. However, L¨ammel and Peyton Jones programmer wanted gsize to behave in a specialized fashion recently developed a technique for writing openly extensible for one of their data types, they would need to edit the type-directed functions in Haskell by making clever use of definition of gmapQ.
    [Show full text]
  • Obliviousness, Modular Reasoning, and the Behavioral Subtyping Analogy
    Obliviousness, Modular Reasoning, and the Behavioral Subtyping Analogy Curtis Clifton and Gary T. Leavens TR #03-15 December 2003 Keywords: aspect-oriented programming, modular reasoning, behavioral subtyping, obliviousness, AspectJ language, superimposition, adaptation. 2002 CR Categories: D.1.5 [Programming Techniques] Object-oriented programming — aspect-oriented programming; D.2.1 [Requirements/Specifications] Languages — JML; D.2.4 [Software/Program Verification] Programming by Con- tract; D.3.2 [Programming Languages] Language Classifications — object-oriented languages, Java, AspectJ; D.3.3 [Programming Languages] Language Constructs and Features — control structures, modules, packages, procedures, functions and subroutines, advice, spectators, assistants, aspects. Copyright c 2003, Curtis Clifton and Gary T. Leavens, All Rights Reserved. Department of Computer Science 226 Atanasoff Hall Iowa State University Ames, Iowa 50011-1040, USA Obliviousness, Modular Reasoning, and the Behavioral Subtyping Analogy Curtis Clifton and Gary T. Leavens1 Iowa State University, 226 Atanasoff Hall, Ames IA 50011, USA, {cclifton,leavens}@cs.iastate.edu, WWW home page: http://www.cs.iastate.edu/~{cclifton,leavens} Abstract. The obliviousness property of AspectJ-like languages con- flicts with the ability to reason about programs in a modular fashion. This can make debugging and maintenance difficult. In object-oriented programming, the discipline of behavioral subtyping allows one to reason about programs modularly, despite the oblivious na- ture of dynamic binding; however, it is not clear what discipline would help programmers in AspectJ-like languages obtain modular reasoning. Behavioral subtyping was born out of the stories programmers were telling in their object-oriented programs and how they reasoned about them. Programmers use AspectJ-like languages to tell what we call “su- perimposition” and “adaptation” stories.
    [Show full text]
  • Successful Lisp - Contents
    Successful Lisp - Contents Table of Contents ● About the Author ● About the Book ● Dedication ● Credits ● Copyright ● Acknowledgments ● Foreword ● Introduction 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 Appendix A ● Chapter 1 - Why Bother? Or: Objections Answered Chapter objective: Describe the most common objections to Lisp, and answer each with advice on state-of-the-art implementations and previews of what this book will explain. ❍ I looked at Lisp before, and didn't understand it. ❍ I can't see the program for the parentheses. ❍ Lisp is very slow compared to my favorite language. ❍ No one else writes programs in Lisp. ❍ Lisp doesn't let me use graphical interfaces. ❍ I can't call other people's code from Lisp. ❍ Lisp's garbage collector causes unpredictable pauses when my program runs. ❍ Lisp is a huge language. ❍ Lisp is only for artificial intelligence research. ❍ Lisp doesn't have any good programming tools. ❍ Lisp uses too much memory. ❍ Lisp uses too much disk space. ❍ I can't find a good Lisp compiler. ● Chapter 2 - Is this Book for Me? Chapter objective: Describe how this book will benefit the reader, with specific examples and references to chapter contents. ❍ The Professional Programmer http://psg.com/~dlamkins/sl/contents.html (1 of 13)11/3/2006 5:46:04 PM Successful Lisp - Contents ❍ The Student ❍ The Hobbyist ❍ The Former Lisp Acquaintance ❍ The Curious ● Chapter 3 - Essential Lisp in Twelve Lessons Chapter objective: Explain Lisp in its simplest form, without worrying about the special cases that can confuse beginners.
    [Show full text]
  • An AOP Extension for C++
    Workshop Aspects AspectC++: Olaf Spinczyk Daniel Lohmann Matthias Urban an AOP Extension for C++ ore and more software developers are The aspect Tracing modularises the implementa- On the CD: getting in touch with aspect-oriented tion of output operations, which are used to trace programming (AOP). By providing the the control flow of the program. Whenever the exe- The evaluation version M means to modularise the implementation of cross- cution of a function starts, the following aspect prints of the AspectC++ Add- in for VisualStudio.NET cutting concerns, it stands for more reusability, its name: and the open source less coupling between modules, and better separa- AspectC++ Develop- tion of concerns in general. Today, solid tool sup- #include <cstdio> ment Tools (ACDT) port for AOP is available, for instance, by JBoss for Eclipse, as well as // Control flow tracing example example listings are (JBoss AOP), BEA (AspectWerkz), and IBM (As- aspect Tracing { available on the ac- pectJ) and the AJDT for Eclipse. However, all // print the function name before execution starts companying CD. these products are based on the Java language. advice execution ("% ...::%(...)") : before () { For C and C++ developers, none of the key players std::printf ("in %s\n", JoinPoint::signature ()); offer AOP support – yet. } This article introduces AspectC++, which is an as- }; pect-oriented language extension for C++. A compil- er for AspectC++, which transforms the source code Even without fully understanding all the syntactical into ordinary C++ code, has been developed as elements shown here, some big advantages of AOP an open source project. The AspectC++ project be- should already be clear from the example.
    [Show full text]