| J.Ichbiah, Barnes, J., Hliard, J., Krieg-Brueckner, B., Roubine, O., Wichman, B.: Rationale for the design of the ada programming language. ACM SIGPLAN Notices 14 (1979) http://www.lgi2p.ema.fr/~fsouchon/sage_applet/sage_applet.html |
....even though an exceptional situation occurs. The end of the 1970s saw the development of exception handling systems dedicated to procedural programming. All specifications have all been influenced by Goodenough s seminal paper [7] Well known implementations include MESA [15] CLU [13] or ADA [8]. Exception handling systems have later been integrated into object oriented languages at the end of the 1980s (Zetalisp Flavors [17] CommonLisp( CLOS) 19] Eiffel [14] Objectworks Smalltalk [21] C [11] or more recently in Java. This papers presents an overview of the specification and ....
J.Ichbiah & al: Preliminary ADA Reference Manual. Rationale for the Design of the ADA Programming Language. Sigplan Notices Vol. 14, No. 6, June 1979.
....of integer expressions with real (floating point) expressions. In these expressions, integer values are converted, when necessary, to their corresponding real values. Another example of subtyping occurs in the case of intervals of discrete types, as in Pascal and Ada (see, for example, JW74] e [Ich79] An interval of a discrete type oe is a subtype of oe. The interest in object oriented programming languages (OOLs) brought more incentive to the study of some aspects related to subtyping. In typed OOLs (as well as in languages which support some form of polymorphism) type checking is based ....
J. Ichbiah. Rationale for the design of the Ada programming language. ACM SigPlan Notices, 14(6B), 1979.
....level of a task. If an uncaught exception occurs in an Ada task, the task terminates without handling the exception or passing it on to an outer block that can handle it; this policy was chosen to prevent the problems that would result if the exception was passed to a parent task asynchronously [9]. The designers of pSather chose to forbid exceptions in a concurrent context [5] 11] 14] These solutions deny concurrent programmers the expressive and robustness benefits of exceptions. Programmers should be able to use exceptions in concurrent constructs as they would normally in the ....
J. D. Ichbiah, J. C. Heliard, O. Roubine, J. G. P. Barnes, B. Krieg-Brueckner, and B. A. Wichmann. Rationale for the design of the ADA programming language. ACM SIGPLAN Notices, 14(6):1--247, 1979.
....level of a task. If an uncaught exception occurs in an Ada task, the task terminates without handling the exception or passing it on to an outer block that can handle it; this policy was chosen to prevent the problems that would result if an exception were passed to a parent task asynchronously [12]. The designers of pSather chose to forbid exceptions in a concurrent context [13] 14] These solutions deny concurrent programmers the expressive and robustness benefits of exceptions. Programmers should be able to use exceptions in concurrent constructs as they would normally in the ....
J. D. Ichbiah, J. C. Heliard, O. Roubine, J. G. P. Barnes, B. Krieg-Brueckner, and B. A. Wichmann. Rationale for the design of the ADA programming language. ACM SIGPLAN Notices, 14(6):1-- 247, 1979.
....level of a task. If an uncaught exception occurs in an Ada task, the task terminates without handling the exception or passing it on to an outer block that can handle it; this policy was chosen to prevent the problems that would result if the exception was passed to a parent task asynchronously [6]. The designers of pSather chose to forbid exceptions in a concurrent context [7] 8] 9] These solutions deny concurrent programmers the expressive and robustness bene ts of exceptions. Programmers should be able to use exceptions in concurrent constructs as they would normally in the ....
Ichbiah, J.D., Heliard, J.C., Roubine, O., Barnes, J.G.P., Krieg-Brueckner, B., Wichmann, B.A.: Rationale for the design of the ADA programming language. ACM SIGPLAN Notices 14 (1979) 1-247
....13 4. 1 Resource and Communication Deadlock Models Many deadlock detection and resolution algorithms are used either in solving resource deadlocks [3, 8, 10, 13, 15, 22, 21, 25, 27, 28, 31, 38, 42, 44, 45, 48, 51, 53, 55, 58, 60] or used in communication based systems [8, 29, 47, 50] or both [6, 30]. However, the distinction between these two models is not always clear since the messages could be treated as implied resources and may not be distinguished from physical or data resources. In resource deadlocks, tasks access resources (for example, data items in database systems or memory ....
....the deadlock condition in the AND OR model. In principle, deadlock in the AND OR model can be detected by applying the test for OR model deadlock repeatedly, where each invocation operates on a subgraph of the AND part of the model. However, this strategy is not very efficient. Hermann and Chandy[30] proposed a more efficient algorithm for AND OR deadlock. Their algorithm is based on a hierarchy of diffusing computation which they called a tree computation. The central idea of their algorithm is that when a diffusing computation reaches a blocked task: 1) the diffusing computation is ....
[Article contains additional citation context not shown here]
J. D. Ichbiah, J. G. P. Barnes, R. J. Firth, and M. Woodger, Rationale for the Design of the Ada Programming Language, United States Government, 1986. The Ada Rationale was developed by Alsys and Honeywell under a contract from the United States Government (Ada Joint Program Office).
....in which treatments of declarations and executable statements differ across languages. Sometimes these treatments depend on the styles and choices of compiler vendors. For example, when Ada code is compiled, all declarations get elaborated [Ada 83] and elaborations can generate executable code [Ichbiah 86] In fact, Ada requires that the effects of elaborations must be the same as if they were performed in sequence at run time, although decisions as to how these effects are to be achieved are left to the discretion of individual compiler developers. Static compilation of declarations is permitted, ....
Ichbiah, Jean D.; Barnes, John G. P.; Firth, Robert J.; & Woodger, Mike. Rationale for the Design of the Ada Programming Language. Minneapolis, Minn.: Honeywell Systems and Research Center, 1986.
....at all. Many language designers insist that the terseness of APL programs is a source of significant problems in actual use. In the Ada83 design rationale, for example, keyword abbreviations, such as proc instead of procedure, are avoided : since we believe full words to be simpler to read. [3]. There is currently little strong evidence either way that languages with shorthand notations are more difficult to read or write. Several successful languages, including C, C , Java, and Perl, are viewed as cryptic and terse by novice programmers. Nardi discusses the goal of making ....
J. Ichbiah, J. Barnes, R. Firth, and M. Woodger. Rationale for the Design of the Ada Programming Language. Cambridge University Press, New York, N.Y., 1991. ISBN 0-521-39267-5.
....interest the non specialist of object oriented programming concerned with the problem of exception handling. I. Introduction Exception handling techniques [3] 9] 12] 13] became an important issue because of their implications in software engineering: faulttolerance [13] 3] modularity [13] [11] [19] 3) reusability (by extending definition domains and functionality of operations signaling exceptions) and readability (by specify in its interface all the possible responses of a module to its legal inputs) Object oriented programming (OOP) and design (OOD) mainly initiated by Simula ....
....for the exception; knowledge about it is embodied into the expressions associated to the label or into the procedure body. In such systems, users have no simple way to define handlers. In most of the important exception handling systems that can be found in procedural languages (e.g. PL I, Ada [11], Clu [13] Mesa [15] exceptions are identifiers. When an exception is raised, a handler that references this identifier is looked for and invoked. A common characteristic of the above systems is that knowledge relative to exceptions (even the most general one) is uneasy to grasp since, in the ....
J.Ichbiah & al : Preliminary ADA Reference Manual. Rationale for the Design of the ADA Programming Language. Sigplan Notices Vol. 14, No. 6, June 1979.
....increasing the flexibility and convenience of modularization constructs. Unfortunately, in the shadow of many exciting developments there has been a tendency to overlook the original purpose of modularization. Some language definitions specify what are to be the compilation units (e.g. Ada [12]) but others do not (e.g. Standard ML [17] A paradoxical question then arises: when does a module system really support modularization (meant as separate compilation) In designing and formalizing module systems, many proposals have focused on the analogy between modules and data structures, ....
Ichbiah, J., J.G.P. Barnes, J.C. Heliard, B. Krieg-Bruecker, O. Roubine, and B.A. Wichmann, Rationale for the design of the ADA programming language, ACM SIGPLAN Notices 14(6), 1979.
....as classes. The first issue that arises for either the user or the implementor of an EHS is the status of exceptions. How are exceptions represented and referenced How can they be manipulated or inspected Exceptions are usually strings, symbols or variable of type exception (as e.g. in Ada [Ichbiah al79] that cannot be inspected or enriched. General knowledge relative to exceptions (e.g. default handlers) is uneasy to grasp since unaccessible or scattered in various handlers. Exceptions are nevertheless complex entities of which descriptions can be given regardless of local handling ....
J.Ichbiah & al : Preliminary ADA Reference Manual. Rationale for the Design of the ADA Programming Language. Sigplan Notices Vol. 14, No. 6, June 1979.
....: r[p] x end fdispatcherg There is no guarantee that every task will eventually be removed. This modification of the solution is left to the reader. 28 CHAPTER 2. SMALL EXAMPLES 2.1. 5 Disk Head Scheduler The problem of coding a disk head scheduler and a solution for it in Ada appear in [17]; a solution in Linda appears in [14] The problem is as follows. A number of users desire access to specific tracks on a disk. A user submits an access request and then waits until the request is served. The disk is controlled by a server process that can serve one access request at a time. A ....
J.D. Ichbiah and et al. Rationale for the design of the Ada programming language. SIGPLAN Notices, Part B, 14(6), June 1979.
....and if the value at that location can change, then there is a possibility of a critical race where the result of the program depends on when which task reads and when which task writes the value. Various systems have provided different mechanisms for dealing with the synchronization problem [2 4], including semaphores, monitors, conditional critical regions, rendezvous, and several kinds of message passing. Harmony addresses the problem by a paradigm for structuring multitask programs, using four primitives that provide message passing. A message, in Harmony, is a variable length ....
J.D. Ichbiah, J.G.P. Barnes, J.C. Heliard, B. Krieg-Brueckner, O. Roubine, and B.A. Wichmann. "Rationale for the Design of the Ada programming language." SIGPLAN Notices, 14, 6. Part B, June 1979.
....occasions signal different exceptions. If a handler for this exception is not specified on the invocation of the initial signaller, the exception is propagated, so that the caller P is 5 Significant ideas on exception handling in programming languages have also been presented in [29] 19] [15], 8] 30] 11 interrupted and it raises E itself, thus becoming a signaller. This propagation up the invocation chain continues until either some caller provides a handler for E on the invocation of its signaller or the top most transaction invocation is reached. In the latter case, the user ....
Ichbiah, J.D. et al. Rationale for the Design of the ADA Programming Language. ACM SIGPLAN Notices 14(6), June, 1979.
....to macro expansion of the generic class definition. Note, however, that this does not imply a macro expansion implementation. In fact, E follows CLU [AtkR78] in compiling generic code that is shared by all instantiations. Other languages that define generics similarly include CLU [Lisk77] Ada [Ichb79], Trellis Owl ############################################################################################## class binaryTree [ class keyType , class entityType , int compare( keyType , keyType ) class btn : binaryTreeNode[ keyType, entityType, compare ] btn root; public: ....
Ichbiah, J., Barnes, J., Heliard, J., Krieg-Bruckner, B., Roubine, O., and Wichmann, B., "Rationale for the Design of the Ada Programming Language," SIGPLAN Notices, 14(6), 1979.
....Medusa provided a separate utility (called MACE) specifically to handle exceptions associated with debugging and tracing. 2.3 Programming Language Support for Exceptions Exception handling is also an issue in the design of a programming language and its runtime environment. Languages like ADA [Ich77] PL I [Mac77] and Mesa [MMS79,GMS77] provide primitives for exception handling within the language. There has been, however, a strong debate on how useful these mechanisms are [Bla82] since they have an adverse impact on the simplicity and elegance of the language. Regardless of the outcome of ....
J. D. Ichbiah. Rationale for the design of the ADA programming language. SIGPLAN Notices Vol. 20, pages 500--503, 1977.
....et at. 19] discuss the rationale behind the design of the Green language, which was the precursor to Ada. However, the differences between tasking in Green and tasking in Ada are substantial. A rationale for the design of Ada 83 was developed after it became both an ANSI and military standard [20]. The goal of the rationale is to impart the overall philosophy of the language design and to explain the motivation behind key features of the language. The rationale mentions the need to protect the integrity of referencing environments as motivation for Ada s termination policy, but does not ....
J. Ichbiah, J. Barnes, R. Firth, and M. Woodger. Rationale for the Design of the Ada Programming Language. Cambridge University Press, 1991.
....variety of Ada language text books [6] 15] describe the language in a more tutorial format, and several specialize in Ada tasking [16] 27] None of these descriptions, however, explain the motivation for nuances in the definitions of the dependence and termination rules in Ada. Ichbiah, et at. [19] discuss the rationale behind the design of the Green language, which was the precursor to Ada. However, the differences between tasking in Green and tasking in Ada are substantial. A rationale for the design of Ada 83 was developed after it became both an ANSI and military standard [20] The goal ....
J. Ichbiah. Rationale for the design of the Ada programming language. SIGPLAN Notices, 14(6), 1979.
....et. at. 18] discuss the rationale behind the design of the Green language, which was the precursor to Ada. However, the differences between tasking in Green and tasking in Ada are substantial. A rationale for the design of Ada was developed after it became both an ANSI and military standard [19]. The goal of the rationale is to impart the overall philosophy of the language design and to explain the motivation behind key features of the language. The rationale mentions the need to protect the integrity of referencing environments as motivation for Ada s termination policy. Outstanding ....
J. Ichbiah, J. Barnes, R. Firth, and M. Woodger. Rationale for the Design of the Ada Programming Language. Cambridge University Press, 1991.
....its direct master. 8 Related Work The ALRM and its clarifications [1] provide the definitive references for all Ada language features. A variety of Ada language text books [6] 15] describe the language in a more tutorial format, and several specialize in Ada tasking [16] 23] Ichbiah, et. at. [18] discuss the rationale behind the design of the Green language, which was the precursor to Ada. However, the differences between tasking in Green and tasking in Ada are substantial. A rationale for the design of Ada was developed after it became both an ANSI and military standard [19] The goal of ....
J. Ichbiah. Rationale for the design of the Ada programming language. SIGPLAN Notices, 14(6), 1979.
....immediate per object memory reclamation in ADTs. In Ada 83 leaving aside the infamous, hypothetical garbage collector to be optionally provided by Ada implementations memory reclamation could, but need not, happen on exit of the scope of each access type and its associated collection [Ada86]. Revised since publication in TRI Ada 94 Conference Proceedings, Baltimore, Maryland, November 6 11, 1994 Page 7 Ada 9X associates storage pools with access types; for each access type, a storage pool may be user defined, thus implicitly redefining both the operation new and the corresponding ....
....end UnShared Strings; with Ada.Unchecked Deallocation; package body UnShared Strings is function (S : String) return String Type is begin return String Type (H = new String (S) end ; function = L, R : String Type) return Boolean is begin return (L.H.all = R.H.all) 4. As [Ada86] explains, no garbage collection was required in Ada 83, because it was felt to be incompatible with real time systems. The pragma Storage Size was available, but Ada 83 had no requirement for memory reclamation. In Ada 9X, alternatives are offered with storage pools and controlled type. end ....
J.D. Ichbiah, J.G.P. Barnes, R.J. Firth, and M. Woodger. Rationale for the Design of the Ada Programming Language. 1986.
....of Defence (DoD) initiative started in the mid 1970 s to develop a High Order Language (HOL) suitable for embedded systems software. The original Ada language proposal, which was one of the four responses to the Ironman Steelman requirements documents [47] was refined to a proposed standard [28,48] by 1980 and standardised in 1983 [49] Our analysis of the requirements and standards documents shows that the designers had four principle high level design goals for Ada 83: program reliability and maintenance, support for programming in the large, support for a wide range of ....
J.D. Ichbiah, J.C. Heliard, O. Roubine, J.G.P. Barnes, B. Krieg--Brueckner and B.A. Wichmann, "Rationale for the Design of the ADA Programming Language", ACM SIGPLAN Notices, Vol 14 No 6, June 1979.
....persistence in Ada is not a new one. Proposed and actual examples include Green s proposed extensions to Ada[21] APPL A[34] PGRAPHITE[40] the work of Millan and Mulatero[27] and Intermetrics proposed ODMG Ada95 binding[31] Our analysis of the Ada requirements and standards documents [22, 35, 36, 37, 38] suggests that the Ada designers had four principle high level design goals for the language: program reliability and maintenance, support for programming in the large, support for a wide range of application domains, and program execution efficiency. In this paper, we focuses on ....
J.D. Ichbiah, J.C. Heliard, O. Roubine, J.G.P. Barnes, B. Krieg-Brueckner, and B.A. Wichmann. Rationale for the design of the ADA programming language. ACM SIGPLAN Notices, 14, June 1979.
.... design goal of IPL was the attainment of a high level of abstraction of both communication and architecture, the development of IPL was therefore a bottom up approach, in contrast to other top down approaches such as Argus [22] Several other languages, e.g. SR [3] DOL [25] Mesa [23] and Ada [19], support distributed computing but not transactions. Argus [22] Aeolus [28] and Avalon C [10] are distributed languages that support atomic transactions; however, they do not support flexible, mixed, or time constrained transactions [13, 27] The rest of the paper is organized as follows. A ....
J.D. Ichbiah, J.C. Heliard, O. Roubine, J.G.P. Barnes, B.Kreig-Brueckner, and B.A. Wichmann. Rationale for the Design of the Ada Programming Language. SIGPLAN Notices (ACM), 14(6), June 1979.
....immediate per object memory reclamation in ADTs. In Ada 83 leaving aside the infamous, hypothetical garbage collector to be optionally provided by Ada implementations memory reclamation could, but need not, happen on exit of the scope of each access type and its associated collection [Ada86]. Ada 9X associates storage pools with access types; for each access type, a storage pool may be user defined, thus implicitly redefining both the operation new and the corresponding body of Unchecked Deallocation. The definition of a storage pool guarantees reclamation on exit of the scope of the ....
....Ada.Unchecked Deallocation; package body UnShared Strings is function (S : String) return String Type is begin return String Type (H = new String (S) end ; function = L, R : String Type) return Boolean is begin return (L.H.all = R.H.all) end = various operations 4. As [Ada86] explains, no garbage collection was required in Ada 83, because it was felt to be incompatible with real time systems. The pragma Storage Size was available, but Ada 83 had no requirement for memory reclamation. In Ada 9X, alternatives are offered with storage pools and controlled type. ....
J.D. Ichbiah, J.G.P. Barnes, R.J. Firth, and M. Woodger. Rationale for the Design of the Ada Programming Language. 1986.
....refers exclusively to the use of object models. 42 7. 1 Properties of Block Structured Languages The fundamental concepts of block structured languages originated with the development of ALGOL 60 [30] and have since been incorporated into the design of many programming languages, such as Ada [31] and Pascal [32] Programs written using block structured languages are organized into nested blocks, where each block introduces a new local referencing environment. Because of their widespread and longstanding use, block structured languages have become a common object of study by maintenance ....
J. Ichbiah, "Rationale for the Design of the Ada Programming Language," SIGPLAN Notices, vol. 14, 1979.
.... definitions and terminology, but by the end of the 70s [Cristian79a] Liskov79] it became clear that all proposed exception mechanisms can be classified into two basic categories: termination mechanisms [Anderson81] Back79] Best81a] Bron76] Cristian79a] Cristian80] Horning74] Ichbiah79] Liskov79] Melliar77] Wulf75] and resumption mechanisms [Goodenough75] Lampson74] Levin77] Parnas72b] Yemini82] For some time it was not clear which kind of mechanism will gain acceptance from programmers. Convincing arguments that the termination paradigm is superior to the ....
....of M.P remains undetected after a proper termination of M.P will be discussed later. Now, what is a sensible reaction to such a situation For example, what exceptional continuation should be associated with the exception u propagated from a lower level One possible solution (adopted in ADA [Ichbiah79] is to continue the propagation of u in the higher level module N. Such free exception propagations across module boundaries may have dangerous consequences. First, according to the information hiding principle of modular programming [Parnas72a] the designer of N is not supposed to know ....
J. Ichbiah et al., "Rationale for the Design of the ADA Programming Language", in SIGPLAN Notices, Vol. 14, No. 6, 1979.
....Customisation requires a collector designed to be open and to delegate portions of his task to other collectors. This is a different concept from the mechanisms of parametrisation or tuning that some collectors provide. For instance garbage collection intervention can be sometimes avoided in ADA [1] by specifying an upper bound for the space needed for data of a certain type. The corresponding space can then be reserved globally when the definition is elaborated. Subsequently, when leaving the program unit enclosing the type definition, the space corresponding to the collection may be ....
....To improve this solution, one may define the class GcVarObject as a derived class from GcObject, which provides a new operator with an additional parameter for the size of the variable member. The following example illustrates its use: class BigNum : public GcVarObject int length; int limbs[1]; size determined at object creation ; BigNum num; BigSize = 256 sizeof(int) num = new(BigSize) BigNum; The object num is created in the default heap and has room for 256 integers. The implementation of class GcVarObject might be however compiler dependent. 11.3 Array of GcObjects Recently ....
J.D. Ichbiah et al. "Rationale for the design of the ADA programming language", ACM SIGPLAN Notices, 14(6), 1979.
....Customisation requires a collector designed to be open and to delegate portions of its task to other collectors. This is a different concept from the mechanisms of parametrisation or tuning that some collectors provide. For instance garbage collection intervention can be sometimes avoided in ADA [27] by specifying an upper bound for the space needed for data of a certain type. The corresponding space can then be reserved globally when the definition is elaborated. Subsequently, when leaving the program unit enclosing the type definition, the space corresponding to the collection may be ....
J. D. Ichbiah et al., `Rationale for the design of the ADA programming language', ACM SIGPLAN Notices, 14(6), (1979).
....as well as future work is outlined in Section 6. 2 Properties of Block Structured Languages The fundamental concepts of block structured languages originated with the development of ALGOL 60 [9] and have since been incorporated into the design of many programming languages, such as Ada [10] and Pascal [11] Programs written using block structured languages are organized into nested blocks, where each block introduces a new local referencing environment. Because of their widespread and longstanding use, block structured languages have become a common object of study by maintenance ....
J. Ichbiah, "Rationale for the Design of the Ada Programming Language," SIGPLAN Notices, vol. 14, 1979.
No context found.
J.Ichbiah, Barnes, J., Hliard, J., Krieg-Brueckner, B., Roubine, O., Wichman, B.: Rationale for the design of the ada programming language. ACM SIGPLAN Notices 14 (1979) http://www.lgi2p.ema.fr/~fsouchon/sage_applet/sage_applet.html
No context found.
Ichbiah, J., J.G.P. Barnes, J.C. Heliard, B. Krieg-Bruecker, O. Roubine, and B.A. Wichmann, Rationale for the design of the ADA programming language, ACM SIGPLAN Notices 14(6), 1979.
No context found.
J. D. Ichbiah et al., `Rationale for the design of the Ada programming language', SIGPLAN Notices, 14, (6), Part B, (1979).
No context found.
J. D. Ichbiah, `Rationale for the design of the Ada programming Language', SIGPLAN Notices, 14, (6) (1979). Part B.
No context found.
J. Ichbiah, et al., "Rationale for the Design of the ADA Programming Language", ACM Sigplan Notices, vol. 14, no 6, June 1979
No context found.
J.D. Ichbiah, J.C. Heliard, O. Roubine, J.G.P. Barnes, B. Krieg-Brueckner, and B.A. Wichmann, "Rationale for the Design of the Ada Programming Language", SIGPLAN Notices, vol. 14, no. 6, Part B, Jun. 1979.
No context found.
Jean D. Ichbiah, et al.: Rationale for the Design of the ADA Programming Language. SIGPLAN Notices. Vol. 14 No. 6. June 1979.
No context found.
J. D. Ichbiah, J. G. P. Barnes, R. J. Firth, and M. Woodger. Rationale for the Design of the Ada Programming Language. Reprinted by Cambridge University Press, 1991.
No context found.
Ichbiah, J. "Rationale for the design of the Ada programming language." ACM Sigplan Notices 14,6 (June 1979),part B.
No context found.
Ichbiah, J.D. et.al.: Rationale for the Design of the Ada Programming Language. SIGPLAN Notices, June 1979.
No context found.
Ichbiah, J. D., Barnes, J. G. P., Firth, R. J., and Woodger, M.. Rationale for the Design of the Ada Programming Language. Honeywell Systems and Research Center, Minneapolis, MN, 1986.
No context found.
Ichbiah, J.D. et.al.: Rationale for the Design of the Ada Programming Language. SIGPLAN Notices, June 1979.
Online articles have much greater impact More about CiteSeer.IST Add search form to your site Submit documents Feedback
CiteSeer.IST - Copyright Penn State and NEC