DOCSLIB.ORG

Reflective Programming and Open Implementations

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Reflective Programming and Open Implementations Dr. Stéphane Ducasse [email protected] http://www.iam.unibe.ch/~ducasse/ University of Bern 2000/2001 i. Table of Contents 1. Reflective Programming and Open Implementations 1 Class as Objects 34 Goal of this Lecture 2 Some Class Properties 35 Outline of the Lecture 3 Some Method based Properties 36 What we could have made... 4 Metaclass Responsibilities 37 History,Concepts,Definitions and Examples 5 Outline 38 Why Do We Need Reflective Programming? 6 Why ObjVlisp? 39 Why Do We Need Reflective Programming? 7 The Loops Approach 40 Traditional vs Reflective Answers 8 The Smalltalk Pragmatical Approach 41 Role ot Reflective Prog in Software Engineering 9 ObjVlisp in 5 Postulates (i) 42 Definitions (I) 10 How to Stop Infinite Recursion? 43 Consequences 11 ObjVlisp in 5 Postulates (ii) 44 Meta Programming in Programming Language Context 12 Unification between Classes and Instances 45 Three Approaches 13 About the 6th ObjVlisp’s Postulate 46 Infinite Tower of (Meta)Interpreters 14 Instance Structure: Instance Variables 47 Reflective Languages 15 Instance Behavior: Methods 48 Open Implementation and MOPs 16 Minimal Structure of an Object 49 The Basic Claim of Open Implementation 17 Class as an Object: Structure 50 Meta Object Protocols 18 The class Class: a Reflective class 52 Meta Programming in CLOS 19 A Complete Example 53 Infinite Tower vs Open Implementation 20 Outline 54 A Simple Application as Example 21 Message Passing (i) 55 Programming in Explicit Metaclass Context 22 Message Passing (ii) 56 Reusing Meta Programs 23 Object Creation by Example 57 MetaProgramming in OO Context 24 Object Creation: the Method new 58 MetaProgramming by Example 25 Object Allocation 59 Costs of Reflective Programming 26 Object Initialization 60 Designing Reflective Systems 27 Object Creation: the Metaclass Role 61 Meta-Problems 28 Class Creation 62 Meta and Open are not Limited to Programming Languages 29 A Simple Instantiation Graph 63 2. The Study of a Minimal Object-Oriented Reflective Kernel 30 What is the minimal behavior shared by all the objects? 64 Goals of this Lecture 31 Outline 65 Outline 32 Two Forms of Inheritance 66 Recall: Meta Programming in Programming Language Context 33 Dynamic Method Inheritance 67 Table of Contents ii. A Simple Inheritance Graph 68 Derived Metaclasses in SOM 103 Method Lookup Example (i) 69 Limit of Derived Metaclass 104 Method Lookup Example (ii) 70 Class Property Propagation in SOM 105 Semantics of super 71 Smalltalk Approach 106 Let us be Absurb! 72 Deep into it: Smalltalk Metaclasses in 7 points 107 A Simple Uniform Kernel 73 Smalltalk Metaclasses in 7 points (iii) 109 Class initialization: a Two Steps Process 74 Smalltalk Metaclasses in 7 points (iv) 110 Recap: Class class 75 Responsibilities 111 Recap: Object class 76 Class Property Propagation in Smalltalk 112 Outline 77 NeoClasstalk: Compatibility Model 113 Bootstrapping the Kernel 78 Compatibility? Yes! 114 Abstract Classes 79 Refactoring the Smalltalk Boolean Hierarchy 115 Abstract 80 The Complete Architecture 116 Abstract Class and Method Lookup 81 Class Property Composition 117 3. About Metaclass Composition 82 An Example of Class Property Composition 118 On the Road 83 Extending the Smalltalk Kernel with the Compatibility Model 119 Recap: A Simple Uniform Kernel 84 NeoClasstalk Programmers 120 Recap: Method Lookup 85 Summary 121 Sets 86 If You Really Want to Know More 122 The Metaclass Set 87 4. Open Implementation: the CLOS MOP Example 123 Sharing Metaclasses 88 Goals of this Lecture 124 Zooming in: Creation of Memo-Point (i) 89 CLOS 125 Zooming in: Creation of Memo-Point (ii) 90 CLOS in a nutshell 126 On the Road 91 Class Definition 127 Problems with Explicit Metaclass Programming 92 Instance Creation 128 Interlevel Calls -> Interlevel Coupling 93 Encapsulation and Attribute Accesses 129 Relevance of The Problem 94 Inheritance 130 Upward Compatibility 95 Multiple Inheritance Conflict Resolution 131 Upward Compatibility Definition 96 Generic Function 132 Downward Compatibility 97 Method Definition (i) 133 Downward Compatibility Definition 98 (Method) Generic Function Application 134 On the Road 99 Method Selection 135 ObjVlisp 100 Why CLOS MOP? 136 CLOS 101 Meta Programming in CLOS 137 SOM 102 CLOS was too big! 138 Table of Contents iii. 5 MetaObjects 139 Controling What Exactly! 176 Static Elements 140 A Limited Survey 177 Structure Protocols (i) 141 CLOS Example (i) 178 Structure Protocols (ii) 142 CLOS Example (ii) 179 Extension Example 143 CLOS Example (iii) 180 Dynamic Elements 144 A Coverage Tool in Smalltalk 181 Class Definition: Defclass 145 Smalltalk: Do It Yourself Syndrome 183 Instance creation 146 Smalltalk Basic Reflective Tools 184 Method Creation: Defmethod (i) 147 6 Techniques 185 Defmethod (ii) 148 Unknown Messages 186 Method lookup and apply protocol 149 Creating a MinimalObject 187 Apply Protocol Example 150 Wrapping anObject 188 Slot Access Protocol 152 Evaluation 189 Finalize Inheritance 153 Method Wrappers: an Example 190 Open Implementation and Reflective Languages 154 Method Wrappers 191 5. Open Implementation Design Issues 155 Control 192 Goals of this Lecture 156 MethodWrapper Optimization 193 Locality in MOP Design 157 MW method body 194 Open Implementation Design Guidelines 158 Quality in interface designs 159 Installation 195 Set Module: Design A 160 MW Evaluation 196 Set Module: Design B 161 Exploiting VM Lookup Algorithm 197 First Guideline 162 Let’s view it 198 Second Guideline 163 Interceptor: Anonymous Classes 199 Third Guideline 164 Let us think a bit 200 Subject Matter 165 Essential Methods 201 Fourth Guideline 166 Naive Control Implementation (i) 202 Design D 167 Naive Control Implementation (ii) 203 Last Guideline: Layered Interfaces 168 Naive Control Implementation (iii) 204 6. Comparing Reflection in CLOS, Smalltalk and Java 169 Possible Optimization 205 Sorry but this is your work! 170 Evaluation 206 Some Criterias 171 Why A Mop for Smalltalk is Needed? 207 7. Implementing Message Passing Control in Smalltalk: an Analysis 173 Pratice! 208 Outline 174 Selected Bibliography 209 Why Controling Message? 175 Web pages 213 Reflective Programming 1. 1. Reflective Programming and Open Implementations Dr. Stéphane Ducasse Software Composition Group University of Bern Switzerland Winter Semester 2000-2001 Email: [email protected] Url: http://www.iam.unibe.ch/~ducasse/ © Dr. Ducasse Stéphane -Universität Bern Reflective Programming and Open Implementations Reflective Programming 2. Goal of this Lecture You will learn about ❑ Open Implementations ❑ Reflection: Intercession and Introspection ❑ Reflective Architectures and Kernels (SOM, Smalltalk, CLOS) ❑ Meta Object Protocol: Powering End-Users ❑ Metaclasses ❑ Message Passing Control Side Effects ❑ Program with a reflective system ❑ Let you implement your own micro kernel ❑ Deeply understanding OO ❑ Experiment with different OO models © Dr. Ducasse Stéphane -Universität Bern Reflective Programming and Open Implementations Reflective Programming 3. Outline of the Lecture ❑ (C) Introduction, Concepts, Definitions, Examples, Meta Object Protocol, Open Implementations ❑ (C) The Study of an Object-Oriented Reflective Kernel (ObjVLisp) ❑ (Lab) ObjVLisp Implementation (1) ❑ (Lab) ObjVLisp Implementation (2) ❑ (C) Metaclass Composition Issues ❑ (Lab) Metaclass Programming with ObjVlisp ❑ ❑ (C) Analysing CLOS and its MOP ❑ You : (C) Reflection in OO Languages (Clos, Smalltalk, Java Comparison) ❑ (Lab) Interface Browser ❑ (C) Message Passing Control in Smalltalk ❑ (Lab) Implementing Actalk ❑ You : (C) Presentation of papers ❑ (Lab) Scaffolding Patterns © Dr. Ducasse Stéphane -Universität Bern Reflective Programming and Open Implementations Reflective Programming 4. What we could have made... ❑ MetaCircularity and Infinite Tower: Lisp in Lisp ❑ Different reflective paradigm (relational, actors...) ☞ We will focus on OO reflective programming © Dr. Ducasse Stéphane -Universität Bern Reflective Programming and Open Implementations Reflective Programming 5. History,Concepts,Definitions and Examples © Dr. Ducasse Stéphane -Universität Bern Reflective Programming and Open Implementations Reflective Programming 6. Why Do We Need Reflective Programming? >Does anyone know why CLOS does not provide a copy protocol? >Has anybody implemented an inheritance method “a la Eiffel”? >We need a method dispatch that take into account an external context of execution? [Tutorial MOP & OI OOPSLA’93] Some problems: ❑ data structure allocation, optimization ❑ control of language entities (feedback, trace, analysis...) ❑ UI and API definition ❑ language semantics In summary ❑ Optimization ❑ Language extensions (control, debugging) ❑ Semantics change © Dr. Ducasse Stéphane -Universität Bern Reflective Programming and Open Implementations Reflective Programming 7. Why Do We Need Reflective Programming? “As a programming language becomes higher and higher level, its implementation in terms of underlying machine involves more and more tradeoffs, on the part of the implementor, about what cases to optimize at the expense of waht other cases.... the ability to cleanly integrate something outside of the language’s scope becomes more and more limited” [Kiczales’92a] ❑ Why instances do have to have the same internal representation? – for Point => maximum speed needed, all instance variables used ☞ array like representation – for Person => minimize space, few instances used ☞ hash-table like representation ❑ Why can’t I control internal representation
Recommended publications
  • Objects and Classes in Python Documentation Release 0.1

    Objects and Classes in Python Documentation Release 0.1

    Objects and classes in Python Documentation Release 0.1 Jonathan Fine Sep 27, 2017 Contents 1 Decorators 2 1.1 The decorator syntax.........................................2 1.2 Bound methods............................................3 1.3 staticmethod() .........................................3 1.4 classmethod() ..........................................3 1.5 The call() decorator.......................................4 1.6 Nesting decorators..........................................4 1.7 Class decorators before Python 2.6.................................5 2 Constructing classes 6 2.1 The empty class...........................................6 3 dict_from_class() 8 3.1 The __dict__ of the empty class...................................8 3.2 Is the doc-string part of the body?..................................9 3.3 Definition of dict_from_class() ...............................9 4 property_from_class() 10 4.1 About properties........................................... 10 4.2 Definition of property_from_class() ............................ 11 4.3 Using property_from_class() ................................ 11 4.4 Unwanted keys............................................ 11 5 Deconstructing classes 13 6 type(name, bases, dict) 14 6.1 Constructing the empty class..................................... 14 6.2 Constructing any class........................................ 15 6.3 Specifying __doc__, __name__ and __module__.......................... 15 7 Subclassing int 16 7.1 Mutable and immutable types.................................... 16 7.2
  • An Introduction to Linux IPC

    An Introduction to Linux IPC

    An introduction to Linux IPC Michael Kerrisk © 2013 linux.conf.au 2013 http://man7.org/ Canberra, Australia [email protected] 2013-01-30 http://lwn.net/ [email protected] man7 .org 1 Goal ● Limited time! ● Get a flavor of main IPC methods man7 .org 2 Me ● Programming on UNIX & Linux since 1987 ● Linux man-pages maintainer ● http://www.kernel.org/doc/man-pages/ ● Kernel + glibc API ● Author of: Further info: http://man7.org/tlpi/ man7 .org 3 You ● Can read a bit of C ● Have a passing familiarity with common syscalls ● fork(), open(), read(), write() man7 .org 4 There’s a lot of IPC ● Pipes ● Shared memory mappings ● FIFOs ● File vs Anonymous ● Cross-memory attach ● Pseudoterminals ● proc_vm_readv() / proc_vm_writev() ● Sockets ● Signals ● Stream vs Datagram (vs Seq. packet) ● Standard, Realtime ● UNIX vs Internet domain ● Eventfd ● POSIX message queues ● Futexes ● POSIX shared memory ● Record locks ● ● POSIX semaphores File locks ● ● Named, Unnamed Mutexes ● System V message queues ● Condition variables ● System V shared memory ● Barriers ● ● System V semaphores Read-write locks man7 .org 5 It helps to classify ● Pipes ● Shared memory mappings ● FIFOs ● File vs Anonymous ● Cross-memory attach ● Pseudoterminals ● proc_vm_readv() / proc_vm_writev() ● Sockets ● Signals ● Stream vs Datagram (vs Seq. packet) ● Standard, Realtime ● UNIX vs Internet domain ● Eventfd ● POSIX message queues ● Futexes ● POSIX shared memory ● Record locks ● ● POSIX semaphores File locks ● ● Named, Unnamed Mutexes ● System V message queues ● Condition variables ● System V shared memory ● Barriers ● ● System V semaphores Read-write locks man7 .org 6 It helps to classify ● Pipes ● Shared memory mappings ● FIFOs ● File vs Anonymous ● Cross-memoryn attach ● Pseudoterminals tio a ● proc_vm_readv() / proc_vm_writev() ● Sockets ic n ● Signals ● Stream vs Datagram (vs uSeq.
  • Multithreading Design Patterns and Thread-Safe Data Structures

    Multithreading Design Patterns and Thread-Safe Data Structures

    Lecture 12: Multithreading Design Patterns and Thread-Safe Data Structures Principles of Computer Systems Autumn 2019 Stanford University Computer Science Department Lecturer: Chris Gregg Philip Levis PDF of this presentation 1 Review from Last Week We now have three distinct ways to coordinate between threads: mutex: mutual exclusion (lock), used to enforce critical sections and atomicity condition_variable: way for threads to coordinate and signal when a variable has changed (integrates a lock for the variable) semaphore: a generalization of a lock, where there can be n threads operating in parallel (a lock is a semaphore with n=1) 2 Mutual Exclusion (mutex) A mutex is a simple lock that is shared between threads, used to protect critical regions of code or shared data structures. mutex m; mutex.lock() mutex.unlock() A mutex is often called a lock: the terms are mostly interchangeable When a thread attempts to lock a mutex: Currently unlocked: the thread takes the lock, and continues executing Currently locked: the thread blocks until the lock is released by the current lock- holder, at which point it attempts to take the lock again (and could compete with other waiting threads). Only the current lock-holder is allowed to unlock a mutex Deadlock can occur when threads form a circular wait on mutexes (e.g. dining philosophers) Places we've seen an operating system use mutexes for us: All file system operation (what if two programs try to write at the same time? create the same file?) Process table (what if two programs call fork() at the same time?) 3 lock_guard<mutex> The lock_guard<mutex> is very simple: it obtains the lock in its constructor, and releases the lock in its destructor.
  • Csci 658-01: Software Language Engineering Python 3 Reflexive

    Csci 658-01: Software Language Engineering Python 3 Reflexive

    CSci 658-01: Software Language Engineering Python 3 Reflexive Metaprogramming Chapter 3 H. Conrad Cunningham 4 May 2018 Contents 3 Decorators and Metaclasses 2 3.1 Basic Function-Level Debugging . .2 3.1.1 Motivating example . .2 3.1.2 Abstraction Principle, staying DRY . .3 3.1.3 Function decorators . .3 3.1.4 Constructing a debug decorator . .4 3.1.5 Using the debug decorator . .6 3.1.6 Case study review . .7 3.1.7 Variations . .7 3.1.7.1 Logging . .7 3.1.7.2 Optional disable . .8 3.2 Extended Function-Level Debugging . .8 3.2.1 Motivating example . .8 3.2.2 Decorators with arguments . .9 3.2.3 Prefix decorator . .9 3.2.4 Reformulated prefix decorator . 10 3.3 Class-Level Debugging . 12 3.3.1 Motivating example . 12 3.3.2 Class-level debugger . 12 3.3.3 Variation: Attribute access debugging . 14 3.4 Class Hierarchy Debugging . 16 3.4.1 Motivating example . 16 3.4.2 Review of objects and types . 17 3.4.3 Class definition process . 18 3.4.4 Changing the metaclass . 20 3.4.5 Debugging using a metaclass . 21 3.4.6 Why metaclasses? . 22 3.5 Chapter Summary . 23 1 3.6 Exercises . 23 3.7 Acknowledgements . 23 3.8 References . 24 3.9 Terms and Concepts . 24 Copyright (C) 2018, H. Conrad Cunningham Professor of Computer and Information Science University of Mississippi 211 Weir Hall P.O. Box 1848 University, MS 38677 (662) 915-5358 Note: This chapter adapts David Beazley’s debugly example presentation from his Python 3 Metaprogramming tutorial at PyCon’2013 [Beazley 2013a].
  • The Use of UML for Software Requirements Expression and Management

    The Use of UML for Software Requirements Expression and Management

    The Use of UML for Software Requirements Expression and Management Alex Murray Ken Clark Jet Propulsion Laboratory Jet Propulsion Laboratory California Institute of Technology California Institute of Technology Pasadena, CA 91109 Pasadena, CA 91109 818-354-0111 818-393-6258 [email protected] [email protected] Abstract— It is common practice to write English-language 1. INTRODUCTION ”shall” statements to embody detailed software requirements in aerospace software applications. This paper explores the This work is being performed as part of the engineering of use of the UML language as a replacement for the English the flight software for the Laser Ranging Interferometer (LRI) language for this purpose. Among the advantages offered by the of the Gravity Recovery and Climate Experiment (GRACE) Unified Modeling Language (UML) is a high degree of clarity Follow-On (F-O) mission. However, rather than use the real and precision in the expression of domain concepts as well as project’s model to illustrate our approach in this paper, we architecture and design. Can this quality of UML be exploited have developed a separate, ”toy” model for use here, because for the definition of software requirements? this makes it easier to avoid getting bogged down in project details, and instead to focus on the technical approach to While expressing logical behavior, interface characteristics, requirements expression and management that is the subject timeliness constraints, and other constraints on software using UML is commonly done and relatively straight-forward, achiev- of this paper. ing the additional aspects of the expression and management of software requirements that stakeholders expect, especially There is one exception to this choice: we will describe our traceability, is far less so.
  • Metaclasses: Generative C++

    Metaclasses: Generative C++

    Metaclasses: Generative C++ Document Number: P0707 R3 Date: 2018-02-11 Reply-to: Herb Sutter ([email protected]) Audience: SG7, EWG Contents 1 Overview .............................................................................................................................................................2 2 Language: Metaclasses .......................................................................................................................................7 3 Library: Example metaclasses .......................................................................................................................... 18 4 Applying metaclasses: Qt moc and C++/WinRT .............................................................................................. 35 5 Alternatives for sourcedefinition transform syntax .................................................................................... 41 6 Alternatives for applying the transform .......................................................................................................... 43 7 FAQs ................................................................................................................................................................. 46 8 Revision history ............................................................................................................................................... 51 Major changes in R3: Switched to function-style declaration syntax per SG7 direction in Albuquerque (old: $class M new: constexpr void M(meta::type target,
  • Semaphores Semaphores (Basic) Semaphore General Vs. Binary

    Semaphores Semaphores (Basic) Semaphore General Vs. Binary

    Concurrent Programming (RIO) 20.1.2012 Lesson 6 Synchronization with HW support • Disable interrupts – Good for short time wait, not good for long time wait – Not good for multiprocessors Semaphores • Interrupts are disabled only in the processor used • Test-and-set instruction (etc) Ch 6 [BenA 06] – Good for short time wait, not good for long time wait – Nor so good in single processor system • May reserve CPU, which is needed by the process holding the lock – Waiting is usually “busy wait” in a loop Semaphores • Good for mutex, not so good for general synchronization – E.g., “wait until process P34 has reached point X” Producer-Consumer Problem – No support for long time wait (in suspended state) Semaphores in C--, Java, • Barrier wait in HW in some multicore architectures – Stop execution until all cores reached barrier_waitinstruction Linux, Minix – No busy wait, because execution pipeline just stops – Not to be confused with barrier_wait thread operation 20.1.2012 Copyright Teemu Kerola 2012 1 20.1.2012 Copyright Teemu Kerola 2012 2 Semaphores (Basic) Semaphore semaphore S public create initial value integer value semafori public P(S) S.value private S.V Edsger W. Dijkstra V(S) http://en.wikipedia.org/wiki/THE_operating_system public private S.list S.L • Dijkstra, 1965, THE operating system queue of waiting processes • Protected variable, abstract data type (object) • P(S) WAIT(S), Down(S) – Allows for concurrency solutions if used properly – If value > 0, deduct 1 and proceed • Atomic operations – o/w, wait suspended in list (queue?) until released – Create (SemaName, InitValue) – P, down, wait, take, pend, • V(S) SIGNAL(S), Up(S) passeren, proberen, try, prolaad, try to decrease – If someone in queue, release one (first?) of them – V, up, signal, release, post, – o/w, increase value by one vrijgeven, verlagen, verhoog, increase 20.1.2012 Copyright Teemu Kerola 2012 3 20.1.2012 Copyright Teemu Kerola 2012 4 General vs.
  • CSC 553 Operating Systems Multiple Processes

    CSC 553 Operating Systems Multiple Processes

    CSC 553 Operating Systems Lecture 4 - Concurrency: Mutual Exclusion and Synchronization Multiple Processes • Operating System design is concerned with the management of processes and threads: • Multiprogramming • Multiprocessing • Distributed Processing Concurrency Arises in Three Different Contexts: • Multiple Applications – invented to allow processing time to be shared among active applications • Structured Applications – extension of modular design and structured programming • Operating System Structure – OS themselves implemented as a set of processes or threads Key Terms Related to Concurrency Principles of Concurrency • Interleaving and overlapping • can be viewed as examples of concurrent processing • both present the same problems • Uniprocessor – the relative speed of execution of processes cannot be predicted • depends on activities of other processes • the way the OS handles interrupts • scheduling policies of the OS Difficulties of Concurrency • Sharing of global resources • Difficult for the OS to manage the allocation of resources optimally • Difficult to locate programming errors as results are not deterministic and reproducible Race Condition • Occurs when multiple processes or threads read and write data items • The final result depends on the order of execution – the “loser” of the race is the process that updates last and will determine the final value of the variable Operating System Concerns • Design and management issues raised by the existence of concurrency: • The OS must: – be able to keep track of various processes
  • Meta-Class Features for Large-Scale Object Categorization on a Budget

    Meta-Class Features for Large-Scale Object Categorization on a Budget

    Meta-Class Features for Large-Scale Object Categorization on a Budget Alessandro Bergamo Lorenzo Torresani Dartmouth College Hanover, NH, U.S.A. faleb, [email protected] Abstract cation accuracy over a predefined set of classes, and without consideration of the computational costs of the recognition. In this paper we introduce a novel image descriptor en- We believe that these two assumptions do not meet the abling accurate object categorization even with linear mod- requirements of modern applications of large-scale object els. Akin to the popular attribute descriptors, our feature categorization. For example, test-recognition efficiency is a vector comprises the outputs of a set of classifiers evaluated fundamental requirement to be able to scale object classi- on the image. However, unlike traditional attributes which fication to Web photo repositories, such as Flickr, which represent hand-selected object classes and predefined vi- are growing at rates of several millions new photos per sual properties, our features are learned automatically and day. Furthermore, while a fixed set of object classifiers can correspond to “abstract” categories, which we name meta- be used to annotate pictures with a set of predefined tags, classes. Each meta-class is a super-category obtained by the interactive nature of searching and browsing large im- grouping a set of object classes such that, collectively, they age collections calls for the ability to allow users to define are easy to distinguish from other sets of categories. By us- their own personal query categories to be recognized and ing “learnability” of the meta-classes as criterion for fea- retrieved from the database, ideally in real-time.
  • Attachment A

    Attachment A

    Board of Governors, State University System of Florida Request to Offer a New Degree Program (Please do not revise this proposal format without prior approval from Board staff) University of West Florida Fall 2018 University Submitting Proposal Proposed Implementation Term Hal Marcus College of Science and Engineering Computer Science Name of College(s) or School(s) Name of Department(s)/ Division(s) Bachelor of Science in Computer Computer Science Science Academic Specialty or Field Complete Name of Degree 11.0701 Proposed CIP Code The submission of this proposal constitutes a commitment by the university that, if the proposal is approved, the necessary financial resources and the criteria for establishing new programs have been met prior to the initiation of the program. Date Approved by the University Board of President Date Trustees Signature of Chair, Board of Date Provost and Senior Vice Date Trustees President Provide headcount (HC) and full-time equivalent (FTE) student estimates of majors for Years 1 through 5. HC and FTE estimates should be identical to those in Table 1 in Appendix A. Indicate the program costs for the first and the fifth years of implementation as shown in the appropriate columns in Table 2 in Appendix A. Calculate an Educational and General (E&G) cost per FTE for Years 1 and 5 (Total E&G divided by FTE). Projected Implementation Projected Program Costs Enrollment Timeframe (From Table 2) (From Table 1) E&G Contract E&G Auxiliary Total HC FTE Cost per & Grants Funds Funds Cost FTE Funds Year 1 150 96.87 3,241 313,960 0 0 313,960 Year 2 150 96.87 Year 3 160 103.33 Year 4 160 103.33 Year 5 170 109.79 3,426 376,087 0 0 376,087 1 Note: This outline and the questions pertaining to each section must be reproduced within the body of the proposal to ensure that all sections have been satisfactorily addressed.
  • The Circle Meta-Model

    The Circle Meta-Model

    Document:P2062R0 Revises: (original) Date: 01-11-2020 Audience: SG7 Authors: Wyatt Childers ([email protected]) ​ ​ Andrew Sutton ([email protected]) ​ ​ Faisal Vali ([email protected]) Daveed Vandevoorde ([email protected]) The Circle Meta-model Introduction During the November 2019 meeting in Belfast, some of the SG7 participants enthusiastically mentioned Circle1 as providing a more intuitive compile-time programming model and suggested that SG7 investigate overhauling the de-facto SG7 approach (P1240+P17332) to follow Circle's ​ ​ ​ general approach (to reflection and metaprogramming). This paper describes a framework for understanding metaprogramming systems and provides a high-level overview of some of Circle's main characteristics, contrasting them to P1240's ​ ​ approach augmented with an injection mechanism along the lines of P1717. ​ ​ While we appreciate some of Circle’s powerful capabilities, we also raise some concerns with its underlying model and provide arguments in support of P1240’s choices as being a more ​ ​ suitable fit for C++’s evolution. The Dimensions of Reflective Programming In P0633, we identified three “dimensions” of compile-time reflective metaprogramming: ​ ​ 1. Control: How are compile-time computations effected/interpreted? What are metaprograms? 2. Reflection: How are source constructs are made available as data for use in metaprograms? 3. Synthesis: How can “code” be generated from a programmatic representation? 1 https://www.circle-lang.org/ Circle is an impressive project: Sean Baxter developed a brand new ​ ​ C++17-like front end on top of LLVM, incorporating a variety of new compile-time capabilities that align closely with SG7's goals. For Sean’s motivations, see https://github.com/seanbaxter/circle/blob/master/examples/README.md#why-i-wrote-circle.
  • Comparative Studies of Programming Languages; Course Lecture Notes

    Comparative Studies of Programming Languages; Course Lecture Notes

    Comparative Studies of Programming Languages, COMP6411 Lecture Notes, Revision 1.9 Joey Paquet Serguei A. Mokhov (Eds.) August 5, 2010 arXiv:1007.2123v6 [cs.PL] 4 Aug 2010 2 Preface Lecture notes for the Comparative Studies of Programming Languages course, COMP6411, taught at the Department of Computer Science and Software Engineering, Faculty of Engineering and Computer Science, Concordia University, Montreal, QC, Canada. These notes include a compiled book of primarily related articles from the Wikipedia, the Free Encyclopedia [24], as well as Comparative Programming Languages book [7] and other resources, including our own. The original notes were compiled by Dr. Paquet [14] 3 4 Contents 1 Brief History and Genealogy of Programming Languages 7 1.1 Introduction . 7 1.1.1 Subreferences . 7 1.2 History . 7 1.2.1 Pre-computer era . 7 1.2.2 Subreferences . 8 1.2.3 Early computer era . 8 1.2.4 Subreferences . 8 1.2.5 Modern/Structured programming languages . 9 1.3 References . 19 2 Programming Paradigms 21 2.1 Introduction . 21 2.2 History . 21 2.2.1 Low-level: binary, assembly . 21 2.2.2 Procedural programming . 22 2.2.3 Object-oriented programming . 23 2.2.4 Declarative programming . 27 3 Program Evaluation 33 3.1 Program analysis and translation phases . 33 3.1.1 Front end . 33 3.1.2 Back end . 34 3.2 Compilation vs. interpretation . 34 3.2.1 Compilation . 34 3.2.2 Interpretation . 36 3.2.3 Subreferences . 37 3.3 Type System . 38 3.3.1 Type checking . 38 3.4 Memory management .