ࡱ> Root Entry FzF FWordDocumentvObjectPool(@|F@|FSummaryInformation(   !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~CompObj fj CompObj&'()*+,-./056789ag@ObjInfoFGHIJKLMNOPUVWXY``VisioDocumenthijklmnopuvwxy  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJLPRVX\^bdgࡱ>  FVISIO 3.0 Drawing VISIO ShapesVisio.Drawing.39qࡱ>LSE/'ࡱ> ࡱ>  FMicrosoft Word Document MSWordDocWord.Document.69qࡱn      !"#$%&'()*+,-./0123456789:;<=>?@ABCDFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmqrstuvwxyz{|}~ therefore it may not be a waste of time to inventory the bad things even if they seem unavoidable. Time for an admission. While this paper is organized as a derivation of Intentional Programming (IP) from first principles, it must be obvious to anyone with practical scientific experience that the historical development of IP followed a heuristic, pragmatic and iterative path, and the present logic has been reverse engineered from the results of this development for pedagogical clarity. Indeed, the pedagogical purpose is only enhanced if the pretense were lifted and the list were taken to be a description, as well as a motivation for IP. The unassailable items will form the basis for IP and indicate the emphasis; the doubtful items will be all delegated back to the users for routine resolution, and the terrible things will all find solutions. So let us complete the lists. First the unassailables. The list is rather short: The purpose of a language is to encode the programmers contributions: The reasons for making this obvious fact explicit is that the list of essentials is so short that we may be in the danger of losing track of the baby in the bath water. This statement just says what the baby is. The program is, or should be, simply a representation of what only the programmer could have known; nothing more, nothing less. Abstraction mechanisms: The act of abstraction is the obtainment of the general in favor of the specific. Our human civilization rests on the power of abstraction insofar as the volume of specific cases handled by an abstraction is typically much greater than the overhead of the abstraction mechanism itself. This is especially true in software so the ability to abstract is key to any encoding. Directness (simplicity) of expression: At some level, all parts of a program are specific: either they deal with specific facts or they describe a specific abstraction. Directness of expression just means that the units that the programmer thinks of as specific correspond closely to the units of encoding. Note that this is not the same as saying that the encoding be simple because there is no guarantee at all that the programmers thoughts (or the programmers problems) are simple. All that is required here is that the mapping between the two be straightforward. Accessibility of desired implementation (implementation efficiency): The programmers goals might well include a degree of performance which depends on a particular implementation method or the exploitation of operating system or hardware features. While this requirement is far from universal, in a competitive environment performance becomes a goal for most pieces of software. This rule basically says that there should be no incentive to go outside of the normal language framework (for example by descending to machine code) even if a specific implementation is desired In the best of possible worlds, there would be no conflict between abstraction and efficiency, indeed the best way to express a specific implementation would be by abstracting it into its computational intent. The notion of directness is also related to abstraction, in that if something is not done directly one should be able to abstract it to become direct. IPs intentions are such universal abstractions Next the doubtful ones. If you disagree with any of the points, please re-read the definition of the technical term doubtful above. IP in each case will focus on finding ways to delegate the choice to the user, not to try to propose new super-duper choices. IP will not solve the problems, but enable the user to make the easier, specific choice in the users domain. The precise methods for delegation will be described in the sequel. Simplicity of language: The word simple is sometimes used in software engineering as if it were a synonym for good when it is really value-free akin to, say, small. While the simplicity of expression of the solution is unassailable, the simplicity of the language itself is doubtful. The existing tension is between the language designers desire on one hand to keep the language simple in order to reduce learning and system implementation costs, and on the other, to try to optimize ease of programming in some domains and often to also consider the speed of execution. At one extreme of the simplicity scale is, of course, the fearsome Turing tarpit, where the speed of programming and object program execution both are brought to a virtual standstill due to simplicity of the language primitives. Syntax: Syntax has long been considered somewhat unimportant as the term syntactic sugar indicates. This term is used when there already exists some basic syntax which needs to be made more palatable for the user by the admission of the sweetener syntax, the syntactic sugar. But if, at the extreme, we consider the underlying syntax to be an abstract syntax tree, all other syntaxes become just sugar. IP takes this view. Users will directly manipulate the program tree while they view the program using an arbitrary and non-permanent syntax. Present day syntax had been predicated on a character stream that could have been input from punch cards, or teletypes. IPs syntax will allow arbitrary typographical or even graphical notations. Decades ago, Algol 60 has already expressed the longing toward clarity of notation when it defined a typographically rich publication language separate from the so-called reference and implementation languages. Types and type checking: The type system of a language is really a compile-time sublanguage, so the usual language issues, except for execution efficiency, will apply to types as well. The benefit of types comes mainly from type checking. Type sublanguages are not universal in the Turing sense, so there is no guarantee that some given type-like semantics of a class of quantities in the users program can be expressed at all. This is acceptable, because type checking is just a convenience, albeit an important one. There are two common forms of escape when the true type is not expressible: either an available superclass is used instead, or an explicit coercion is used to paper over the difficulty. An example for the former is when an integer type is used for a logical name, such as a window number. An example for the latter might come up if the window number can have its own type but this prevents it from participating in superclass integer operations, for example I/O. However there are numerous other cases where a typical modern type system is simply unable to express directly what the user wishes to create. IP will delegate the problem of exact type creation to the user by providing for universal computation in the type machinery at compile time. Other standards enforcement:The remarks on types are also applicable to instances where a language enforces or encourages some general software engineering discipline, such as goto-less programming, object oriented programming, use of interfaces, or modularization. In each of these cases a sublanguage exists and there is a potential tension between the users requirements, the expressiveness of the sub-language, and the escape mechanism. The latter effectively becomes the extension machinery in cases when the requirements and the sub-language do not match. Finally we have the list of terrible things which are taken for granted: Languages are not compatible with each other: For example, my system is in C, I can not combine it with Ada. Or, I cant use a nice feature of Ada in C, as I would use a foreign bon mot in normal English text. It is true that modules compiled from different languages can be often linked together, but this just shows that the difficulties are not necessarily caused by semantic incompatibility. For a permanent and maintainable combination, the declarations would have to be sharable and the code mixable. Languages are not compatible with themselves: For example, I share two independently developed modules in my C program. Unfortunately, both modules include a definition for a macro called X which cause a name collision. This is as if in real life if a John Smith worked for a company as an accountant, a second John Smith could not be hired as another accountant or even as a lawyer without inordinate repercussions, such as legally changing the name of one of the Smiths or replacing the first Smith. Languages are not compatible with a fixed point: For example, if the string desired by the operating system, proprietary software package, or efficient algorithm is not represented the same as in the language, a potentially costly and unreliable conversion has to be employed. In effect, the languages act as additional fixed points when they should be the accommodators. Computational intent and implementation details are intermingled. Consider, for example the intention of selecting a member m from a container c. There are a large number of implementation possibilities, as implied by the following access codes: c.m c->m c[m] m[c] c(m) m(c) (*c)[m] (c>>m)&1 etc. etc. Classes, inlining, and other abstraction machinery can hide implementation detail, but still leave the uniform reference at the declarations unresolved. What is the form of a class declaration for a container with a single boolean member (i.e. class c{ bool m;};) which could be implemented in any of the above ways? This is not a frivolous question because of the fixpoint problem, namely that there may be strong reasons elsewhere in the program under construction which support the fixing the implementation in a certain way. It may not be critical that any container should be smoothly re-implementable, for example as separate arrays for each member, indexed by container instance number (the m[c] example), but the issue is rather that given some such existing arrays, can we still consider them as containers? Saying that the already fixed implementation should be changed, or that the objects in question should not be considered containers under the circumstances ignores realistic boundary conditions on one hand and violates sound software engineering on the other. Progress in programming languages is limited, among other factors, by the small number of language designers. Many pieces of program text are not abstractable, or abstractable only in pre-processors. Examples in C are iterators, or repeated pieces of code in procedures which could be easily expressed as local procedures if such existed. Reliance on pre-processors creates a whole different set of problems in terms of naming, and the limited computing capabilities which are available. Meta-work (i.e. consistent rewriting of a program) is not expressible in languages even though it comprises a substantial part of programmers workload. Lisp is an exception in this regard, but only at the cost of failing most other tests for usability. Domain-specific knowledge can not be injected into the compilation process. Programmers are often given complete suzerainty over run-time, but their special knowledge of the abstractions, or of the rules of combining the abstractions, constant folding, initializations, and so on, would not be used at all by the compiler. Programmers are actually encouraged to make part of their contributions in the form of non-machine processable text (i.e. comments). Either this text is not very useful, and then we make fun of it; or it is useful, in which case we might well ask why the information (describing perhaps an invariant, a meta-work procedure, a type limitation, test information, etc.) is not in processable form. It is only a slight exaggeration to say that every good comment in a program represents a small failure of the language. (Cobol had a good idea in this regard: the Identification Division made machine processable at least a small fraction of the information programmers typically encode into comments.) Even overview comments describing program contents or structure are often derivable from underlying program structure. Many natural notations are not acceptable. For example, a2+2ab+b2 would be an unthinkable notation in current computer languages even though its meaning is clear. Notational freedom will become more important when programmers get a say in language design. Some mathematician who develops a great type system, compile-time optimizer and constant folder for matrices with special properties may well choose to use a traditional notation. In summary, we are seeking a system for encoding the programmers contributions in units that correspond to the programmers intentions, with arbitrary abstraction that does not incur run-time costs. Implementation detail should be separable from computational intent, and any implementation should be accessible for a given intention, including those matching any given fixed point. The issues of syntax, types, standards, and naming should be delegated to the programmers, but in a way that their contributions remain compatible even when different choices or tradeoffs are made by different programmers. In syntax, any notation should be acceptable. Arbitrary type calculus, meta-work, domain-specific compilation knowledge, and information traditionally kept in good comments should be expressible as part of the machine processable part of the program. But why talk about the death of languages? Would not any system satisfying these requirements be considered a language by definition? To be able to answer this question negatively, I have to rely on a metaphor from the realm of biology. You might have followed the incredible flowering of evolutionary biology that followed a shift in emphasis, originally proposed by Dr. Richard Dawkins, from the evolution of species to the evolution of genes. In this new view the genes occupy the center stage, they vie for survival by replication efficiency, while the individuals in a given species are survival machines which the genes have built so to speak in order to protect and replicate themselves. This new view helps connect a lot of additional biological phenomena with Darwinian theory of evolution. Unfortunately my task is not to convince you that this is great for biology (one can easily show that it is) but instead I would like to posit a parallel structure in the world of computer languages: languages are the species, which adapt to the users needs, while the specific features of the languages are the genes (or more precisely, information memes) that they carry. The whole lives in a nurturing and sometimes violent universe of language designers, language implementors and users. For example infix operator is a meme. Algol, Fortran, and C carry it, Lisp does not. Garbage collection is another meme: Lisp and Smalltalk carry it, Algol, Fortran and C do not. Other memes can be identified which distinguish the individual languages or language families, such as labelled common, fi, types and so on. IP represents a similar shift in emphasis from languages to memes of language features which we shall call intentions. Each intention carries the definition of its associated notation (syntax) and implementations (semantics) as attached methods. A program consists of a tree of nodes, each node being an instance of some intention. In this view the languages still exist but only as quasi-ephemeral conglomerations of memes. Languages would not be designed and they would not be named, hence they will die as identifiable artifacts. (Apropos names: the early history of programming languages has a famous example of a language which was really just a pragmatic collection of features, named by Mr. Jules Schwartz, a rebellious programmer, as JOVIALl that is Jules Own Version of the International Algorithmic Language. This was one small step toward the intentional world). One key property of intentions, as described in the sequel, is that they can coexist with each other syntactically and can be made to coexist semantically. This means that the existing legacy code of the users is no longer an albatross retarding innovation, but a valuable asset to which new services can be tied without limit. Once encoded in terms of intentions, software assumes an invariant immortal form, free from inherent obsolence. The fate of languages will roughly parallel the fate of dedicated word processors. For example, we can imagine having asked in 1974 the following question: word processing is a key need in myriad aspects of business and in everyday life so how realistic is it to talk about the death of Word Processors? In fact the question was debated at the time and many reasonable people took the conservative stance that the specialized and highly optimized and hence continually improving Word Processors will continue to be the best delivery vehicles for word processing solutions. As we know today, dedicated Word Processors have become dimestore curiosities if not completely extinct and peoples word processing needs are satisfied by an incredible range of software products which run on standardized commodity computing platforms, in other words PCs. In the parallel picture, IP will be the platform which can support a multiplicity of continuously evolving intention libraries. It is interesting to compare the eco-system of old-style dedicated Word Processor development with old-style language development. In each case mutation, hence improvement, was limited by the small number of manufacturers and language designers respectively. Stability was further ensured by direct dependence on the hardware box in case of word processing, and the dependence of legacy code on the languages. Were someone to create a new style of word processors, users would have had to buy a new hardware box; likewise a new style of language would have made it necessary that the users rewrite their legacy programs, a considerable obstacle to evolution in both instances. We can now observe the benefits of enabling evolution at least in the word processing case. Once the relatively expensive hardware box was made universal, the number of word processors skyrocketed and the quality and power of the products greatly increased. There emerged a small number of dominant word processing packages, but there are a myriad of niche products also. Moreover, the dominant products can remain on the top only by continually evolving and improving and they are orders of magnitudes better in every respect than their pre-evolutionary prototypes. Indeed, the major promise of IP may not be the fixing of a finite number of mundane problems, but the enabling of the larger scale evolution of programming technology. One factor that enables evolution is the delegation of many decisions to the user, which raises the question of whether the user could, or would take on this additional burden. In fact, the PC software industry has been built on a model where a relatively small segment of the user population specializes in the creation of solutions for the rest of the users, the end users, whenever a system is open to modifications. Even the small former segment, the solution providers, can number in the thousands, so it is much larger than the handful of gurus who used to control the means of abstraction. There is every hope that this model of the industry will be equally valid and valuable for programming technology also. The Source Tree So let us provide form to the thoughts. Without being overly pedantic, we should set the stage by admitting the obvious: programming systems exists because human programmers have ideas to contribute. So we place the programmer in the picture:  EMBED Visio.Drawing.3  IP maintains the contributions from several programmers who may be cooperating as a team, or the contributions can be loaded from separately acquired libraries. The contributions are in the form of a tree of nodes, called the IP Source Tree. At the time pictured here, the programmer is interacting with IP via a graphical user interface (GUI). The interface displays the source tree and facilitates its editing. A key element in programming is the forming of some intention in the programmers mind. By programmers intention we mean a desire that something be accomplished. Its emergence is best provoked by a direct question: What do you really intend here?. The possible answers may range from add these two numbers and remember the result, through call a specialized instance of procedure P transformed with respect to second and third parameters and partially inlined up to medium level; adapted to the present implementation of the first parameter, etc, etc.. To actualize the programmers abstract desire, specific nodes are created by the programmer in the source tree. The nodes are each identified as an instance of the particular primitive intention by a graph-like pointer to the declaration of the intention. The nodes also contain tree-like pointers to any number of arguments as shown in the following figure:  EMBED Visio.Drawing.3  Needless to say, the declarations, and the details of the intentions are themselves also intention instances and reside within the source tree, typically, but not always, in a standard library. Thus the programmers contributions form a tree of nodes. Some nodes, that is those pointed to by graph-like pointers, are declarations. Each node is identified as to its intention by the graph-like pointer. Each node can be embellished with arbitrary detail by hanging additional nodes below it. There is just one more small detail: nodes may also contain literal data stored as bits. So if the constant 2 needs to be stored in the tree, the bits are stored in the node and the graph-like pointer will define how the bits are to be interpreted ( that is, what data representation is used. There is no requirement that such nodes be terminal nodes in the tree. So far so good. One could say that the tree-like pointers are a little like S-expressions in Lisp, while the graph-like pointers define the object type in the object-oriented view. The source tree provides a solid substrate for representing arbitrary intentions in a modular fashion. Identification is unambiguous and invariant, via the graph-like pointers. Detail can be added at any point, without disturbing any other part of the tree. Defining Intentions What is missing? Just syntax and semantics, that is, looks and meaning. True to the program we set up earlier, we just invite the user (some user) to furnish the computation for: Imaging: to display an instance of the intention in some notation, and Reducing: to produce a particular implementation of the intention by performing an arbitrary program transformation on a copy of the source tree, until the copy tree contains only a limited set of primitive intentions from which machine code can be generated by the usual technologies. Once its data has been processed, the reduced tree will be immediately discarded. Continuing the biological metaphor, we call these methods Imaging, and Reduction Enzymes respectively. Their descriptions can be hung under the declaration of the intention they describe and they are called from the IP Kernel by special method calls. For example, when the user interface needs to show the image of the tree starting at some node N, the interface code will simply execute the image yourself method on the object N. The enzymes can be written in IP itself, and new intentions may be also used in the enzymes themselves. Is this circular? Of course it is, but standard bootstrapping methods can ensure that a working copy of the system is kept at any time while the new enzymes are debugged. How is this different from opening up the insides of a compiler, or having a retargetable compiler? First of all there is no parser there is only an arbitrary notation that the imaging enzymes produce. This means that the problems and limits of extending the notational space are merely that of comprehension and aesthetics and no longer technical in nature. Of course, this raises the issue of how the tree is input by the user, which will be treated in the next section. The second difference between IP and an open compiler is the particularly uniform and familiar way that the extensions are introduced. In this regard IP inherits the best property of Lisp: in both environments the programmer interacts essentially with the same structure as the programmers extension programs do. If anything, IPs tree is better optimized for representing programs, since it is not intended to serve as the main run-time data storage abstraction as Lisps S-expressions do. Completeness of Development Environment Integrated Development Environments (IDEs) are the cornerstones of modern software engineering. When one looks at Ada, C++ or Lisp IDE sales literature, the support of the IDE for the specific language is always emphasized. Of course what is being specifically supported is not the language per se, but some language features. In IP the system is divided into a shareable kernel IDE and the extended behaviors contributed by the intentions to each IDE component. These components are as follows: notation / display / pointing editor / user interface / browsing version control reduction / compilation /change propagation library system debugging profiling, testing (future) When a new intention is defined, the default methods for notation, editing, version control, library access, and debugging will do a decent job in any case. Even the semantic definition can be left to default to a simple procedure call semantics. Of course, a new intention can be made much more attractive to use as more and more of the methods in the various components are redefined to match the intention specifically. For example, a new type may come with its own routines to display values of the type in the debugger. Or, the editor can perform specific computation to propose default operands when an instance of the intention is created. It is worth noting that the development environment is also modeless insofar as the user perceives only one interface and editing of the source tree is always possible. There is no debugger, per se, there are only debugging-oriented commands. Setting a breakpoint or inserting a new statement, for example, are both accomplished using the same selection method for selecting the place where the breakpoint or new statement should go. The following figure illustrates the components and their interrelationships:  EMBED Visio.Drawing.3  Input Imaging enzymes can be quite arbitrary and they work in one direction only which raises the question of how the source tree is input. If we wanted to parse the input, the imaging computation would have to be invertible. The problem is avoided by denying the premise of a strict one-to-one connection between input and display. A not-entirely-frivolous argument is that the premise does not quite hold even with todays parsable languages. When programmers interact with the source, they use some text editor. For example, to enter the C program text fragment: if (alpha < 0) the programmer might have actually typed: if9^(alfa^^pha <= 0)^^^ where ^ denotes a backspace, cursor positioning, mouse click or delete. The point is that programs have been always expressed in terms of editor commands and this overlay has not been considered a burden by programmers. In IP intentions are input by direct manipulation of the tree. Various forms of selection are used to designate the operand or the place in the tree, and then the usual cut/copy/paste operations can be performed. Text typed in from the keyboard is tokenized and parsed by a very simple command processor. The tokens are presented to all declarations for recognition, and then the appropriate methods are executed on the declaration which matched the token. It is easy to arrange things so that typing if will result in the insertion of an if intention, and typing alpha will paste the reference to the declaration of alpha. The above example, if entered IP entirely from the keyboard with no errors would be: if_alpha<0_ where _ denotes a space. This is neither less efficient, nor radically different from what had to be done in the old paradigm. In a number of instances the departure of the input language from the image can be quite radical. For example, we found it convenient to type cast to enter a cast, or type proc to declare a new procedure, even though in the currently most popular imaging idiom, C, these appear as: (...)... , or ... ...() {} respectively, where ... indicates incomplete parts. Experience shows that the burden of having to remember the words cast or proc is not insufferable. Some users prefer to set up their keyboard interface instead so that CTRL-( can be used to enter a cast (no shift key is necessary). Again, we can look back at the development of WYSIWYG (what you see is what you get) word processing systems. To enter italic text by strict analogy to how plain text is typed, one would need an italic keyboard, or at least a lockable italics shift, just like the current Caps Lock key. This was not done, because it would not have been sufficient, as the number of character formatting options proliferated through thin, semibold and bold, ad infinitum; because of practical difficulties, and because there were other perfectly intentional ways of specifying italics though menus, toolbars, dialog boxes, or keyboard commands such as control-I. These input methods generally do not correspond to the image of the intention, but rather they have just a mnemonic connection with it. IP extends the same strategy to computer programming. It is worth noting that identifiers or names in IP are used only in interactions with the user. Furthermore, the use of names is not the only tool available to the user to designate identity - pointing to instances or specifying properties can be also used for identification. Once an object is identified, a link to the declaration is stored in the source tree as a graph-like pointer. This means that the name machinery can focus on optimizing communications with the programmer and be otherwise completely ignored by the semantic portion of the system. The problem of inputting legacy code written in legacy languages is quite separate. To do this, first the features of the language have to be defined in terms of IP declarations, and then a commercial parser for the language has to be modified to produce the source tree. There are some interesting complications which stem from the use of pre-processor directives in some languages. These are discussed in the sequel. Review of the Requirements With the enzymes in place, IP possesses, in addition to generality of representation, modularity and invariance, the following desired properties: Extensibility: the features of the system are determined by declarations which a user might provide. Notation: arbitrary notations may be used including those that are not parsable and ambiguous. Naming is extremely flexible. Arbitrary semantics and implementation flexibility: since the semantics are expressed in terms of program transformations. It is worth reviewing how IP helps with the terrible problems which were enumerated earlier: Languages compatible with each other: once read into IP with the appropriate legacy parser, the nodes are self identifying with respect to notation and semantics. Compatibility becomes a tractable issue of choosing or writing implementation methods for the language intentions which can work together. Even particularly obnoxious legacy constructs can be accommodated, for example, by providing a simple but inefficient implementation to bridge over the period during which instances of the construct are replaced by more robust abstractions. The benefit is that the system under development will remain testable while the abstractions are changed. It is also possible that the simple implementation will suffice in the first place. Name conflicts: since names are not used for identification, except only during initial input (including legacy code parsing) when there is ample opportunity to designate scope or otherwise disambiguate between different possibilities, name conflicts are impossible in IP. Names are still used to communicate with the user. If the user is confused by name ambiguity, there are many remedies which are guaranteed not to affect semantics. Browser commands are available to show the declarations, or the names can be changed in the declaration quickly and safely, with all references to the declaration updated in constant time. Computational intent and implementation detail: In IP the intent and the implementation detail can be separated. First, the intent can be expressed by creating a new intention declaration, or by hanging new attributes under an existing node. Next, the reduction transformation associated with the intention can be changed or widened to create the desired implementation. Abstraction: Any abstraction in IP can be implemented as an intention which does not reduce to R-code, but instead to different intentions which have to be reduced in turn. Any node in the tree can be replaced with an abstraction and formal operands can be added as required. Meta-work: This is just equivalent to program transformations which are in turn integral to the operation of the system. The IP editor provides a way to apply an enzyme (Editing Enzyme) to the source tree so that the results are permanent as if they were input by the programmer. Here are some examples of editing enzymes: Lift Abstraction: Changes selected code into a procedure. Depending on various options, the variables referenced may be made into formal parameters. The original copy may be replaced with an appropriate call to the new procedure. For example, by pointing at: A + 1 a procedure: PROC ???(A) A+1; is created and the original A+1 is replaced by ???(A). The unknown name ??? can be easily edited because single-point renaming is simple in IP. A variant of this enzyme can further parameterize a function. Select 1 in the procedure, and execute the enzyme. We get a new parameter and all calls will be edited, too. PROC add(A, ???) A+???; ........add(A, 1) (assuming that the procedure name has already been changed to add.) The enzyme can also create names automatically according to selected naming schemes. Change sequences of C #defines into C++ enums: for example #define A 0 #define B 1 would be replaced by: enum { A; B;} ...; Apply De-Morgans law, or other transforms to expressions: for example if (!a && b) would be transformed into: if (!(a || !b)) Domain-specific knowledge: type calculus, constant folding, and the basic node processing functions of the reducer are all extendible. Any information that makes intentional sense can be included in the source tree and appropriate processing for the information can be defined as methods in the intention declarations. Obvious Fears IP represent a substantial change from past practices. What are the possible downsides? What will happen to legacy code: IP deals very well with the legacy problem. Not only can it run legacy languages, but it is an excellent platform for re-engineering legacy code. Amateurs playing with syntax, causing confusion: In fact no permanent harm will come from using badly designed notations, just that interaction will be difficult while the notation is in effect. The programmer can return to a standard or commercial notation at any time without loss of data. Run time efficiency: Since IP uses commercial code-generator back ends, the quality of code for the usual level of abstraction should be unchanged. There is also the strong hope that by using domain specific optimizations and specialization, code efficiency can be improved. Editing efficiency: Direct manipulation of the source tree raises the specter of Syntax Directed Editors which have never become successful in large part because they were unpleasant to use. This issue will be discussed in the sequel. Efficiency of representation: measurements show that the source tree corresponding to a C legacy program is larger by a factor of 3 than the C source encoded as Ascii. However, raising the abstraction level and increasing code sharing can reduce the number of nodes in the program, so the factor of 3 should be thought as an upper limit. In addition, much of the extra bits in IP help browsing functions to the extent that some browsing databases become unnecessary. Capital costs: Unfortunately, text-based tools can not be used with IP, so change-control, source check-in, source level debugging and other important auxiliary systems have to be also re-implemented. The high capital costs of doing so might explain in part why such systems have not emerged earlier. On the positive side, the source-tree based approach, once implemented, can provide new functionality. For example a source control system now can have access not only to the history of edits that a user made, but also the semantics of the nodes which have been edited. The system can use this knowledge to merge changes made by different people, and to detect conflicts. Of course, end-users would not be noticeably affected by capital costs. New abstractions: are there useful ones? Only time will tell. Right now, there is a backlog of abstractions, such as partial evaluation, which have been used in research contexts only and which would have obvious uses when applied to everyday systems. In the rest of the paper well be discussing a number of abstractions which make program sharing easier. We should always remember that in the old world the cost of a new abstraction was very high: typically it meant that a new language would have to be used. Consequently, the benefits had to be also very high for the abstraction to make sense. Method calls prior to C++ could be cited as a rare abstraction which took root in Smalltalk and other languages. With IP, the decision to use a new abstraction can be completely routine, not unlike the decision to use a published algorithm or a library. The initial costs are low, and the cost of reversing the decision is also limited. In effect, the IP abstractions do not have to revolutionary to be useful. Complexity of writing enzymes: Here the bad memory is that of program generators which were difficult enough to construct that their use has not become widespread despite of their power and benefits. IP has two advantages over the earlier attempts: first, the tree is particularly easy to generate with programs - a cynic would say it is optimized for generation by programs rather than by programmers - and second, new intentions may be created for the common clichs used in enzyme writing. Notational Space The exciting fact about notations in IP is that it will be able to evolve over time, without loss of information. Two components cooperate to create the display of the source tree: The first component consists of the set of the imaging enzymes, which are created or collected by the user. There may be more than one image for each intention, and there will always be at least one default image. The user can select, say, C-view, directing the system to invoke the C enzymes when available. The second component is a built-in formatter which lays out the screen image, handles fonts, breaks long lines at the appropriate points, and maintains the information for decoding the users pointing actions. For the latter, the system has to maintain a data structure which can map a particular pixel on the display back to the tree node which is behind the pixel. This data structure is also used to trigger the recomputation of the image when the supporting node is edited. The interface between the components is a simple rich-text formatting language, not unlike a mini-TEX. There are no plans to make the output language extendible by the user other than by copious parameterization. Its current capabilities include fonts, font modes (bold, etc.), many underlines, overlines and strikethroughs, colors, and simple formula layout (matrices, integral forms, roots, fractions, etc.) More capabilities can be added to new versions of the system. Only the imaging enzymes contain knowledge of the imaging language; the source tree has none, with a specific exception which has to do with the programmers special formatting instructions. In IP, the choice of notation will be just a personal decision just as indentation and comments used to be. Arbitrary manual formatting with spaces and tabs is no longer possible: the choice of view determines not only what used to be the language that is C, Pascal or Cobol, but also the formatting conventions, such as the K&P style indentation: if (f) { i = 0; } or indentation with the brackets lined up: if (f) { i=0; } As the systems develop, these styles may include more heuristic rules to create for example: if (f) {i=0;} Any additional control of the formatting by the programmer will require cooperation by the imaging enzymes. A simple and useful trick is to introduce an intention for a blank line: if (f) { i=0; } The semantics of the blank line is just a noop, but it is displayed without the extra semicolon. If there are reasons for formatting the same intention in different ways, the intention must have a parameter expressing the choice. For example, a comment associated with a statement might appear in different positions: // comment 1 i=1; i=2; // comment 2 // comment 3 i=3; The choice between positions 1 and 2 is expressed in terms of an intentional property under the comment node: left vs. right comments. The special indention of choice 3 is expressed by associating a general formatting property on the comment node: outdent by so-and-so much. The main reason for worrying about these issues at all has to do with legacy code. The better job IP does of preserving the structure of the legacy code, which in the past had to be expressed as formatting and comments, the easier the re-engineering process will be for the programmers. The imaging language allows multiple fonts and the 16-bit Unicode character set becomes readily available. The constants in the source tree are self-identifying so they may or may not use Unicode or any other encoding. Since the source tree does not depend on names for identifying graph-like links, the only restriction on names in IP are those that the programmers choose for simplifying the input of new programs. It is possible to establish a link without using the name, just by direct pointing to the destination of the link: for example add 1 to the variable declared there click. Similarly the operation add, and in principle even the common constant 1 could be selected by clicking. However, some simple restrictions on the names make it possible to tokenize the keyboard input: J+1_ into Name token: J, Name token: +, Constant token: 1, which then can be arranged to have the desired effect, that is the creation of the source tree +(J, 1). But even this restriction for tokenizations does not necessarily mean that the names have to be restricted the same way. Lookup for input can be performed on the basis of partial matches. More importantly, declarations can have multiple names: link name which remains invariant even when the declaration is renamed normal, or short name used for input and for expert overview discursive, or long name, which could be used by programmers unfamiliar with the program foreign names, needed when several different natural languages are used in development Note that the lack of restrictions on names opens up the realistic possibility of programming in kanji and Chinese, not to mention the use of Greek, cyrillic and other alphabets. The notion of literate programming was introduced by Knuth so that parts of programs can be exposed in an order that helps the reader, for example in the order of stepwise refinement. IP is an obvious vehicle for implementing such displays in an interactive setting, where the same intentional structure could be displayed both in literate and in literal forms. Many other views are also possible: for example, one might want to group the objectmethod pairs by objects or by methods. The simplest variable view command, outlining, has already been implemented. Extension Machinery At the most abstract level, extension simply means that parts of the users code may be executed by IP. This means that parts of the users code are suitably identified as some extension of IP. There has to be a library of interface specifications which is exported by IP and to which the user extensions must conform. Extension code is then culled together and a dynalink library is created which can be used immediately by IP. Most, but not all, extensions are associated with intentions. These follow the object paradigm, as shown in the following figure:  EMBED Visio.Drawing.3  where the method names identify the aspect of the system that is extended by the intention, and the procedure is the contribution from the user which performs the extension. The dotted graph-like pointer indicates that an appropriate multiple inheritance scheme is provided. Instead of just following the graph-like pointer to the immediate declaration, the inheritance computation can generate a set of underlying intentions of which the node in question is an instance. For example, a node pointing to the declaration of an integer variable may inherit methods from the virtual intention simple variable and from the actual type integer. Effectively, the inheritance computation can classify nodes as representing several virtual intentions starting from, and in addition to, the one pointed to by the node. The root of the inheritance hierarchy is implemented entirely in the IP kernel. It describes the most common behaviors for intentions as the default. This means that an intention need not define all methods. For example, a procedure can use the existing call semantics by default but define its own imaging. Or, a new intention with new semantics can still use the default parenthesized functional notation as its imaging. The inheritance computation itself can be extended by come from hooks, described in the sequel. Clearly, extensions are only possible when there is some recognition by the creators of the IP kernel of the need for extension. Once this is achieved, the new method name is defined in an interface file. The default implementation for the method gets coded and the appropriate method calls get inserted into the IP kernel. Now the users can define new extension methods and this will not disturb the existing extensions. The fact that methods can be defined for behavior in all parts of an integrated development environment also distinguishes intentions from classes. Classes differ from each other only during execution of the program. They cannot be individually distinguished by any other part of an integrated system: the editor, version control, change dependency propagation, browser, or the debugger. Intention can define specifically appropriate behavior in all of these components. As suggested earlier, some desirable extensions may not be associated with any given intention, for example if a change in the inheritance mechanism is desired. Also, there are many issues raised by the modularization of the information necessary for extension. What if library (or user) A desires to add a method to an intention from a different library B? What if type T of an interface definition should be an opaque box for the user, but a detailed structure for the implementing routines in IP? Fortunately, IP is implemented in itself, so the required intention can be pragmatically defined and used to solve the problem. Editing Probably the least natural aspect of IP seems to be the requirement that the source tree be edited as a structure and not as text. Users have historically accepted direct manipulation for graphics, for example. However, when the source data is shown in terms of characters, the tradition has been to edit the source as it were a character stream. The syntax directed editors have come the closest to approximating the IP editing problem. In the syntax directed paradigm, the syntax rules are immediately applied to the users input, with two important results: first the input of illegal constructions is prevented at the outset; and second, as a result of parsing, the system has knowledge of what has been typed and this knowledge can be used in turn to help the user with prompts, automatic formatting, defaults and so on. Despite these advantages, syntax directed editing has never been a commercial success. One can only surmise the reasons for the users dislike of such systems, but one good guess is that a successful system should be modeless and intentional. Modelesssness means that work on one section of the code can be always suspended and the focus transferred to some other portion. Intentional here means that the editor commands should directly relate to the intentions rather than the representation of the intentions. Modelessness is important because programs are seldom constructed in a strict order. The programmer must be able to express code fragments whether or not they make sense in their intermediate forms. There should be no interruptions, demanding prompts, or beeps. IP does have two subtle forms of reminders: incomplete operands are typically highlighted in color, and there is also a To Do list with current references to all incomplete or otherwise incorrect code as discovered by a background type checker. After finishing some coding the programmer can simply scan the screen for highlights and then scan the todo list for any remaining errors. Of course, there will always be a few obscure errors which will be uncovered only during the reduction/compilation of the program. The editing model is based on the standard cut/copy/paste operations, but with about seven different selection types as opposed to the single text selection used by text editors. Just one of the selection types, for example, is necessary for selections within constants, names or comments which can all be edited as text. The other types select subtrees, lists of subtrees, individual nodes, places in lists, and left or right operands for operations. While this is quite a bit more complicated than basic word processing, the programmer users are well equipped and motivated to handle the conceptual load. Having a reliable and multi-step undo facility also help create a comfortable environment where the consequences of mistakes are very much limited and where experimentation is encouraged. Example for an Intention Let us consider the construction of a new intention for a dialog box, as in a user interface for a program. The intention is not a class: the class already expresses some data structure that is a particular implementation of dialog boxes. The intention is simply a repository of the users contribution. So the process of defining the intention starts with cataloguing the independent quantities, such as: size (width/height) title collection of items, for each type of item position title code to define default value code to call after value changed specific fields depending on type of item button: code to call when button is pressed radio buttons: collection of items, for each position title value to be returned when selected etc. etc. This process can be elaborated without limits. The quantities in the intention may be identified by labels or by positions. The quantities themselves may be constants, expressions, code, pointers to declarations, graphics or whatever is required by the problem: their presence does not commit to any particular form of processing or interpretation yet. If there are shared quantities, they should be placed in a declaration, and then the sharing is expressed by graph-like pointers to the declaration (for simplicity, the above list did not include sharing). Constants can be interpreted in the context of the intention. Some constants will be lengths, these can be encoded as discrete choices, taken from the analog length of a line segment, or as subtrees or character strings with units provided, for example 1 3/4 or 10cm. One nice thing about intentions is that they can be extended even when they are already in use. Of course, the order of parameters which were identified by position may not be disrupted, but labeled or subsidiary information can be attached to any node without disturbing the existing uses. In the most extreme cases, an editing enzyme could be supplied to perform the transformation necessary for an upgrade. Once the intention is formalized, the first implementation must be decided. This may be as simple as ignoring everything initially, or may use a sophisticated class-based library. In either case, the Reduction Enzymes have to be written. The implementation may be changed at any time. An Imaging Enzyme can be also written which can echo all contributions and perhaps also provide a preview of the dialog box. A more sophisticated implementation of the interface code in the future might provide tools to allow direct manipulation of the graphical items as well, so that the programmer could adjust the size parameters in the intention by dragging the borders of the preview. Failing any this, the intention could be still displayed and input in standard functional notation. Useful Abstractions The prediction is that IPs combination of expressive power and availability will give rise to an incredible burst of creativity from many corners. The purpose of the following examples is not to demonstrate unique creativity but to illustrate the degrees of freedom. Especially in the beginning, the plate will be full with grand old ideas which somehow have gotten stuck in some niche language such as Lisp, Smalltalk, or even BCPL. Just bringing these abstractions into general use will be a major undertaking with far reaching consequences. Valof. A short-lived feature of BCPL was the valof primary which could be used to write an arbitrary computation as part of an expression, for example: sum=valof{int i, sum =0; for (i=0,i<20;i++)sum+=a[i]; resultis sum; }check_sum; (where the resultis construct defines the result and breaks to the end of the valof braces) It got left out of C, probably on the valid basis that the same code could have been written more clearly as an equivalent sequence of statements. However, the construction is invaluable as a way station in a series of transformations. If an enzyme were to expound on the expression: sum = (a check_sum; it might well wish to choose the inline loop as the implementation of the summing intention, and it would prefer to do the substitution in place, without the need of analysis. In effect, valof is the key primitive ingredient of the various inlining features of languages such as C++. But how can valof itself be implemented? It is worth enumerating the ways, because they are typical for a whole class of primitive intentions: The necessary complex analysis may be performed to displace the code to the nearest legal place which is executed before the actual use and use a temporary variable to transfer the value. int T; int i, sum=0; for (i=0;i<20;i++) sum+=a[i]; T = sum; goto end; end: sum = T check_sum; Use a trivial if suboptimal implementation to verify that the abstraction is useful. Frequently, the benefits of use outweigh the inefficiencies, or problems unrelated to efficiency can be identified once an implementation is available. When the feature proves itself, new implementations can be introduced without negating in any way the investments made into using it, that is without having to change existing code. The trivial implementation for valof is to introduce a function: int T(int a[]) { int i, sum =0; for (i=0,i<20;i++)sum+=a[i]; return sum; } ..... sum = T(a) - check_sum; If the abstraction is useful and sufficiently basic, it can be absorbed into R-Code, which simply means that the optimizations of the code-generating back end are allowed to posses knowledge of the abstraction in question. Separating computational intent from implementation detail. The idea here is to provide parameters (annotations and stipulations) to declarations or operations which determine how the intentions should be implemented; that is, what reduction enzyme should be applied. A few clarifications are in order: IP allows an arbitrary number of arguments to any node, but how would one separate annotations from standard operands? The answer is essentially that intentions for annotations are expected to answer true to the are you an annotation? method. (In the rare cases when annotations themselves must be operands, special intentions, which ignore this answer, provide the required context.) By separation, IP means an arbitrary distance, so that the change of implementation can be effected without having to change the code that uses the intention in question. But the choice of implementation has to be made at the site where the intention is used, so how does the information get there? By successive abstraction. Annotating the actual intention instance would be possible but probably rare. Next, one could annotate the declaration of an operand, the declaration of the type of the operand, and so on, at each level affecting more and more quantities with fewer and fewer annotations. Implementation information can be also propagated through procedure interfaces using specialization (cf.) and completely remoted from its place of activity by proxy contributions (cf.). Finally, the notion of implementing is to be interpreted under the assumptions that are implied by the annotations and stipulations. For example, a four-element fixed array may well be an implementation for a general collection intention, provided that the number of elements in the collection will never exceed four, the element sizes match the array type, zero is available to mark the absence of an element, etc., etc. Annotating the collection with the name of the implementation (that is, the reduction enzyme) would be understood by IP as a stipulation by the user that sufficient conditions for the use of the implementation are satisfied. Or, conventions could be introduced where the specific stipulations could be made by the user which could be interpreted by the enzymes to see which enzyme should be awarded the job. But is it worthwhile to optimize code to the extent implied by this facility? The answer may or may not be yes, but the question could be more usefully refocussed on the act of writing the code in the first place. It has been said that premature optimization is the root of all evil, yet all programmers have experienced the quandary of writing code that has a chance of performing well versus writing a functional prototype which will have to be rewritten for performance. Where does designed-in performance end and premature optimization begin? IP removes the quandary. When you have the urge to commit premature optimization, you can express both the prototypical intention and the more complicated implementation at the same time. Perhaps the expression of the implementation as an enzyme may be harder than writing the code directly but as a bonus, the particular implementation trick now becomes a sharable and marketable object, to be used whenever a similar situation might arise. Also, the optimization, premature or not, becomes replaceable by other implementations with different performance characteristics. How is this different from classes in Object Oriented Programming? First, the implementation choice applies to every intention, not just objects, so the system does not have to be one-hundred-percent pure object oriented to have the benefits of separation. Even when the object paradigm itself is considered an intention, it might benefit from various implementation models that do not involve OOP. Conversely, OOP itself includes many implementation choices and different structures might benefit from different implementation choices. Second, under IP any implementation tricks are acceptable, not only those which are expressible in terms of methods. For example a procedure might request space in the callers frame, and demand a pointer to it to be passed. A field in a structure can be a fixed size array, a relative pointer to a variable size array, with the size stored separately, or a heap pointer to an allocated block with the size computed from the block size. These choices could be all simulated in OOP at one level, but you could not define an embedded object which, if included into another class as a field, would create any one of the above choices. Thirdly, in IP the independent quantities which form the programmers contribution to an intention can be kept textually separate and without any impact on the run-time program, from the dependent quantities which comprise the implementation. In OOP, similar separation within a class is impossible and can be only approximated by public/private labels, comment, and program formatting. The form of expression of the intention is difficult to separate from the run-time representation in that anything a programmer writes in a class constructor, for example, has to have some run-time existence by definition. The intention/implementation abstraction does not replace procedures. Roughly speaking, a procedure is an intention with one implementation which is in the form of a subroutine. Casting the implementation into transformational form becomes effective only when an intention will admit to multiple possible implementations, or if the actual parameters expressing the intentions differ markedly from the formal parameters which implement the intention. Specialization. The act of specialization is satisfying a procedure call by the creation of a new procedure instance by partial evaluation of the old instance with respect to some additional information about the values of the actual arguments, typically the information that some argument has a given constant value. This should have absolutely no effect on the results but for two very important factors: First, some interesting quantities must be compile time constants: for example static types, implementation choices, field selectors, code sequences, efficient array limits. Absent specialization, formal parameters to procedures are, by definition, variable. Ergo: many interesting quantities cannot be used as parameters to procedures unless one has specialization. Specialization thus removes the incentives to use source-level macros or other preprocessor constructs when abstractions with compile time constant formal parameters are needed. Much clutter in C production code is caused exactly by the macro definitions and ifdefs which express otherwise quite normal abstractions, but using a very primitive and unattractive language. The second key factor that favors specialization is efficiency. Existing procedures can often be speeded up in key contexts by judicious specialization. Inlining is a common feature in programming languages that achieves the same or greater performance improvement than specialization, except that inlining is profligate in its use of code-space. In any case, specialization provides for a spectrum of tradeoffs. But the most important effect of efficiency will be not on existing code, but on new code. Once it is clear that parametrization does not involve run-time costs (nor a change in the mode of expression, for example, having to use macros instead of procedures) the programmer can express more and more variability in the code in terms of parameters. This will give rise to larger, very general, archetypal procedures which will have one or maybe a few instantiations in any given using program. The archetypes would be extremely reusable because of their generality. Also they would be usable because from any single programs point of view they would be as efficient and have as few free parameters as if tailor-made. In the 1968 Nato conference McIllroy made the famous prediction that a universal component library could be developed and it might contain 100 of just sine routines alone, not unlike a hardware component catalog in which there are at least 100 kinds of op amps. This prediction has not come true maybe because 100 is too small when the combinatorics of possible number representations, wordlengths, desired precisions, preferred approximations, space/time tradeoffs, etc. are taken into account. The number 100 is also too large, when one considers the size and organization of catalogs and deliverables, and the problem of the marketer and customer to exchange information about supply and demand. With specializations, the universal library would have just one sin routine (or perhaps just one trig archetype where the particular trigonometric function is also just a parameter) and users would be able to specify, or let default, a dozen or more parameters. The number of possible specific routines which could be gotten from the archetype would be combinatoriaRoot EntryzF@FWordDocumentvObjectPool@|F@|FSummaryInformation(     -RSTdetu;############################################K-;<Lbt lm de_`MRS!#K###############}###############S! 8 4h! 8 4h!%*,,--/0o2e337K89:<7?@@JDKD]I^IJJ N!NOOSS#> # ######### ######S#### #### #### ##8b! 8 4h! 8 4hSXX \ \\]+],]dbebbbqdrdeeggg^hhjjkkllppprrr s7sFsPsls ######## ################### ###########! 8 4h&lsmsuuwwwxxxayKzZzzzx{}E~Q~~ ,.xyJKLg_܉XY#######C'################ ##############! 8 4h% ~ٓܔ<h#h##}##x####V#Q#L#L#p!  4h! h 4h! 8 4h!  4h! 8 4h h?˗DES`a########i#d#a#a#a#i##i##! 8 4h! 8 4hp!  4h!  4h[\EF89():$%BIOX^ɰʰ#######h##* #######################! 8 4h! 8 4h ײGH#$ag@}ֺ-./p`a~############################)# ##! h 4h! 8 4h89\]4;\%&UVcd ##### ######################################+ @A-h$+ohw*+"#cd######################## ### ####### ###! 8 4h%  @A^_pq !!###$$5$$$$5%#####~################## ##############! 8 4h.%5%l%q%%&&&&(''(((+++ ----//L1M1<2=2P2~55777S889:a:;;#####################################`! 8 4h%;;m< ==>>?@@xAABBBnCCjDD[EEFnFF,GGGG###########################`K@Normala "A@"Default Paragraph FontDG!        ! !   !         _"2EYe_itw(_a9!0n@DJ   < k?G;!Slsh5%;GZ'Z)Ze_~__tuuaz|AZ\D:::::Word DevelopmentC:\doc\newcastle\NEWCAST2.DOCWord DevelopmentC:\doc\newcastle\NEWCAST2.DOCWord DevelopmentC:\doc\newcastle\NEWCAST2.DOCWord DevelopmentC:\doc\newcastle\NEWCAST2.DOCWord DevelopmentC:\doc\newcastle\NEWCAST2.DOCWord DevelopmentC:\doc\newcastle\NEWCAST2.DOCWord DevelopmentC:\doc\newcastle\NEWCAST2.DOCWord DevelopmentC:\doc\newcastle\NEWCAST2.DOCWord DevelopmentC:\doc\newcastle\NEWCAST2.DOC Cindy Wilson)\\ATR\LIBRARY\TECH-RPT\Sum95\Tr-95-52.doc@HP LaserJet 4Si/4SiMX PS\\msprint21\privsPSCRIPTHP LaserJet 4Si/4SiMX PSHP LaserJet 4Si/4SiMX PSw odXX]Xo3RdCustom page 1BBCustom page 2BBCustom page 3BBHP LaserJet 4Si/4SiMX PSw odXX]Xo3RdCustom page 1BBCustom page 2BBCustom page 3BB1Times New Roman Symbol &Arial"1h:E:E:E. ;@'r$uEThe Death of Computer Languages, the Birth of Intentional ProgrammingWord Development Cindy Wilsonࡱ> oܥhW eGvDjjjjjjjjjjjjjjllllll*lXlu1l^lllllllnnnnLoLZrLuuXMvuujjllllluljjjjll  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~lllljjljjln@F~jkjjjjjjjjlnll The Death Of Computer Languages, The Birth of Intentional Programming Charles Simonyi September 1995 Technical Report MSR-TR-95-52 Microsoft Research Microsoft Corporation One Microsoft Way Redmond, WA 98052 The Death of Computer Languages, the Birth of Intentional Programming Charles Simonyi Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 USA Introduction This lecture series sponsored by Prof. Randell has a long-standing tradition of grand overviews of the state of the art in some aspect of computer science. For this instance, Brian and I have decided to break with this tradition for a number of reasons. First, currently I am only articulate when I discuss Intentional Programming so this limited the choice of subjects. But the general topic of Future of Software suggests that we look forward and it also grants a certain license to speculate. It so happens that this is the first public forum where I have ever discussed these ideas and this should also lend some spice to the occasion. I intend to discuss one possible future avenue for the evolution of our expression of computer programs which would create exciting new possibilities in the production and sharing of software artifacts. In my second talk I would like to demonstrate, using an operational implementation, how programming might be done in the future. Why talk about the death of programming languages? Is something ailing languages? At the outset it is safe to say that we all share a feeling of unease insofar as the general state of software is concerned: development is difficult, achieving correctness is difficult, levels of software reuse are low relative to what we would intuitively expect. But how much of this has to do with programming languages as opposed to software engineering? I suspect it has to do a lot with languages, and to see why, I enjoy arranging the common properties of languages in three categories: Unassailable: statements which everybody, including me, believe to be good, although there might be arguments about importances. I think they are important in that they are the only unassailable and hence invariant properties. For example, I rank efficiency as unassailable. Doubtful: these are good and necessary properties except that it is widely believed that a choice has to be made and then that choice must be right. For example syntax falls into this category. Needless to say there is disagreement in what right is, at worst due to differences in opinion and at best due to differing requirements. I call these issues doubtful because I believe that we have the freedom of deferring the choices to a time and place where information supporting the choice is maximal and the cost of making the wrong choice is minimal, rendering t  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~hese issues routine. Terrible things that are accepted as normal. For example: Different languages are not compatible with each other. These things are so obvious that people do not even think about them. If pressed they would agree that they are bad things which should be alleviated when possible, not unlike automobile accidents which will happen despite our best efforts to reduce the mayhem on the highways. Again, I believe that we underestimate the degrees of freedom we possess in the software world, anding Journal, July 1990. FEATHER, M. S., A Survey and Classification on some Program Transformation Approaches and Techniques. ACT Transactions on Programming Languages and Systems, Vol 13, No 3, pp. 342-371. GRISWOLD, W. G., BOWDIDGE, R. W., Program Restructuring via Design-Level Manipulation. Proceedings of the Workshop on Studies of Software Design, Baltimore, May 1993. GROGONO, P., Comments, Assertions, and Pragmas. SIGPLAN Notices, Vol 24, No 3. JORDAN, M., An Extensible Programming Environment for MoRoot EntryzF@PFWordDocumentsMObjectPool@|F@|FSummaryInformation( DocumentSummaryInformation8(_871116437#F@|F EF_871119209 F@FF_871287815FFF  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJLPRVX\^bd՜.+,0HPpx  Microsoft Corporation; FThe Death of Computer Languages, the Birth of Intentional ProgrammingࡱOh+'0$0@ Xd    FThe Death of Computer Languages, the Birth of Intentional ProgrammingerWord DevelopmentrosNormalN Cindy Wilsonent2 Microsoft Word for Windows 95l @@BOsF@F@F. ࡱ> ࡱ>  FVISIO 3.0 Drawing VISIO Shap_871204774FFxF_871204910 FxF FOle MPIC  KLlly huge. . Come from statement. This novel abstraction helps with hiding information between modules. It stands in contrast with a normal procedure call, where the caller knows what procedure to call, but the procedure only knows what it implements, not who might call it. In a come from procedure, the potential call site, the come from label, knows only what invariants are true at the site, but does not know what procedures, if any, might be called. The procedures, in turn specify what come from labels, that is under what conditions, they should be called from.  EMBED Visio.Drawing.3  For example, when cache C is empty, the following come from label may be executed: CacheEmpty(C): and the following procedure would be called: proc comes from CacheEmpty(CACHE c) { ... } note that parameters would be allowed. All this looks perfectly normal except for the fact that the procedure must also import the name CacheEmpty just as the label does, and that there could be, say 3 labels and 4 procedures referring to the same name. At each of the 3 labeled places, 4 calls, one to each of the 4 procedures would be executed. Information hiding would be perfect as the only definition they would all have to know is the name of the invariant they all apparently have a stake in. Proxy contributions. This intention is another abstraction to help maintain information hiding, without having to resort to run-time interpretation. For example, to extend the behavior of an intention defined in a system library, the method can not be written as part of the declaration, instead, it is contributed by proxy. In a similar manner, a module can add fields to a data structure, or add values to an enumerated type that it does not own. Legacy Programs IP promises to be a great vehicle for re-engineering legacy code. The method for incorporating a legacy language L into IP is as follows: Identify the intentions in L either with existing intentions (such as +, int, goto) or with specific new intentions (such as MOVE CORRESPONDING.) Adapt an existing parser for L to create the source tree of these intentions. It helps if this parser is written in a language for which a legacy parser already exists (such as C.) Otherwise, the parser has to be re-coded.. Choose implementations for the new intentions and define the transformations for them. At this point choices have to be made about semantic compatibility with existing intentions. Fortunately, these choices will not be permanent, so engineering tradeoffs can be made between requirements, schedule, and implementation costs. If necessary, compatible implementations may have to be added to existing intentions. Typically, imaging enzymes ought be defined to be able to display the code true to the language L. This is very easy to do and will help a lot in verifying the parser has worked and attracting legacy users. By the way, it is acceptable if intentions outside of L, and even rare L intentions do not have imaging enzymes: the inherited or default notations will typically suffice in such cases. Step 3 might still be a sizable project for a large language such as Cobol, Pl/1, or Ada. Of course the incentives for an independent software vendor to do this work will be also very large. For smaller, locally popular languages, where the semantics are more standard than the syntax, the total costs might be of the order of a month of a programmers time depending on the availability of a parser to start with. We have implemented a full Pl/m system in IP in addition to the C legacy system that was used for bootstrap. With Pl/m in place, a private collection of legacy code written for some long defunct platform found a new lease on life. Indeed, if there will ever be a computer museum for languages, IP would be an ideal framework in which dead languages could be resurrected and maybe even find use in a luxurious new development environment which would be beyond the languages creators wildest dreams. Once a program written in L is imported into IP, it is open to re-engineering by continuous improvement. Instances of inconvenient old intentions could be removed or consolidated one-by-one and the program would remain in runable and testable state throughout the process. Old parts could be viewed in L or in C, while new parts would show in C (or whatever the best available notation is.) The re-training of programmers skilled in L could also proceed in parallel with the improvement of the program code. Large-scale systematic changes to the legacy program could be effected by writing editing enzymes. One interesting question of legacy parsing is what to do with pre-processor information and with comments? As to comments, they historically have comprised an important part of the programmers contributions and must be preserved. The real issue is to develop heuristics as to what node in the tree the comments should be attached to, that is to parse the tacit syntax of comment bindings. In languages such as C, much of the intentional information is encoded in macros. For example, consider the C fragment: #define transform(x) x + 5 ... print(transform(a)); It would be a tragic loss of information if the legacy parsers total output would be: ... print(a+5); which is what a typical compiler rightly expects from its parser. Optimally, we would expect the IP legacy parser to recover the underlying intention: anytype transform(callbyname anytype x) {return x+5;} ... print(transform(a)); Again, this calls for heuristics which go beyond the original language definition, but which, defined and applied judiciously, not only preserve more of the intention of the source, but also serve as a first step to re-engineering away from macros. Experience has shown that it is useful to classify C macros into a few categories: constant-like: such as #define a 1 procedure-like: such as #define transform(x) x+5 token-like: a catch-all category, meaning that calls to it must be expanded and that information will be unfortunately lost. The expansion may be labeled with the name of the macro so that it may be identified by an editing enzyme during re-engineering. statement-like: #define forever for(;;) // note last parameter is the next statement type-modifier-like: #define LINK ** Similarly, #ifdefs can be also classified into token-like which will be expanded with information loss and honorable, which can be made intentional. Some classification can be done automatically, and some of the rarer ones must be classified by the user using a pragma comment. Using the above classification and a few intentions which express the underlying intent, practically all macros and ifdefs in very complex programs can be intentionalized. For example, an honorable ifdef applied to statements can be expressed as a simple if. However when it is applied to a declaration, it is expressable only as a new intention: an annotation attached to the declaration which contains the condition under which storage need to be reserved for the declaration. Business model As mentioned earlier, some users of IP will specialize in creating packages of intentions and collaborate to establish standards which ensure semantic compatibility of the intentions. Let S denote the number of standards, I the number of intentions, and U the number of end-users. The expectation is that S will be small, I large, and U very large: S << I << U I will grow because the market will the very large U. This is as opposed to today where the market for language features is stagnant, maybe with a few big sales every decade. The number of standards will be small, but standards can be changed if the benefit to U exceeds the cost of recoding the Is, in other words the shift will be possible when cost/benefit < U/I which will be in the thousands. The cost would be borne by the ISVs (independent Software Vendors) but they would in turn charge the users according to the benefit of the change. This is very much different than today, when the cost/benefit must be less than 1 for change to take place. Pressures from U would be satisfied by new Is. There will be very few impediments in the way to growing I. In the old world, pressures from U would have to be handled by essentially S. Now, pressures from Is would create new standards, as described above. Accumulated difficulties faced by ISVs would have to be relieved by periodic updates to the IP kernel, extending the ways that the kernel itself can be extended. The market will be very large because of the absorption of more and more legacy languages, and because of the increase in code sharing due to the separation of computational intent and implementation detail, and because of specialization. Summary and Status We have presented the idea of the intention as an abstraction mechanism, and an integrated development system which may be used to develop systems using intentions. Software encoded intentionally can be said to be immortal, in that its meaning can be sustained independently of the long term progress in programming notation and implementation techniques. The independence and self-sufficiency of intentions might well create first a market in abstractions or language features, followed by the long sought-after dream of a software componentry market. Legacy code can be integrated into the new paradigm with minimal or no loss of information and there are considerable prospects for hot re-engineering or continuous improvement, which can be performed while the legacy system is kept in operating condition. IP is currently under development at Microsoft Research. Several US Patents have been applied for, covering various aspects of the system. The system achieved complete self-sufficiency March 1, 1995, and since then all further development of IP has been performed in IP itself. The size of the system as of September 1995 was about 1.7M nodes (intention instances) in the source tree. Plans include the creation of component libraries; the support of additional legacy languages, such as C++; operational use of the system elsewhere within the company; and finally productization before the year 2000. References ABRAHAMS, P. W., Typographical Extensions for Programming Languages: Breaking out of the ASCII Straitjacket. BACON, D. F., GRAHAM, S. L., SHARP, O. J., Compiler Transformations for High-Performance Computing. ACM Computing Surveys, Vol 26 No 4, December, 1994. BALLANCE, R. A., GRAHAM, S. L., VAN DE VANTER, M. L., The Pan Language-Based Editing System for Integrated Development Environments. SIGSOFT, 1990. BASSETT, P. G., Frame-Based Software Engineering and Iterative Design Refinement. Software Engineering: Tools, Techniques, Practice, April 1991. BASSETT, P. G., Frame-Based Software Engineering. IEEE Software, July 1987. BATORY, D., OMALLEY, S., The Design and Implementation of Hierarchial Software Systems with Reusable Components. ACM Transactions of Software Engineering and Methodology, Vol 1, No 4. BERLIN, L., When Objects Collide: Experiences with Reusing Multiple Hierarchies. ECOOP/OOPLSA 90 Proceedings, Oct 1990. BOSWORTH, G., Objects, not classes, are the issue. Object Magazine, December 1992. BURSON, S., KOTIK, G. B., MARKOSIAN, L. Z., A Program Transformation Approach to Automating Software Re-engineering. IEEE, 1990. CAMERON, R. D., Efficient High-level Iteration with Accumulators. ACM Transactions on Programming Languages and Systems, 1989, Vol 11, No 2, pp. 194 - 211. CHEATHAM, T.E. Jr., Reusability Through Program Transformations. IEEE Transactions on Software Engineering, Vol SE-10, #5. COHEN, H. H., Source-to-Source Improvement of Recursive Programs. Ph.D. dissertation, Division of Applied Sciences, Harvard Univ., May 1980. DEWAR, R. B. K., GRAND, A., LIU, S., SCHWARTZ, J.T., Programming by Refinement, as exemplified by the SETL Representation Sublanguage. ACT Transactions on Programming Languages and Systems, Vol 1, No 1, pp 27-49. DEWAR, R. B. K., SHARIR, M., WEIXELBAUM, E., Transformational Derivation of a Garbage Collection Algorithm. ACM Transactions on Programming Languages and Systems, Vol 4, No 4. DYKES, L. R., CAMERON, R. D., Towards high-level editing in syntax-based editors. Software Engineering Journal, July 1990. FEATHER, M. S., A Survey and Classification on some Program Transformation Approaches and Techniques. ACT Transactions on Programming Languages and Systems, Vol 13, No 3, pp. 342-371. GRISWOLD, W. G., BOWDIDGE, R. W., Program Restructuring via Design-Level Manipulation. Proceedings of the Workshop on Studies of Software Design, Baltimore, May 1993. GROGONO, P., Comments, Assertions, and Pragmas. SIGPLAN Notices, Vol 24, No 3. JORDAN, M., An Extensible Programming Environment for Modula-3. ACM, 1990 KAELBLING, M. J., Programming Languages Should NOT Have Comment Statements. SIGPLAN Notices, Vol 23, No 10. KOTIK, G. B., MARKOSIAN, L. Z., Automating Software Analysis and Testing Using a Program Transformation System. ACM, 1989. KOTIK, G. B., ROCKMORE, A. J., SMITH, D. R., Use of Refine For Knowledge-Based Software Development. IEEE, 1986. KRUEGER, C. W., Models of Reuse in Software Engineering. Carnegie Mellon Report CS-89-188, December 1989. MERKS, E. A. T., DYCK, J. M., CAMERON, R. D., Language Design For Program Manipulation. IEEE Transactions on Software Engineering, Vol 18, No 1. MINR, S., Interacting with structure-oriented editors. Lund University, Sweden PARNAS, D. L., SHORE, J. E., ELLIOTT, W. D., On the Need for Fewer Restrictions in Changing Compile-Time Environments. Naval Research Laboratory Report, 7847. PRIETO-DIAZ, R., Status Report: Software Reusability. IEEE Software, May 1993. RIEHLE, R., Objectivism: Class Considered Harmful. Communications of the ACM, August 1992, Vol 35, No 8. SAKKINEN, M., The Darker Side of C++ Revisited. Structured Programming, 13: 155-177. SCHERLIS, W. L., Abstract Data Types, Specializations, and Program Reuse. SHAW, M., WULF, W.A., Toward Relaxing Assumptions.in Languages and their Implementations. SIGPLAN 15(3), 45-61 1980 VOLPANO, D. M., KIEBURTZ, R. B., The Templates Approach to Software Use. Software Reusability, Edited by Biggerstaff, T.J., Perlis, A.J. Addison-Wesley /=heMETA tCompObj gObjInfoVisioDocumentOle SPIC QLMETA nCompObjOgObjInfoNVisioDocument*/Ole YPIC WLMETAntry EPCompObjentUgObjInfoTVisioDocumentU]Ole  _ PIC$%&'()*+,-./0 56789]L@METADEFGHIJKLMNOP UVWXY6`CompObjfghijklmnop uvwxy[gObjInfoy!ZVisioDocumentp(OletPool ePICaryInformation "%cLMETA  V CompObj&'()*+,-./0$&56789ag@ObjInfoFGHIJKLMNOP'UVWXY``VisioDocumenthijklmnopuvwxyVisio (TM) Drawing R wd !fffMMM333#q0#T d Arial) -3Times New Roman5T?? Y@-1''J/T  hTJbOSS0{Gz?@CPjV]uVbUUO OS? T666 NP U    UvPaC G#G#G#G#G#G#G &H#O`$$!^M4!}7i>p'0U2?!67gjP>6;03206&0B!4?6P2GT}w2k=- w2 T /@ 9ܿ6L^pu 95<2?O??ZX: F&}03P?|_?V*&CG ]OoN9̋OOOOO2qW`?@Vohf.hfRjj)gV_ _) 2]_ og&qooon# x0T_o?u@.5e%v4pq/@"K@U B p K@ +U/37U?CS@KUOW[U_c#pUo5@ w!{U"#$ % ~ yJB ԏ}x1 '9K ~P ß~` );~ }~  +(~ m(~ > | _qX?DxjtCe&[PJCςϔ } cuP m9P߅ߗ~|  ew(~ ~ Ugy~l ~ EWi{(~w ~w5GYk~w~w%/7/Z` aO贁Nk?8Q&06 RT /////#f?0#e?/25?G?Y?k?}?Q?2'E?/2???OO/ ??4eOwOZa(OOG=jOK\ @R_XNqb+5c8_tqwTimPa<\'K2rbIpMqMfqf"Дm1j paPV?oU03b0f[*rmG !__@___o<~lTq&ij3doogmS Bei{d:oLjc%YkohJooo"=FX.o@vooe#'9K]x oo5 τ3ُ!3h$Qcu)DM_qf%ïկ i-?Qc\\MSPRINT3\9/1041 VJ 157.56. |p[Letter Dyna_mic?FG l \4iN'~PSTATICSome sample`8winspool\\MSPRINT3\9/1041 VJ 157.56.136.246Ne00:FALSE1  P 9D?j@Us!@F_T L*HhGTIGzT @I/b@??I QVI:zIDžbbb bK=e$n4Hcp Wxooo"o* o2 o: oB oJ oRpZobojor%op#uoowoo_5 5 4!5 5 5 5 5 5 z5 r5 j5 b5 Z5 R5 J5 B5 :5 25 *5 "5 5 5 5 - oBA"GPjg@RQ?@$\( @!?:!.?P 3@Q$@%$& & ޠ :u`F"X1]2Nc0ui96 & % L@[Wl_UXgIa+030!!g7 c07&AY0){Y0@B-Or0*O/bOtMAMИO&OO Ir{ PQ#P"Qh}W:H!P///*P"% /??+6# @? R4c????X2jQu1Ib??? ??]OO5HAFbOOaOsOOOO7o[__'_9V>@E_xW_iZr@Fz{o?@(! %VܪW!̳_VV0"K8 "hRD".3)+X2>Aa?s3~? ,o5vaZ~ed ojsM%yVtLupT3VoXi_*@"__U#>H1__oo&o8nXMcXojo|oo&4IAFo'q_߿mϥ9V#{@_ASe_ү>?P?*s???<o??O"O4OFO @`aO;,rOO"N,r+s,r{€đ~ْ(_B_&`_r_______"?4?o&oAoSoeo@_?5ooo/ M_`b{pœt/4FXj|ԏ_pHx&75;S?@:m@}@?@@U5?*2ŵ?P*)#ħ+ů4'rܰg!N-'L@ ߽2:PKYWi{ *J߲f*ϊݸ@׺\H|[[T4>)"lab/els" ݿwh@!4 EWjϥP&8*<%A w=Rdv)Proced/ures $wi`,ΛC !ݥ=LSsD "q؛//?/J?/n?l}come from" declaration,GzT @/b@ @B "@(> Gp4@ /w<?R /Gh,Page-1Black fill}White uRed Greeun -Cya@Yellow GMnta3ay(10% x line3 Long dash1"darI9e. X5 7 9 1pxlm9mHairqShort Arial ckeredtop leftT/imes33  !ͪ      x h X G 4 $  3] Ӫ] ] ] ] ] ] r] d] U] G] <] -] ] ] "!p!GzT @/b@  _ \bl 2@B"Iv<W g(s@(74`? R w4T`wzD& ! wBg#w@R{$ J)/'R 'w;>p K2F+wպ?w8"<@P.w bࡱ> esVisio.Drawing.39qࡱ>RQ' 6    --$###-- --$OO-- --$-- --$JvvOJOJ-- --$-- --${{{-- --$OOO-- --$###-- -- %0T0- -- %00- -- %00\\- --% - --% - --%0 0- --%\ \- --%x-'-- $kk-- --%-'-- $-- --%B-'-- $-- --%-'-- $-- --%n-'-- $-- --%x-'-- $k-- --%-'-- $--  Arialww6w -"System6%Pw- . - !"labels"8- -- . - ! Procedures8- -- . -!"come from" declaration-ࡱLRQ'.ࡱ> ࡱ> ࡱ>  FVISIO 3.0 Drawing VISIO Shapn      !"#$%&'()*+,-./0123456789:;<=>?@ABCDFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmqrstuvwxyz{|}~Visio (TM) Drawing */R .d !fffMMM333#q0#T d Arial) -3Times New Roman5T?? Y@-1''J/T  hTJbOSS0{Gz?@CPjV]uVbUUO OS? T666 NP U    UvPaC G#G#G#G#G#G#G &H#O`$$!^M4!}7i>p'0U2?!67gjP>6;03206&0B!4?6P2GT}w2k=- w2 T /@ 9ܿ6L^pu 95<2?O??ZX: F&}03P?|_?V*&CG ]OoN9̋OOOOO2qW`?@Vohf.hfRjj)gV_ _) 2]_ og&qooon# x0T_o?u@.5e%v4M@q/@"K@U B p K@ +U/37U?CS@KUOW[U_c#pUo5@ w!{U"#$ %& ~ yJB Ə؏(}x1+=O~P ǟ~` -?~  (~  /~ q~ B!| cuX?xjtCe&[PJC(Ϙ} @gy#m= T߉ߛ(~ i{~ ~ Yk}~p  (~I[m~w ~w9K]o~ w(~w)/;/Z`!aO?Nk?<Q(&&VT /////#f?0#e!?329?K?]?o???Q?2+E?32???O O/ ??4iO{OZaOOGAnOK\ PR _XNqf+ 5c8otqwTiqPa<\/'2rbIpMqQfqj"Дq1Sj paPV?ovU03b0f[rqG !_____o@~pT q*ij7doo$gqS#Beid>oPjg%]kshJoo&AJ\2ozooe#+=Oa| oo9 ӄ7ݏ@ %7h$Ugy -HQcuf%ǯٯmP1CU&PR)׿X)VŀDUt% OaXz]8ϛ=RTṇ#U%4ķԼYfb)\\MSPRINT3\9/1041 VJ 157.56. |p[LetterRIVJ 157.K6OW \4BiN'@Gz@@@%X?@`8winspool\\MSPRINT3\9/1041 VJ 157.56.136.246Ne00:u `u `b0@_@F hTA@* ?<I?NXfx** <Ebb{b b NeH ( 3: 33󎻂߻34w5B3J V;U;Il@ Z;33;@ 30yP;3237Connect the side of onbjoanor.H"&\h_T@@, ?> OP u `u `@ T >xub?u `u q{u` Qu b  A@ )F4@O?0V)9chZ (8L@V,@OAJ&WI\ Q%Z%%a " wr}'`rL`-@R& @& /$| u`.J' ' V 0O贁Nk?gk'!bd4 d3 a0 !`(C) Shapeware Corporation+hP{lUxI5E10*+S v !@  &  0RA@-A[r xCr %(BTfl`}%-x& F-#- %CHo /%ywSHS\+>m "(:MQ#$F hTA@* ?<I?NXfx** <Ebb{b b NeH J <3󎻂3;󿇻0 M; jn;9 A 30ߙ;u 36Connect the side of onbjotopanor.b?6i6S?E8?5H"&th_Th@@@\[?,=,n=P u `u `bqu `u z )xuu` Qu b A@ {  +?@.؂-؂@,@@99?6C"C+q nwanL@%P AQAI ?$& %?b DL`;-@& ^Y u`.@Jr| ! <+0O贁Nk?J'ml$$b4 3 a70 !`(C) Shapeware Corporation  ClU,110*7@4G+> U q }@T!u }@*E8!+5 }p-y#F#Be B  ]5G@@/?S+;HO@S,H8/lS,֣p= W@G_z#@# ,֣p= W@G_z#@$ <@B `q,zG{4@0S |?R ! eP 9'qD@m۶ms@'F_T |L*hGTI֣p= W@IGz#@??I ?VIzbwbb/ b=ߓenHJo gpWxoo"o* o2{p: oB] oJ oRpZobojorGzooooܓpooooo]!oO$"o#oEh#$o%o !Ճk c S Uڕ ҕ ʕ • U U Uz r j b UZ R J B U: 2 * " U  e 4In$*&E"AHHPjg@RQ;?@@!y5;?=?P h6q6z6 6:u`F2N1u96 & %|,0+|3B L@[Wl_UXgIa{@Ch@!!727A|*U {Bz=O3Lz?O]6QM$_OH_ Ir{PQY@PPh W:HS1T127?Xj Ta?x65Ћ55??d9 %f??OO&0@T161bbqEJMaLnS_DhO zOOOl_GFrE#f^6_X#hp__p___Q%q4dD#f~a`KL` yW\po HA/?_S?aTo@@ |!y???oQ`N3W??ooo"NA7CBOTOfO6H(IFO_[_=*M_qV@XC_ AjFX "o-ojo|oџnXfo9u%^pίPHF_ҙүdBt(ڣs?lEƔz &߄uX!)"U@HJHؼ躣Up2p$bbU# 4 A &%>A{AI ?}$Ѕ%$ʟӜ@IDPnPA/J0JURf(08?Ó yk?V*QöfȨ4o!D?CH,>Pbtk} i0B@J;4#@ g# %EV TiN% @@h1 +B_QB.SWC&4Zz&RpyDb? >>CUgx!˿;@X%OT_,Œ_@VU`f@aU?doc$itet}eeePObOxO7`>r'9KP߰__݆fg9]JJJTR4fc!PxDeclaration of intenꁮ j?|?63\`ro:t ?ñßo JM_K  @ϯv@"4F襁 ؿ5) oOaϾП⟩Bŧ@J\m-oߓ!!3 ſ5!<πN^p@@ G"M"Z "[_q?A?/e?%EWi? SwE:L//$/>@AtER@//?O RM ??o?3o_Wo??? AQOeuOOO'tO_"_H`rrb/t//___|o/_o1?{?ooooo ?? O+?OoZcLuEE>vDR|!u `u `bu `u h'Jppoc@ U`cjroސ!ts"`y}ED)CO!pwt}zw0{tr?VuPb>lrQ'9ASorv,V)OmPHR H3EWi{ïկ@@)9O]BtEӉFqQw̿޿&8J\nπϒϤfosu EEEҝEQFzrxawߥ߷zHTpU 'ŏ@&<0guwT`rMethod nameG u9 v]q trT'%|yASiZѓ"T"""qRecA;@΁ ;@ }0u/./d?@,t`80t;+"09!09$/V/>T""qT"7[OOk _;?/T/??/Q/Tj/|/O//.P b"bbb/|U>`+6_G?Y?k?__<?u{?sy8zMo_oobbVOhOzOOOOOO_OB_._ΏR_d_v_HϱVԴU-DT!'9K]o߁\Y՟$ţis!'.`r@*X{jߝ6iU@@`UDu?Bĵop0iCUpok*1CL@ZGP@}˜@ ߀+Oڋ))(4:Code of mins/tancX]oah͟ߟ'9]D@6(RQ!1կC! J\ntȿڿ"+=Oa̪ t@FϒϤť%6N"@Rdv>,?P?t?b<:??&??^@@BFCXj|/@R296ɧ#Sm URcSoRIc)gSOj&?O\nN?:mw///A.uZ/l/s_//RpY/// ?o O??䏚???ΏP@t*OQjrisjrSRjQ~R qeЩr8v)0ƇbrӞ pPU___Eo#o5ghJo\onm"ooLMjh w6Nhco#5GNDmD0~b}0/0SRjQRү4bP]o dhbw`ꡏŏ 5g"nm#EWL yF嫖 @bAQA3DQcJ3EWw؁pB4ۿڋT. $(èfQ GJ3 t@f@@XUe`ふaU䔰BXD .&+h xPAߩ&߀6Z~6rćD4R!)sDeclaration of virtual inten %Yk}C4#`?Nf@Qdm~B'D6HZl~"F/{/ ?/)?/M? BInstance node0֣p= W@Gz#@$& "@B0/+-> 8-i4@ P+?R _?0%Page-1Black fill_White }uRed Green -Cya@Yellow GMnta3a=y(10% x line3 Long dash1"da%rI9e. X5 7 9 1Gpxlm9mHairqShort Arial cke?redtop leftTim esConnectorSide s%!vable#&/bottomx# "'D'.31Z/13b3U] H 0 ! u  3 W3͡ U x Uh X G 4 U$  UӁ U r d UU G < -  '|t"p= W@Gz#@  !u O ^ fl 2@B q-y<W g(otϿ@(084`?!R P4TE_{D& ! `B"fRM$7] CIY)a/'R ()V+:p pK2FGO?w8-<@ - . bࡱ> esVisio.Drawing.39qࡱ>LFb(7ࡱ> ࡱ> ࡱ>  FVISIO 3.0 Drawing VISIO ShapesVisio.Drawing.39qࡱ>LUc08Fb    W 2--$VV-- --$DD==-- ArialwwZw -"System(Z%POw- . -- --$-- --$777-- -- %D-'-- $G0GG-- --% -'-- $%*%-- -- . -!Declaration of intentionX- --$K}}QKQK}-- --$^^^-- --$QQQ-- --$c??cc?-- --$Q%%QQ%-- --$cDcDc-- --%9-'-- $6Q66-- --%9-'-- $6Q66-- -- %??v-'-- $1y?^Ly1y---- . - !Method!name- -- %??-'-- $1!?L!1!---- . - !MethodT!name- -- %i?i?-'-- $1?L1---- . - !Method!name8- --%}%}-'-- $}o-- -- . -!Code of method instancenf- --%}}@ -'-- $= }X o= = -- -- . -!Code of method instancen f- --%}}}-'-- $}o-- -- . -!Code of method instancen.f- -- %?9?-'-- $61Q?6L61-- --$e e 9 9 e -- --$     -- -- %   -'-- $    -- --cK<$yaR:- --cDc\ckccccc- --77777(7@7O7g-'-- $g)7gDg)-- --c{&>Met(7O^v!9H`o #2JYq 4C[j-ETl{  / > V e }         ( @ O g v          " 1 I X j-'-- $g  g g -- --% e - -- . -!Declaration of virtual  ! intention a- -- . - ! Instance nodef-ࡱ> Visio (TM) Drawing U]R 4\!d !fffMMM333#q0#T d Arial) -3Times New Roman5T?? Y@-1,,J/T  hTJbOSS0{Gz?@CPjV]uVbUUO OS? T666 NP U    UvPaC G#G#G#G#G#G#G &H#O`$$!^M4!}7i>p'0U2?!67gjP>6;03206&0B!4?6P2GT}w2k=- w2 T /@ 9ܿ6L^pu 95<2?O??ZX: F&}03P?|_?V*&CG ]OoN9̋OOOOO2qW`?@Vohf.hfRjj)gV_ _) 2]_ og&qooon# x0T_o?u@.5e%vu4q/@"K@ B p K@ +/37?CS@KOW[_c#po5@ w!{"#$ %*&'  ~ yJB @ʏ܏}x1 /AS~P ˟~` 1PC~ @~   !3~ u~  F%|  gπyX?xjtCe&[PJ@CϊϜ}  k}'JmAX@ߍߟ~ m~  ~  ]oP~t @ ~ M_q~w ~w =OaPs~w @~w -/?/Z`%aO贁Nk?A@Q&&ZT /////#f?0#e%?72=?O?a?s??QA?2/E?72??? OO/?#?4mOOZaOOGEErOK\ PR_!XNqj+5c8ot9qwTiuPa}<\'2rb IpMqUfqn"Нu1j paP#V?oU03bS0f[ruG !_____HoD~tTq.ij;d ooguS'BeidBoTjk%akwhJoo*EN`6o~ooe#/AS@eo#o= ŏׄ;);h$Yk} 1LUgyf%˯ݯq5GY&P R۶\-V HUx%$OHO<Ĝ;ŕߜՒHAQׇL])4Uo) 'ѿ4şן% !nopψϚϸa\\MSPRINT3\9/1041 VJ 157.56. |p[Letterbin;c:?i\IW! \4ԨiN'I$I?hT`8winspool\\MSPRINT3\9/1041 VJ 157.56.136.246_Ne00:agc:\doc\NEWCAST.VSD\Dr2F hTIp= ף?IHzGk?A;I1OfxK*I3<Ebbb^ b NzekG 9 +wwpwpww~wwD'w98P./wp` PefP7I[m,wZAssemble with other wave sections to create a border. Rotmakvertical .mb?пp= HzG??IRQ迀zp?G hT|@p= ף?@HzG?@;1F ?P#*o@I5|<|Eu`Iu o`b kjJ@: bY!~`(C) Shapeware Corporation0}geH H,h_T @+?6>>=z=Pt` 7]{t  u`u l_b}  !#-* B$ *;E6 $ *S]6 $ P*ku6$*(6$*J6 '3AMYeq}lU0/ae i#i Zm۶mۯ?T# - "H%~Z?@$I k.,#` ܌H! / 8t3g7=t5'%//? ?27'F?X?z/ rֹ Z@^AD u@hQ U/g/>T?>ۯ( & (E-?{?O?1>O1Og:%8_7<7Z%'E&_O_\_@27G__OXF bG mONOO^To%n¯( & (e'o_8o27\ono_s%n~Q ].o@1>&qoXF bG oNL oo(xd% & %!F_HZl@Jo&q.NvF_Jޟx_~5ZD bG N _B1%&yVF?:0oOޯOI \o/꿌T_ϠrZDbG!NGYz?1%&yER1I_|GPTGP9,GP!l! i$g?BN5Lq???04Y (*Erd#]s6o@<` @"2 0Xd ]Qu}p- F"G#B 'GI B (GCdG@/Q+BP)GRc3H .cF hTI@IE(B??;*?N(u*%3<Ebb{b bNeN O Awwwwpow pwwp wx wpx py   w IDrag, drop, & ungroup this Windows Metafile to converta Visio shape.bE(B??Gzd7:??P"3w࿀>Eȿ@?@E(B?@P;HHu` ?ruy ;,b 7  d}:5swR*rz>DI j863b ܩ!J`(C) Shapeware Corporation7 )  : *j-:&% -%T6 %c,$% s,\?IS9f/l?[GIU8f*{ #3(ZXUPsFc9Q'=I]o-}:BGJ#fZ$%yb 4zF!!& +07>DJO{STq^N@67/0-+&!A:`^pB!)${{? #!PP{OKFU @;M 4I .E"! 2 :Ay HUNS{WX"r1!2.W4B O _ q #XWS] M > 4:2)P:1'h!u0A8O 2)">2U#10)0i"j!4L^J#| M  +@U9@q5@^+@N-@@)@6/_-[@+? //{J?\?n??5 6!F/X/j/|/% /U$ P+PpQS P~U? PnQ';@7@3@/@>-@ nQ~Q]@U@)@3@J7@;@RE)]@Q,'@4?-@MP^=@qPTPS?@C@G@WO)@AU@8P21]@Be090fUEQBc<3!0 -* :1dO??j3 `;`X`h`mrvy{~uY;l[PLG-p:% uL%~{wop]pDp-p#aovOO| `sX`;` `r p;pXph| uusq`mr m#`}CV)L)pK)pOZ%pkp:XtzwFvZ<om)p\1pQ/MqLqځJ׀HIUL$}upqp_p[pWpSpOpKpGpCp?p;p7p΢3p/pqG׀:%9p CpƪGpKpOpSpWp[p_pcp:gpkpiprupvxz*mpup~p]&ppp]D-#w pґfUǗΑ*/9fUq)4r^pQ}.C-%opdu{𸵠oogp,!g@t%@%ί\GU]$`,)1ݲ}73)ܱ!;p7)Ѷx}g Opnztvye|hfUIE|dxMLkpJ!fUtkppkpI£l¢sts|fUy|qѸruxfUOђ59DѕS7fUlz 7FxQpxvOp w k&΅e!&*/257}8tiT6740-*V&$# y^KC:51 -' {urqnpg_\_hweY"M:BQ9d0s)}%#"!(.6?DrT_[ju)Opp p``=A=|`ѐ߮B| tЬ}Ѓ3ЊЋ.ЍЎЖЕДГ058/;P5c,r|[ E !&"C"!oN(yncqXCـ0:2p,)"!$*%0W;EK0s+p'rfq*|UPq ps2w`*%E`"t1]39pë2E_[`SOKG11GKOS`[_E$ a%$f߸(ǒAYg}wu@umk=Ӡ]B O "%p(+*A%=` yǰeH+滠Oدx]X\6p.pTX,>pOcNMMUP HEEEFGcVE׃Ar j a[XR UJ PYbUlu{.o-?`mr>p4l'ihnvWl K K 7 $0n@sTyk*/Pw= c +9>G!N8UK[[`gcneqfujxpzx{}W|;3+mf\PB3"ppqX= usM%'M -wpje`\XUTSQ}MvGl.$όϜk}smo_&t3=?s5{(dgiвxqfk |tjpT  \dccd1SDp1BmiSgZdJ_7Y RKB9/$b<5PvO)jS}?w/r#om 2e%K 1jAUul|+Qx>d'1:CgJ9QLWW\hWoarbIpww=vytqIlEJxh?o~w={QoUE/]3Ձ]A;sQVS)]1@NQdkMoA^RD5$ػ%ĕ࿫ Q"S O p:wOv!PWQ WaflUsz॑q౪຿»!>; XyqಏV!S O G q X}<٪ѿ๪p,%wY>XW}2zzyEJQv!~1{ sI}~ vlB4AE'#~9z5t#n -^ULgh8B-" Y3u^J:.&B @ @Bk//B0I֯LHӥqB0S qЈ_t%Ыi7PO}Ap_p paw]IyWg5ԃm"QOp?Q%_1_C_@U_g_OOAAS ,}'i":/Mb+fPna(o__fa%ko}ooo1oCoA]Srp͵Po@rq,oojq%ox*<O\o^pxi_Mu`}N76oc6HZy@hFG - B8+}- FP&G#B p+G3 B,GqSG@"GS+B -GSFNVG(3F hTA@* ?<I?NXfx** <Ebb{b b NeH u 3ς;%. 3;FLU&][\]PM.%38Drag & drop to add an arrow with a 60-degreehead.H"'=hT@?, 4F?P-DT! @!u `u `bu `u z@Gu?@xu|u` Hu  b X#b k,@5,+D,> 5 ## ~L@!/ 6" F) FP>d/Q(dK#$ R,; 9`Qps-8R? -7@ @yQ&@g0 q`(C) Shapeware CorporatOiona0&kH }  tN`׀s@1 6s:<4{l U%a1\++/"2 W@V@@*3ߐEy~' r=L!)eFp= ףpruK?C|AG} G!Nv'QHx@C@eFGxHYHxO3H)J\RW@SPGq>PPPPP\ dķ ]^N@3F_5bZ_R@(@ =a? @b<=FC&RW@yaxbW@P5}`5bb4`!b??Gi6࿬:m?H?}%ˆ F)G3#B r4q BC>G@@O!5HG"cm+BPO8;,> p=!@G_z$@$ ,> p=!@G_z$@% ,> p=!@G_z$@& ,> p=!@G_z$@' \@B H"GI9,&Gu|)G'-G S@+ 4@?0"GXG|/G[3<G8?R `!G92 P 9,qDw@U@,FT L*hGTI> ףp=!@IGz$@??֌I ?VIzbbb b=weRnGcH Wxwwo N"{x* w2 w: wBxJwRwZrwbxjwrwzxwwwwܛxwww]wwE.x!wxw#w$ww%w&w'(w)w"*+^B : !* "    s k c [ S K C ; 3 + #  U   : 2 * "   )J4InF$%g(&')** +- GBKZl@݇@@| "@@L?!?45?P(-DT!@4666 61I0Q@UBUBW]wU2{(_40O5LYAHZAT;WA?Bgi5>?2_P t`EwPtU}^{YSYQAl_U0VWm?m?1UKPU@L?@$I`gW ESZQPW0P@e.u3lw`c.!ߘlg ///<)\(?*?N>Zg?y??????OO)OO _ zOOOOO_ -._@_R_d\)ebuggPH(:Q? Yevi{Lc:4*R???Q O2ODOVOhOzO a`hrOOOOOO__ B_T_f_x__2_Vz_ool<bN7[ޏ;mR. O BJJ:L^P(LSC=@(CD"Oas[?)??qKi??U?O7_RCODEJDRdvǏ$ǘc@@ c $AU$߀pDRD`jS|_0BVon% .//H@@*K?@`F+u]/LVpu )"v////$pC??'?9?K?=OOOPϦϼ,@>p!2K!23 3?!237*3:ӏOas U#1/+"(.+2PD)u)u)u ?W8+s2UF)?//, ?@R,PL@@߽A%EX`8BDBBOTOfJP'oA@ j`gbEV;oAQo_omAP-oMooc rj`3p7qA_JpJp=h:[(Standard Debug Kernel(!$O/0) _O..V{//////_/_OpbxdA0ςU_ p3 ,-X8ă^?+=O/Oo1oeOwN~oOOT%0(=j/(:L^pPaԉbn  ʳӉ>&ǒ,ʁɟ۟#5G#&bt`}(?@pd?@lv%VW ~N(Ӥ?ܯ$6HZlH/VWk(s%Pls`Aid3qr3pTWV>`W`~ϟϱQ~ '0BTߜT#R @t.P?wO(ɨD߻@'9K$4 Qz%PR )z/ m!2f>gr/AS@eM(H}{S?[:XLٷ#ɨ =GGYk}Kk T2@&%P&MS7ݶ32C3>O20CG36J/κ.7/I/Q)l/~/C0@}@ "@@SXS / ??-???Q?c?u?K P4$1bMXMW)hPBOUڹTzf1bc0c>o1bcg:cjOasυqOOOOX^OOQ* __.\ z@@bLP{sɥ?{\۲&YR{Vq.4_oo8p4bނo x_C 4v$EWz,q]}_qu"]}؊aq2TR^+._f?@mҨPUɨ? B/______KI4q@Q?Ѵ@y?$̹d䝵qp qzo Z#59Y} < > p=!@Gz$@$%&'()*+ ,!.@B !GX;> :4@ +X?R G YPage-1Black fill}White uRed Greeun -Cya@Yellow GMnta3ay(10% x line3 Long dash1"darI9e. X5 7 9 1pxlm9mHairqShort Arial ckeredtop leftT/imesF[Norma, 8ptWave section 2?DirF ta2Q WorokstaH!JQ 60 deg= single% @+.7!t-.20s]/ 4n% T(.27W3 !~ n ] J 2 !   3 3ͪ000000x0h0X0G040$003M0ӪM0M0M0M0M0M0rM0dM0UM0GM0 ףp=!@Gz$@  !" 5`fl 2@B 8[z< g(q@(&394`?!R 4TD& ! +BWW(ʼnhR+:wl$ )B G 'R X+#Y?p K2F}]O3?w \<@`/ * bࡱ> Uc r(    #  0--8J7BV<w7557<"BCJc`cWCQ"MKKMQwWV`7J77Vw    "Cc5c-C&""  "&w-V5777Vw"Cc cC"wV 77  *Km 77  mK*  5 =*DKHmJJHD=577(.2552m.K(* 5 ` h*nKsmuusnh`7J7SY]__]mYKS*J ` -- 1--.${m8aZZ|VVZam${$&19=|=Z981&----% {8Z|${- .  Arialwww -!Transaction file"SystemR2w%P$w- 1--$>>VV-- .  Arialwww -!Version ControlF- 1--$%>%>cc%-- . - !DisplayS/- --$2>2>pp2---- . - !Editor /2 !CommandB ! processor /t~ !Browser/'- 0--8p{wuuw:{[||[:pp_pWPLJJL:P[W|_tl|f[a:__afltp_p4p,%!!:%[,|4JA|;[7:447;AJp4pJDRcX]__]X/RPJp4p<PC/GIIGC<c4DJDtD}c/}Ptp_pgPn/rttrngc_DtDDc/PppP/cDD----- .@ -- -- ,$($klmpty~yusrr-  -- F$! %),-,)% -  --- ,$+++(% &*.//,$$(++/.*& ,$,$-  -- J$# %),--,)% -  --- ,$6$/++(% &*./+/.-,+$ ///++++,-./,$     &*./++(%6$   $ -  -- j$3O O O xO lO eO cN aM `K ^I ]C \< Z2 X& U R NJGC@=;98889:=@{BkEZIIL8O)RUWYZ[\]_cju~vO -  --- $ M eM eM lM xM M P P P xP lP eP e$ J `J `L aL bM cM eP eP cP aN ^L ]K ]V$)99:;=?BEHL P S& V1 Y; \C ^H _J `K ]I \D Z< X2 V' S P LIEB?<9866666789L$$]]\[YW)T8QINZJkG{DA?<::96679;>{AkDZGIJ8M)PSUXYYY$ cc`_^]YZ\_cc&$~ujccju~$ vwvwvwxxw$ M N vwO P O P P O N -  - - %K cv--   -- $L fvvL L f-  -- - %L fvvL L f--   -- $ vwO N vwvuuvw$z|vwxz-  -- $ [^^ZZ\Z[\]^$ st[\qsqqrst$ `bssbdba`ab$ ^ ^`d b b b a ` _ ^$ gg ^ bfffhhhg$ ^\gf[Z[[Z[\-  -- $e> > = = < : 8 5 1 - $   |k\PHEA?><9520.( <LLNQTX ]b g,l7qAuKyS}Y^_`bcefhjlov~{wsnie ` [" X0 T; RB PF OI NL KN FO ?N 5L #I F C A ? > -  --- ,$1 1 5 8 9 ; ; < < < @ ? ? ? = ; 9 5 1 1 L$$EEHP\k|  $ - 1 1 - $   |k\PHEE$ ==?@BEEA><;;&$0136;=;840/0//001,$  (.00.' $ &$JL<<LMLMMMLL$$``^Z~S{KxBt8o,j!e` [WROLJJMNPRVZ ^c h+m7sAwK{SY]^^,$lljhfecba`^`bcefhjllL$$E ME MB N; P/ R! V Z^chlquy|vollov|xtpkf b ]" Y0 V; SC RF QF Q$ M ?M ?L FK JI ME MF QJ ON LP FP ?P ?6$< < = ? A D G J #L 5M ?P ?O 5M #K H E B A @ @ @ ? > = < -  -- ($+)(&& $)+-  -- - .%++)(&& $)+--   -- $Akhdbbcfimq5tQwexnyqzs|ttsrpmjfc^Z W S# P/ M9 K@ JC IF HH EI BI >H 6F %C @ = ; 9 8 7 6 4 / , $   |smk-  -- - %Ikkhdbbbcfimq5tQwexnxnyqzs|tttsrpmjfc^Z W S# P/ M9 K@ JC IC IF HH EI BI >I >H 6F %C @ = ; 9 8 8 7 6 4 / / , $   |smk--   -- $Azwtsrsux{/GX_cdeedca_]ZXUSPN L J I H G F E B > 6 '            |z-  -- - %Izzwtsrrsux{/GX__cdeeedca_]ZXUSPN L J I H G G F E B > > 6 '              |z--   -- ~$=rsux{/GX__^][ZXVSQOMKJH G G F E D C A > : 5 $          ~xsr-  --- $& O' O  $ O& O-  -- $ JJJIIKGFFFGG($a~`v^aZCV!RNKJGHKNR!VCZa]v^~-  -- $mYXVUUW^h t$/7<=>>==<;9630,)$  " 3 D T e v                                               z l _ P A 1 !   |tmheda^[Y-  --- &$VVWXZ[WVUSSSSSTVV,$;;7.#vj `XVSV]g s~$08<<$ <<<<<;<?????$D               u d T C 2 "   #'+/2479:;<??><:852.*& ! # 3 D U e v                $            $             V$)                                         $Dddehnt|  ! 1 A P _ l z                   z l _ P A 1 !   |smhecc$ [[\^adc`]YWW-  - - l%4               x h W G 6 &   "%()+,,,-.....,**%zqhc`--   -- 0$v"  ) 0 ^ X c j       v-  -- - 0%v"  ) 0 ^ X c j       v--   -- $ j _  v  ^ -  -- - % j _  v  ^ --   -- $     -  -- - %     --   -- $ m            m -  -- - % m            m --   ' 1- -$?>?>}}?-- . - !Debuggerm- 1--$bL L bbL -- . - ! Reductionz - 1--$L |L |L -- . - ! Standard code\  ! generator T- 1--$L L L -- . -!Standard Linker z - - -% - 1--$ o o- - -- 1--$ | |- -  -- 1--$  - -  --  . -!User contributed portion -  . -!enzymes previouslyP #!compiled from source tree - 1--$k  Q Q    k -- 1--$k | |Q |Q | | | k --  . - !. OBJ -  . - !RCODE - 1--$Kk  Q Q    Kk --  . - !. EXEz - 1--n$5hvjWp7y0wOroprw3GWdn7sWuvsndWG 3$;N_lu{o}O{0ul_N;$ ypjhv--vh^jOk8p*ty|{%v3sKqZpoprqrtvw}"-3=FGSYc&h7n=oLqWsdtsuvutrojdb\WQI G;&17 ANOW_cilquz|}o}n|_{OyGw8u0p!llc\OF;7,$ {vpomji|hvh-- . -!Source tree / forest- 1--&$u4PlulP4----%ujb4^P^lbju- .  Arialwww - !Source derived8 ! info (symbolj5 ! tables etc.)@- --%>D-'-- $ %%& -- --%KQVQ-'-- $Y^>QYCY^-- --%Up-'-- $`DM`-- --%QQ-'--8CQ^CCQ^C-- --%Je-'--8M2uMMb}ubb-- --%fI-'--8oQaoM^@M-- --%=p-'-- $@%u@@-- 1-- $, , --  . - !Standard DebugO !Kernel'- --%V^^-'--8YP>^YkYPP^kP-- --% -'--8    -- --%- $ - --%-  - --%-  - --%77-'--8)o7D))7D)-- -- %||=-'--83QB3-- --%%t-'-- $l3ul--ࡱ> ࡱ> ࡱ> ࡱ>  FVISIO 3.0 Drawing VISIO ShapesVisio.Drawing.39qࡱ>L!J(*;##ࡱ> ࡱ> Visio (TM) Drawing (R $ 'd !fffMMM333#q0#T d Arial) -3Times New Roman5T?? Y@-1''J/T  hTJbOSS0{Gz?@CPjV]uVbUUO OS? T666 NP U    UvPaC G#G#G#G#G#G#G &H#O`$$!^M4!}7i>p'0U2?!67gjP>6;03206&0B!4?6P2GT}w2k=- w2 T /@ 9ܿ6L^pu 95<2?O??ZX: F&}03P?|_?V*&CG ]OoN9̋OOOOO2qW`?@Vohf.hfRjj)gV_ _) 2]_ og&qooon# x0T_o?u@.5e%v4M@q/@"K@U B p K@ +U/37U?CS@KUOW[U_c#pUo5@ w!{U"#$ %& ~ yJB Ə؏(}x1+=O~P ǟ~` -?~  (~  /~ q~ B!| cuX?xjtCe&[PJC(Ϙ} @gy#m= T߉ߛ(~ i{~ ~ Yk}~p  (~I[m~w ~w9K]o~ w(~w)/;/Z`!aO?Nk?<Q(&&VT /////#f?0#e!?329?K?]?o???Q?2+E?32???O O/ ??4iO{OZaOOGAnOK\ PR _XNqf+ 5c8otqwTiqPa<\/'2rbIpMqQfqj"Дq1Sj paPV?ovU03b0f[rqG !_____o@~pT q*ij7doo$gqS#Beid>oPjg%]kshJoo&AJ\2ozooe#+=Oa| oo9 ӄ7ݏ@ %7h$Ugy -HQcuf%ǯٯmP1CU&PR)׿X)VŀDUt% OaXz]8ϛ=RTṇ#U%4ķԼYfb)\\MSPRINT3\9/1041 VJ 157.56. |p[LetterO \4iN'*מ ) ?`8winspool\\MSPRINT3\9/1041 VJ 157.56.136.246Ne00: 6F hTA@* ?<I?NXfx** <Ebb{b b NeH ( 3: 33󎻂߻34w5B3J V;U;Il@ Z;33;@ 30yP;3237Connect the side of onbjoanor.H"&\h_T@@, ?> OP u `u `@ T >xub?u `u q{u` Qu b  A@ )F4@O?0V)9chZ (8L@V,@OAJ&WI\ Q%Z%%a " wr}'`rL`-@R& @& /$| u`.J' ' V 0O贁Nk?gk'!bd4 d3 a0 !`(C) Shapeware Corporation+hP{lUxI5E10*+S v !@  &  0RA@-A[r xCr %(BTfl`}%-x& F%#B@'c %B p( /%@$HSHPIS\+BO ": /)ǃQ#$F hTA@* ?<I?NXfx** <Ebb{b b NeH J <3󎻂3;󿇻0 M; jn;9 A 30ߙ;u 36Connect the side of onbjotopanor.b?6i6S?E8?5H"&th_Th@@@\[?,=,n=P u `u `bqu `u z )xuu` Qu b A@ {  +?@.؂-؂@,@@99?6C"C+q nwanL@%P AQAI ?$& %?b DL`;-@& ^Y u`.@Jr| ! <+0O贁Nk?J'ml$$b4 3 a70 !`(C) Shapeware Corporation  ClU,110*7@4G+> U q }@T!u }@*E8!+5 }p-y#F`%߯#B+J B _@-C5G7@/$gU+;O%c,HQc,(\@K_~d@# ,(\@K_~d@$ <@B (%T,8*zSp4@$?R x'! eP 9qDw@U@FT L*hGTI(\@IK~߱d@??֌I ?VIzbbb b=weRnHoI gpWxowoow"o* o2{p: oB oJ oRpZob]ojorpzoropoo% % $!% % % % z% r% j% b% Z% R% J% B% :% 2% *% "% % % %  4TIn#$AHPijg@)~(@@B _t@?!@!9%&?P  &@A$& v&:u`F: 2T1u[96 & %| |2 L@[W{l_UXgIa030!!-Y7e2k7"A| {:A3???oo0ID@C0KO-OOa5V@XCD_ :Ajŏׂ慓__ +_J\n@bX'Lf9?`oeoݟMϯ1H=F Qc?3W|ybE *F^p + yDZ/  $0Hc/D R 1JzWQ@@`U!#$^$,& ϐ 2ʗPϕϧC;O.BOߔrOOOOOIЌT41q-Operand nod es///iWQ (@.HS?T0?VL?^?p??PPWb?????OO`OoOoWoOI.oRov__(Y!-Methods of the intentioEn E.N贁?@?cvfP-DT!!eu `u `bu `u 9ذ.`q ` ܁ o@o;o?'^&6gi ?@Z<9@mƀ!?>>?ܓHz0{vtWd'bџ aKyƔbo~Z2fe6+P`H+=([٨Ohm4 /8Ǐُ! 9堞4 NWal"<5 ~ ’ّ ªÊ);M_q@4ïխ gRQQ?\̜m0c>`r̿޿ȳО4 N`Y:hTlϲ’MّxX~ -?Q ߑխ ));Mjym _?QcuɁ(4NW7ϻkeP’/ّF#&'L* @cCUgݥ N [?oW| 1CUgy@O0ZdwBNY (C/N1ePwBvC’OّwBSGCZo//////// 1?#?5?ݥP?b?t?AR@@B t@sls~???O"O4OFOXO`zDEr~Yg:m6ZlEZeC_uy@ArtErsDs’ّErswNsz=_O_a_s_____ ln__ mo0o,BoThah:LYoooooo!3zDTu]~.w|vꁶ…q /ASewX:ɏ mTi!ai>ö91'q˟ݟ@zDTu._|=kZrSq~^Äٯ!3EW _k̿D޿"/A?QcuχϙϫϽπχzDTu_|P $ߚu?R!qL,R ߹%iI[mG5!Ti? 1CUgyUzD}"Tu_|#T 3Q}"/q}"3'# :u7);eVhzRQ?^s @@Qfep6rCDCH//)/;/M/_/q)#@HtKR_DgD @@)\(E%\U) tnU)sKRSJS_qKRSWTSZC?U?g?y?????8PrN?OM$@(Lq;MLHXK@#@@@UJq8@Is?P>JY)TsR?vCIu __acv._`rHIntention ins_tance @$O6OHOT-?Qcu8Jjr(G$oZ_@@p=/ ףcU _W"on2Qo x ҵϰ޿&?{\n0(\@K~d@#$ "@B$ $-> 8-$H4@ $$?R PMPage-1Black fill}White uRed Greeun -Cya@Yellow GMnta3ay(10% x line3 Long dash1"darI9e. X5 7 9 1pxlm9mHairqShort Arial ckeredtop leftT/imesConnectoroSide s%!;vable!(/bottom3HQ 0Q !rQ Q P!3 W3i i i Ui i i xi Uhi Xi Gi 4i $i i 3U ӥ U r Ud U G < -  %]t"(\@K~d@  !u O ^ fl 2@B -f&y< g(y@q@(74`?!R P$4T{D^& ! `$BO7xPR$I$ "8)@/'R ()$d}9p pK2F?wp*&<@ -$ bࡱ> o!J(    --$%%-- --$-- Arialwww -"System%PP&w- . -!Graph-like ptr.X- --$Qcc7Q7Qc-- --$ccc-- -- %=-'-- $:Q::-- -- %-'-- $-- -- . - ! Operand nodesrK- -- . -!Methods of the intentionlp- --%X-'-- $UpUU-- --%lZ-'-- $y\cp`Ry\-- --%c^-'-- $cpRc-- --%DZ-'-- $Rpx\R-- --%^-'-- $R%p cR-- --%}c}-'-- $}o-- --%2c-'-- $  -- --%c` -'-- $lQWl-- --%c -'-- $ -- --%c -'-- $-- --%u-'-- $k{k-- -- . - ! Intention !instance&- --%m%v -'-- $a+}7ua+-- -- . -!Declaration of intentionx- --%\-ࡱ> oVisio (TM) Drawing R ¸$d !fffMMM333#q0#T d Arial) -3Times New Roman5T?? Y@-1,,J/T  hTJbOSS0{Gz?@CPjV]uVbUUO OS? T666 NP U    UvPaC G#G#G#G#G#G#xG &#O`$$!N=4!>7i>}p'0U2?E! 67gjP>603206&0B!4?6@27Tg2k=\- g2 VT @9ܯ6L^pu )5,2?Op??ZX F&m0#P@w?l_?VCG MO_N9{OOOOOo2qG`?FoXf.Xf RrjrjrgF_ _) ]__qgaopsoon# h0T_o?u5e%wv4Rpc{r@u";@ B U ` ;@ U#'/U3C@;?UGKOUSp_U%@ g!k"oU#$ %{&_'-( @~ yJB Џ}h1#5G~P (~` %7~ y~p '~  i{ ~ :(| [mX?xjQtCU&KPJ3~ϐ} _q ߔm5L߁ߓ~x as~  (~ Qcu~h ~ASew~ w (~w1CUg~w~w"!/3/Z`aO贁Nk?4A&&NT /////f /0e?+21?C?U?g?y?Q? 2#E?+2????O/??4aOsOZaOOG9fOK\* @R_XNa^+|5 c(_rtavwTiiPa<\'2rR9p=qIfqb":Дi1j`aePV?oU03b0f[r iG !______8~hTq"ij@/d~o{ogiSBeiwd6oHj_%UkkhJ{ooo 9BT*orooe##5GYtoo1 ˄/Տ /h$M_q}ݟ% @I[mf%ѯe|);M&@BϿX!V@q 'R ^Mw_R8i!0'2"q?OR%}%-2! F! #-3 } S fGS+WS2HmSs(#%&)*,.0 1 3 F hTA@* ?<I?NXfx** <Ebb{b b NeH u 3ς;%%73;}NNK^`[p6RO@>>3 38Drag & drop to add an arrow with a 45-degreehead.H"'=hT@?, 4F?P-DT! !u `u `bu `u z@Gu?@xu|u` Hu  b X#b ,@@7?t+@.>y 5 ## L@^! 6" F) FP>d/Q(d,kR$ R,; 9`Qps-8R? -7@ @Q&@=g0 q`(C) Shapeware Corpor?ationa0Q&kH }  tN`_s@1 6s:<4l U]%a1d\++/D"2 W@V@et& r=L!)eFp= חpuK?C|AG} G!Nv'QHx@C@eFGxHYHxO3H)J\RW@SPGq>PUPPPP\ 'd ]^F@3F_5bZ_R@(@ =a}? @Ob-=FC&(W@yaxbW@5}`5Ebb`!ubD??@Gi6࿰:m?H??f<43}p- F(#W#B )Wߙ B(Ww>G@/XSHHWYSv+B*W@F hTA@* ?<I?NXfx** <Ebb{b b NeH   3;#_;/3*2 ;󻻰2 3G3 0EIφTI;󰋷{r e V@ G8m *& 37Drag & drop to add an arrow with 45-degreeheads.H"'=hT@?@?@4=4?P !u `u `bu `u z@Gu@xu|u` Hu  bw ,Q#z @4@v5@^5n !5 ## L@! 6" F) bHP>d/Qc $( R,; 9`Qps-8R? -7@ @&Q(-DT! @@=g0 q`(C) Shapeware Corpor?ationa0Q&nH }  tN`_s@1 6s:<4l U)w#a152F+/" W@V@@o%%U@r=L!)eFp= ףpuK?C|AA]I@!|COGnGLO)w,(A!=OO_AH:A)F?Q _x@CAeFWxH_iHxO\O cW@SE`a !ª_`_`Z_`)_`W`W`W`\:Nd q.e^F@3Fo5bZb@(@ a?{ @b-OVRS&4W@5q4r4r 4r4r 4rXA59p5?p5Qp5Wp! b??9i6lӿ:m?:?b }- F$W#B ,W+ B p)WC=G@(WHƿWc+B(-W6e,!@u&# ? ,Gz @_(\@% ,Gz @_(\@& ,!@&) ,!@&* ,!@& ,!@&. ,!@&0 ,!@&1 ,!@&3  @B h(W~ 8)W,P+W\'B #3X32g-WOgЃmg.Wg@gF hTA@* ?<I?NXfx** <Ebb{b b NeH ( 3: 33󎻂߻34w5B3J V;U;Il@ Z;33;@ 30yP;3237Connect the side of onbjoanor.H"&\h_T@@, ?> OP u `u `@ T >xub?u `u q{u` Qu b  A@ )F4@O?0V)9chZ (8L@V,@OAJ&WI\ Q%Z%%a " wr}'`rL`-@R& @& /$| u`.J' ' V 0O贁Nk?gk'!bd4 d3 a0 !`(C) Shapeware Corporation+hP{lUxI5E10*+S v !@  &  0RA@-A[r xCr %(BTfl`}%x& F/#-3% ,0%SHS\+m !": M.QF hTA@* ?<I?NXfx** <Ebb{b b NeH J <3󎻂3;󿇻0 M; jn;9 A 30ߙ;u 36Connect the side of onbjotopanor.b?6i6S?E8?5H"&th_Th@@@\[?,=,n=P u `u `bqu `u z )xuu` Qu b A@ {  +?@.؂-؂@,@@99?6C"C+q nwanL@%P AQAI ?$& %?b DL`;-@& ^Y u`.@Jr| ! <+0O贁Nk?J'ml$$b4 3 a70 !`(C) Shapeware Corporation  ClU,110*7@4G+> U q }@T!u }@*E8!+5 }py#F!{#ߔ"  9#5GnS+;oS,H+=SF hTIp= ף?IHzGk?A;I1OfxK*I3<Ebbb^ b NzekG 9 +wwpwpww~wwD'w98P./wp` PefP7I[m,wZAssemble with other wave sections to create a border. Rotmakvertical .mb?пp= HzG??IRQ迀zp?G hT|@p= ף?@HzG?@;1F ?P#*o@I5|<|Eu`Iu o`b kjJ@: bY!~`(C) Shapeware Corporation0}geH H,h_T @+?6>>=z=Pt` 7]{t  u`u l_b}  !#-* B$ *;E6 $ *S]6 $ P*ku6$*(6$*J6 '3AMYeq}lU0/ae i#i Zm۶mۯ?T# - "H%~Z?@$I k.,#` ܌H! / 8t3g7=t5'%//? ?27'F?X?z/ rֹ Z@^AD u@hQ U/g/>T?>ۯ( & (E-?{?O?1>O1Og:%8_7<7Z%'E&_O_\_@27G__OXF bG mONOO^To%n¯( & (e'o_8o27\ono_s%n~Q ].o@1>&qoXF bG oNL oo(xd% & %!F_HZl@Jo&q.NvF_Jޟx_~5ZD bG N _B1%&yVF?:0oOޯOI \o/꿌T_ϠrZDbG!NGYz?1%&yER1I_|GPTGP9,GP!l! i$g?BN5Lq???04Y (*Erd#]s6o@<` @"2 0Xd ]Qu}% F-# .  +/dGSOS3H=SF hTI@IE(B??;*?N(u*%3<Ebb{b bNeN O Awwwwpow pwwp wx wpx py   w IDrag, drop, & ungroup this Windows Metafile to converta Visio shape.bE(B??Gzd7:??P"3w࿀>Eȿ@?@E(B?@P;HHu` ?ruy ;,b 7  d}:5swR*rz>DI j863b ܩ!J`(C) Shapeware Corporation7 )  : *j-:&% -%T6 %c,$% s,\?IS9f/l?[GIU8f*{ #3(ZXUPsFc9Q'=I]o-}:BGJ#fZ$%yb 4zF!!& +07>DJO{STq^N@67/0-+&!A:`^pB!)${{? #!PP{OKFU @;M 4I .E"! 2 :Ay HUNS{WX"r1!2.W4B O _ q #XWS] M > 4:2)P:1'h!u0A8O 2)">2U#10)0i"j!4L^J#| M  +@U9@q5@^+@N-@@)@6/_-[@+? //{J?\?n??5 6!F/X/j/|/% /U$ P+PpQS P~U? PnQ';@7@3@/@>-@ nQ~Q]@U@)@3@J7@;@RE)]@Q,'@4?-@MP^=@qPTPS?@C@G@WO)@AU@8P21]@Be090fUEQBc<3!0 -* :1dO??j3 `;`X`h`mrvy{~uY;l[PLG-p:% uL%~{wop]pDp-p#aovOO| `sX`;` `r p;pXph| uusq`mr m#`}CV)L)pK)pOZ%pkp:XtzwFvZ<om)p\1pQ/MqLqځJ׀HIUL$}upqp_p[pWpSpOpKpGpCp?p;p7p΢3p/pqG׀:%9p CpƪGpKpOpSpWp[p_pcp:gpkpiprupvxz*mpup~p]&ppp]D-#w pґfUǗΑ*/9fUq)4r^pQ}.C-%opdu{𸵠oogp,!g@t%@%ί\GU]$`,)1ݲ}73)ܱ!;p7)Ѷx}g Opnztvye|hfUIE|dxMLkpJ!fUtkppkpI£l¢sts|fUy|qѸruxfUOђ59DѕS7fUlz 7FxQpxvOp w k&΅e!&*/257}8tiT6740-*V&$# y^KC:51 -' {urqnpg_\_hweY"M:BQ9d0s)}%#"!(.6?DrT_[ju)Opp p``=A=|`ѐ߮B| tЬ}Ѓ3ЊЋ.ЍЎЖЕДГ058/;P5c,r|[ E !&"C"!oN(yncqXCـ0:2p,)"!$*%0W;EK0s+p'rfq*|UPq ps2w`*%E`"t1]39pë2E_[`SOKG11GKOS`[_E$ a%$f߸(ǒAYg}wu@umk=Ӡ]B O "%p(+*A%=` yǰeH+滠Oدx]X\6p.pTX,>pOcNMMUP HEEEFGcVE׃Ar j a[XR UJ PYbUlu{.o-?`mr>p4l'ihnvWl K K 7 $0n@sTyk*/Pw= c +9>G!N8UK[[`gcneqfujxpzx{}W|;3+mf\PB3"ppqX= usM%'M -wpje`\XUTSQ}MvGl.$όϜk}smo_&t3=?s5{(dgiвxqfk |tjpT  \dccd1SDp1BmiSgZdJ_7Y RKB9/$b<5PvO)jS}?w/r#om 2e%K 1jAUul|+Qx>d'1:CgJ9QLWW\hWoarbIpww=vytqIlEJxh?o~w={QoUE/]3Ձ]A;sQVS)]1@NQdkMoA^RD5$ػ%ĕ࿫ Q"S O p:wOv!PWQ WaflUsz॑q౪຿»!>; XyqಏV!S O G q X}<٪ѿ๪p,%wY>XW}2zzyEJQv!~1{ sI}~ vlB4AE'#~9z5t#n -^ULgh8B-" Y3u^J:.&B @ @Bk//B0I֯LHӥqB0S qЈ_t%Ыi7PO}Ap_p paw]IyWg5ԃm"QOp?Q%_1_C_@U_g_OOAAS ,}'i":/Mb+fPna(o__fa%ko}ooo1oCoA]Srp͵Po@rq,oojq%ox*<O\o^pxi_Mu`}N76oc6HZy@h:5- g6}p F}E3# 3 4WSGMS+SFN-WP.F hTA@* ?<I?NXfx** <Ebb{b b NeH U G3: 33߻1߻;:@3E@;:o [3`;xy3 03?}ϰ;󰋷  j"ix`ly `ZtEY EkN|9 903JMove control handles to customize the shape ofarrow's heads.d tail.mb?7i6l:m?8?H"w'}hT-@?, 4*FP }G(  u `u `bu `{u !@u` Qu@b|:z> > Y> 3@,p.+?q,nt؎:L@ ." ! tnhaM WaI@  tN`_s@j! o&pjh(:ba$ P>/Qc J4QR1< 9%`Qps-8R? y7@ @&Q(-DT! @>!0 `(C) Shapeware Corporation]4}lU"M'Q# Q -| ,3R e@d@n,4$r A("e@AfE@qG4EOAIEB eFPqGI3re@Y A8P]DeF$PPqG|I0U9X|PGVeFPqG( "1QJ`^c@@A0P.1QSZQ tNU|R>SQdh7JRe@>S` ~R`}(``U`J```^ p HHA$tOo`ظTF}FPB 1:)g!:_$N Y3^C|QhCQO'~9A>QAYbAj|w8QhCDQע;;}! FP#} Q R[SGSU+KS+HMVF hTA@* ?<I?NXfx** <Ebb{b b NeH u 3ς;%. 3;FLU&][\]PM.%38Drag & drop to add an arrow with a 60-degreehead.H"'=hT@?, 4F?P-DT! @!u `u `bu `u z@Gu?@xu|u` Hu  b X#b k,@5,+D,> 5 ## ~L@!/ 6" F) FP>d/Q(dK#$ R,; 9`Qps-8R? -7@ @yQ&@g0 q`(C) Shapeware CorporatOiona0&kH }  tN`׀s@1 6s:<4{l U%a1\++/"2 W@V@@*3ߐEy~' r=L!)eFp= ףpruK?C|AG} G!Nv'QHx@C@eFGxHYHxO3H)J\RW@SPGq>PPPPP\ dķ ]^N@3F_5bZ_R@(@ =a? @b<=FC&RW@yaxbW@P5}`5bb4`!b??Gi6࿬:m?H?}%;ˆ F^W# 3q }-jX>GSHSm+m\; _p4B)W/SW/8W?R 'Wh/!z_$&m_p-u_}2| Pk_Vo_Q\q dE_=,>Ykc:\visio\template\ee_basic.vss* VOs calOloutgOas|block*xM/,/!lipar4////?/*}/&?8?/\?/ flowchc$ - ???K??o?order3**9@x**HE@5@C!D?U@&@!F/T L*hGTIGz @I(\@?[?A I FRIzbbb b ߓenHJo gpWxooo"o* o2{p:] oB oRpZob oJojororopo隓#o.oopwoowoooEp/m m l!Um m m m Um m m m Um m m m Um zm rm jm Ubm Zm Rm Jm UBm :m 2m *m U"m m m m E4In %& '%"AHPjg@RQ?@{@@}U\@@š }ǣ?Z4O0PD?!u `u `bu w`u 4c644@I0011004w 021 0@3:u`?122%@JuNE & %@p= ף~P5@@)\;@Q4@ 432ABN%CI@OhFqFzF3E$W{l_UXg}a?PaEQJP!!A0FLA@BKZ7UVؾ?c6Psnl@h[@z_@A/SBGQU2: 4F [5 d5@B@4@| D8Ho"o4crA5@T W~H31?!?3?E1{CEX?j?|0MΊF\P1???? ?;O>O!^G1a @rs"ArrpwzD ExOABuO_TArOsAPAr{[s_0_B_T_f_________oVo,oHolo0@RP@+MPbtߘS-P??j??V?O?t iGUI̐ Oc4@33 UUa/@@a?"( @ ^PgP Q^PP!,[P_RpPgPPmVPyT`///?5$3 &,55?G?9HaHOZKt@qRF^W Ba?>QP+ұPzQfQ`0)O=h]20ookY . OOO= ףp=Ep?@ ?"*_|0Y##3, !A,___ZRp2 fR rRQۂ쀛QyQ__ oo1l>HooP"3]h)ooooo꾟B^pBw@@?(\BF#X#EL>_] Ԅ mQrR Q.);M_ozhpfh%i?Y 1ٯUtאPƯtw+A'5Lw`-T&YS8  fRrR|_RQ(_߿_Yk}Ϗϟ.Jw>O&8\ P'm#\YPHϾaHT@@(h@@}U\ض d%7I[mߑy@<$eڔ8sCede5Jxy|:@EWiǟٟ Z5K(6 +a<x#8 C&=2Ȧ`ҩc3/?Q-?oXϿ}O-A H<2pJ\nykPxPb#Yk}ŏo KCUgyV/h/藿 (8ӯ/( ( -&ą/8H?5H?Z6ҩ[o?????O)O4B OwOOOOO%__2_D_V_h_zXP~]X!2%@@@Uֱ5?Դ_1z¶ 3cյ`}h:†!lpo\~L@]ߜbfPؘaboooвӷ+ Ұ\߀π"ߤ!m0aprogrammer's contributionv~@@?X%ʿܿ1;+@π\nπφcEdLϦϸnߐ@Dh(Xother )s5'5__Z|%R?4c@@.O!hpkGakGPR\&u `u `bu `u D'f#` 0. `a=O[/AO3k@OW p!x/#z)q /0bL%=hZ 3^%I`0O贁Nk?e87$baΖo>ba\+=P0tAH2'9KWci3i0C{Oag 0/OB /2/D+h5c-@P"S%n$BCB"@C_!Y^"o_()(P))??%?7?I?[?m??80N??=??OS[ wic{DmOOOOO`OOěrO_D%Sɰfn$rsr"kQ'"=vp___oo'o9oKo:n{oo=ooo|e?;fi̓{!3|*<N`rG}Oiz1| ihi"߯kQ" 绠)p͠YPӏ @8̞I[=FXj|@@HR氭 STAKl$Ҋ!=\n̿Ϩ 5ߡuO/߅w* "z L^pϴT_Sϩϻf=Y*<߂N !bt߆ߘߪߜj<`^xd(+24Gz @(\@%&' ;"0!@&()* "< !@&+,./03456 0!@&)*2 "l@B &Wv2w#+ 'WW&7/+XCU7D?n@@!&FT L*hGTkI!@z&@??)A zFIzbub/ b }'enHo gptWxoow"o* o2{p: oB oJ oRpZob]ojorpzoropowoo_% % $!% % % % z% r% j% b% Z% R% J% B% :% 2% *% "% % % % N 4InU)*AHPjlg!@ $!?-?P &&& &| :u`?T1Y2_0ue96   L@[Wl_UXtgIa0E30!!{c7_0Q7"A| {!XگGy݋P:H [m< ٨h尸w¸? /8Կ .@(Igyϋ6Š¶vn?Q߀cu߇ߙ߫v );MMY;DӜ鰹F¸1?c>bd@5G6;EX/n.„/cC#+=Oas F  MYl~¸Mjym @0dB(//6.ͰBCB&_<^$R_/.// ??.?@?R?d?"o??"???- FXoW|>OPObOtOOO@Ò`Oe~rOOU ~r}s~r S_s______oUo3ow?io{o#ooo-`!˿'9K]7Ȅà`p^" HT+ɣu_%+ȏڏ"4F as-O%O @-?Qcu.VҗqŹʯ-VU "V_N`r@̿Bo/AS-oXj 2߀D$qŧ߮؝I$# "$- .@Rdv@5!erτ,O " %PN4gݥa>Q" d?""3o7#: 2DVhe!@RoD/V/h/z////// @R5?J89?SQ?ARS 2o"R]c=gScj????OO$O6OzZOlO~OXOOO2$`#@@Qfs2(D?CH_$_6_H_Z_l_fpP_R__SU2%%U!DaRQRÁeqˏm͉"􏾨?Ey%تj!@ooooooo޸~2DV}gp(k|~}x1v\A$$@@U2%p?Pz(QQ4 UgsT|PL@apPJӚxܑ ϴ6ϠZԙWijT4qxIntention instancecpgyH@;6xB (D(P('Q ,>g(2U$T.&ӡ0օWmj$Ht ї&RdV|xH۟CV}i"=ON1c>p߂ߔߦ߸"g2$#ق%;QH.i#!3Ei,qD@VU@,FT L*hGTkI!@z&@??UA ?zF,Iz%bb^ b NenGHsww wo Nr"x* ww2 w: wBxJwRwZwbܓxjwr]wwwwwxww]wwE.x!wxw#w$ww%w&'(w])w"$*{+B : !* "    k c [ S K C ; z r j b Z R J B : 2 * "   ?)J4InF,.W/0345 6"- GBNf @ @^!#@@L?!?45?P(-DT!6666 _WU^wU2 (_40O3L`wA";0?Agio3>?_P *ZAyl_U0*Wm۶m?UPtU@~L?@$IP;W S{ZvQwP{W0UWtU_YtWՋ0i@W!UP`0[_Z˳_U`]_{ZUYUW@Pe~o_Vao(i5olo1pWo4£o{`]o1ro(i\@}wySo(||Fp%vodx'job%_@Njdfq _胪(iɏ;_R%"U^ozRV%7Œ(g HgB"4O2ig!8U U U U;] BOΦ צ :u`?8=Cu I5B  ENL@U@YDUVXE1aϰӳӰCG0BCc9gB9 EզR ίBT͊xԜ Ir~Aza_ai#`*c:nVersion ControlwXTm 0sT?Gi;Lՠ"5ަ 4K(4JSFOsYDUV5ֈ?@Loޠ.Pw$$$^daM*u0#jF.sڣGpoTransact8filevLׇJ\?g.#h9wͯ߯.C_q8u@U|Pњ@п@!/ASeϯFπjHDisplayrnxz$#5GYknр:2@1!2$6HZO(O?LO#aEditor /;mmand processorG05!A=!0XAsP =!@@QPTйֿ(?UHU#QUڿ^)?:Z S RSx5ٝeDrAEA0R3o%bPT,TQP_Pj0ЂtդPc^P_o,Z0t` R:D`tni!`y!@@檚f f %V@@ozfԖv ~ezb"O z6|J|ozfv0r6 +%wE(—o}s% TFl~c`:jX់4BTFXeܣ/r Sc|v+zN G Rh! s_htpUKNP@E(B@/% P?vecᭃ+ r 4/F/X/j/@//϶////??kV=4]I?[?@m????qO  ??OObO'OKoOOOL)ebuggerB` Wi{߾D!ߵ'9K=4l~9 6); /./LXReduction` (:} bas ʯ  `2+=@OasS/ uBD/Oh/OXOOx///,V@Standard code generato ///Ҁ?+?=?Uc?u?????P`b??O!O3OO_ CrOOOO_t(_&8_J_\_,~_d Linku©[_`WJ f!ƤL!`u `u `buo `u ӄQe`Vq `.9Yi`\ocUnooSqRTUƑhΟpЙǐ ȐY`@h! Y`cpce^udo ~؞Hڀ7`Hj_I ![uV׶ foe 9Kk?XXjIJvoooooίRүvi`ύ# -qQH, ?PbtT?ʿ o/ASeEߩI6zZߞ,j|ߎ ߼#7I[m:K4ReiIvFXj|/@/d/ 0օ_ّ_uRd @@VU41&@k@X42U?D4 0d35 E52 ǿj2 '9qP/$/>4[OO/OC7O/)OmOOYO_I T64B!HUser contributed portionf/??5Y@@R:8PF> c]?"z4U? fbP?jqb???OO%O7OIO;_M_OOODib_/Y4@ ]_o_Y5henzymes previous{lyPmpilPfrom source treePR. J XXkX1@@Y T0 <<+!Uք z2D.`kݰJ -!u+g  tN`zs@A s'ݏQ``uXI~=dk-Йp@*?3Ey;)Gp= ףpDN6e?@QqG)3 l X D 0 ?|R (T,s YdPQD5tsN@}v^<___ƌPXv oo.o S\oto4B’ooooooo~Xߎ9ρϥG0B. OBJ(#؟?@q##Յ7 RԆpY/UП*??%=A6?H?Z?!x5Ff9$-DT! ѳ????? O`$OtbBOTOfKGntFbcbe{~"( PX7*C;p#_5_G_Y_k_}___ .___,6oo(oW 0;f` P!3|~oooooobрoh"fK}E3I"_(D#OPg#s(/ASw# ] ҏLi]oMhޟfKFf]uŠp-(@/d/v/(:~ k}B]!Ŀ:iy5Uakn?+=OasMmhYϾ4zsFYXYp'/+(C U.ߝ߯ 9K]"nֿa?(P\3K /AC;\6D'"zJk"D'"&#'"/A.p/g߫[m X]#<N`I/@-/I/[/ a @* Ց1RBu+#zB1RS0S_ 1RSW:SZz+?ӯa?s????go??˃$ @!O#KR2H>KBvee?gX{lCt??T@`*/ҔrH/_l$"Lc L@-a 5eX>D&HbTbRodovjpWaՐn` zwe,vKaa%@aM @[rzCGOZYh^:"9A$HStandard Debug Ke/rnelj% Oo.O@I>vϋOOOOO{ͣ@l+-) 1(<i?_>?P?0oBo2xo ood&ȟ rIU zO&8J\nJqn]Ұ¯l+z&$]\] (sZ#52ſ׿ 1CU1Q'rτϖp?@lv5v^H?"4Fߏr?@`<$+~ߐl+ Ѐ!+*+"!"(r"r5,za B=(@Rdy IU?@w_H,#D.t" L^ & $w"#"??QU>HBk?Y sZ p-?Qcu,.m)/H@IUS[:XLC? =GW/i/{////{@/tgR//ڀFFgRfSgR_-^|2 oXx?vvAAPwvw-|23;a_AI{-xo|oHoٟKoaqD@VU@FT L*hGTkI!@z&@??UA ?zF,Iz%bb^ b NenL*Hogxo o]oopo oZ oboJoR  orrozG] oooo}oE E D!E E E E E E E E zE rE jE bE ZE RE JE BE :E 2E *E "E E E :E - 4InU)*AA HPjg!?! @!54)7?P 666 #6:u`?1u9>6    02 L@[}Wl_OUXgIWa@C@!!727RA00lB^4 7@O3YL?OMA0MOhROO Irk8P L^$6Ϧ 2ǟٟ럫Ͻ-y+vaB` 2ߖ௒O߶ODOOJT/x/X 2?D?T???IcP][djbpbuχϙ OO}OOy+vr߂OODߎ@_do$_6_H_ @A /v_/_X? ?__]?o?#o5oGo>ah??? oo+=E RpO0BOO2V@zJ d_t_9𭆸__ڏL;N_o!3EI2b …oo@o "4Tϴߒ(į֯,N@ bGz6ȏ|>O9M3ǿٿ[4w[mUI bFFbr߄ߖZV (8L6Xjz Ynm` qf%7IM_?UI bFO">߀/T/2//dvߺ/ &8! g'g'P-DT!~!u `u `bu w`u +DI2D&D@[t1 `&@-AfA5@2@qDd0m`\nBn^FE@@ ECBA1_CY@/_F?S@000{>?8\Db/0o 5%j%//t>G8/mPB60H???&?@Ff8 G"O4OFOXOjO|No`O@D[rOOKoEC[rZs[rR+Q~@RWXss퀏_______@ onh;oMo_mpooooOoooo 0BD=^D)|vD)()R+Q@R˯%@坰]oɏۏ #geGQ+FVUR5N`RU`c!Y^Qŝb ,DJ`I$*0Pv?//Zι/9ߋ w1iW:0:0:0TB84VRS1jCode of method instance0 >Pb?(?OOҟ~H WqA5MM@ r_Q*AkAQv z-?QcueW﫿!o/Dic 0r#%ʟ%ҟ%|M?,"/dXBϢDj"ո< *f'?K?a?;$Mn am,9`#@@QfCDr;DCHK]o/@0R%9!, +#%,)NPfRSS|_RSW&SZ+// ??= ODN?}-,0B̬ qXj/1 uϹOO _`r"4FXDoo6?2?V zD@,@xoooӃ r:@@r$OfΓ!pؓ*pΓ3Eqƕ<ϕJؕ{@s ,חߗ7g @3EW!Declarationsinten<?OL"ϻ9Ր^"x^Å9MŖI:/1_Z#BTtPPW@/3oۿ"w*Cˈ֨?GQZϡ1L/J +.)fL?ߣAVm aV[a:ageơ8)R a"c﨟`0*Kw@t`qbˁ/t5 D1/3 /G ,BTa"Ra__'"/ߓߥ߷߀?I%m????6GW{ a$ &8J R'2l!2'2'2%'0)/o//' 7;W9u2J//?'2'2$6Z~0_T_p)HQ$?un ̐DWDWP-DT!3!0u `u `bu `;u ldlt& sdgd@Q `g`naav`s`dSOeOwOІP rl<-%e@@($`*Ks;pVQ r s1|0 rswszzOOD\LPFOO _\ (@0o_ZWPH`k-@@`╨A)1oo/o@ʯܯ7Ia_-_@^_0֯ 'Code@m#in_stancQ_D_u:`Tir!vr@"%Ksϵ@vi]A{QG O"bpX˶6ߦࡱ>  FVISIO 3.0 Drawing VISIO ShapesVisio.Drawing.39qࡱ>LSE/'ࡱ> ࡱ> SE ' f  B  --2%RP '6GZumP/-Hc- --2%RP ~luXPC/-}c- --&%8+XAuZu>c- --&%8XulQ3c-  .  Arialww(8w - ! programmer"System(8%Pw- 0--V$)!0@Q|czt|(?ThztcQ@0!zhT?(--  . -!programmer's mindvDa- - -%'6ETc-  . -!programmer's intention- 0- -$h+h+//h--  . -!GUI- 0--Z$+JKPWboz~hYNFBBFNY*h9zFPX\^\ X%P=FT9i*z~zoibTW=P%K J-- 0--^$-/ .C[t#6FS]bd/bF]]SsF6#t[C. s]F/-- 0-- $-- 0--f$1oU <&0DZr'&7<EUOoW\^\WOE67N'dxrZD0xd N6-- 0--$??hh-- . -!IP !kernelQ- --$}77 } }7---- . - !. EXEt ! the desireds !program- 0--$^,,**-- --%r -'--8q}[xyq0-- --%yb-'--8bqzp^0Up-- 0--$ Q <  <Q-- - -%- - -%WzfUuzUzU- 0--$ JJppp<p J J<--  . -!programmer's contribution8-  . -!other programmers' ! contribution ,- --%7to-'-- $hzsh-- --%\0=-'-- $*6=62E*6-- --% NP-'-- $WWHW-- --%6Jv-'-- $Q{?EoQ{--  . -!"-  . -!"-ࡱ> odula-3. ACM, 1990 KAELBLING, M. J., Programming Languages Should NOT Have Comment Statements. SIGPLAN Notices, Vol 23, No 10. KOTIK, G. B., MARKOSIAN, L. Z., Automating Software Analysis and Testing Using a Program Transformation System. ACM, 1989. KOTIK, G. B., ROCKMORE, A. J., SMITH, D. R., Use of Refine For Knowledge-Based Software Development. IEEE, 1986. KRUEGER, C. W., Models of Reuse in Software Engineering. Carnegie Mellon Report CS-89-188, December 1989. MERKS, E. A. T., DYCK, J. M., CAMERON, R. D., Language Design For Program Manipulation. IEEE Transactions on Software Engineering, Vol 18, No 1. MINR, S., Interacting with structure-oriented editors. Lund University, Sweden PARNAS, D. L., SHORE, J. E., ELLIOTT, W. D., On the Need for Fewer Restrictions in Changing Compile-Time Environments. Naval Research Laboratory Report, 7847. PRIETO-DIAZ, R., Status Report: Software Reusability. IEEE Software, May 1993. RIEHLE, R., Objectivism: Class Considered Harmful. Communications of the ACM, August 1992, Vol 35, No 8. SAKKINEN, M., The Darker Side of C++ Revisited. Structured Programming, 13: 155-177. SCHERLIS, W. L., Abstract Data Types, Specializations, and Program Reuse. SHAW, M., WULF, W.A., Toward Relaxing Assumptions.in Languages and their Implementations. SIGPLAN 15(3), 45-61 1980 VOLPANO, D. M., KIEBURTZ, R. B., The Templates Approach to Software Use. Software Reusability, Edited by Biggerstaff, T.J., Perlis, A.J. Addison-Wesley /=he  RTce<--2222444466r?s?y?{? \\]]'](])]*]__ebfb~bbbbjekeggpppwwwxxxxxxLgES):hijkſe uD3KuD3avKJ uDi93KuDi93avK uD.3KuD.3avKuDhVU[ccUcUJ/abz{|}$4%& AFM S   ABZ[\]$++=2P2778899r9y99:G:T:: ;o;;;;a<e<<<K=u=>>X??c uD.3KuD.3avKJSc uD3KuD3avKuDUcUVR?? @~@@(AcAAAB B`BoBBBbCfC0DZD2ESEEEEEIF_FGGGGuV