| Wirth, N.: Type Extension. In ACM Transactions on Programming Languages and Systems, Vol. 10, No. 2, April 1988, pp. 204--214. |
....and manipulation of processes, both statically and dynamically as required. In addition, the provision of events as a first class language feature in Persimmon provides a communication mechanism at a high level of abstraction. The Persimmon language supports the concept of Type Extension [Wir88] providing polymorphism for data, processes and events. A detailed description of Persimmon can be found in [Wri94] and a simple example is included as Appendix A. 9. COMPARISON WITH OTHER WORK One of the earliest mechanisms for integrating independent tools in an environment is implemented in ....
Wirth,N.,"Type extension",ACM TOPLAS, Vol. 10, pps.204-14
....extended with the necessary extra facilities a process type and an event type. The Persimmon language is a simple but powerful language supporting orthogonal persistence of instances of all data types, including types themselves. It supports type extension concepts similar to those of Oberon [Wir88] enabling polymorphism; separate definition of type interfaces (signatures) and implementations (contexts) together with signature matching similar to Russell. For more details refer to [Wri93] The main advantage of using a persistent programming language is that it is possible to easily share ....
Wirth,N.,"Type extension",ACM TOPLAS, Vol. 10, pps.204-14
....will be the identity on both the type and the value of any argument. The presence of variables or mutable types [1,2] have so far lead to unsafe type systems, unless the subtype ordering is trivialized in this case. A system which operationally is more similar to ours is that of type extensions [10]. However, several important issues are not addressed, leading to various anomalies. For example, just allowing actual parameters to have larger types than formal parameters is too liberal an attitude. We must have a homogeneous choice of larger types, as the following example shows. The ....
Wirth, N. "Type Extensions.", In Transactions on Programming Languages and Systems Vol 10 No 2, ACM 1988. 38
....will be the identity on both the type and the value of any argument. The presence of variables or mutable types [1,2] have so far lead to unsafe type systems, unless the subtype ordering is trivialized in this case. A system which operationally is more similar to ours is that of type extensions [10]. However, several important issues are not addressed, leading to various anomalies. For example, just allowing actual parameters to have larger types than formal parameters is too liberal an attitude. We must have a homogeneous choice of larger types, as the following example shows. The ....
Wirth, N. "Type Extensions.", In Transactions on Programming Languages and Systems Vol 10 No 2, ACM 1988. 38
....pointer to the next structure in the list and p selector will be the integer specifying which property the element contains. This idiom of ANSI C provides an implementation of a language feature called Type Extensions that is a prerequisite for extensible data types in object oriented languages [6]. The value of the property can be accessed via p PropVal if p is of type TYPEProperty. This strategy is independent of the type of value (TYPE can be replaced by any built in or user defined type identifier) and the structure uses exactly the amount of storage required by the associative ....
Wirth, N., "Type Extensions," ACM Transactions on Programming Languages and Systems 10 (April 1988), 204--214.
....some kind of class structure, with inheritance (b) some means for dynamically binding methods to objects based on runtime tests of object class Oberon 2 [3, 4] is a minimal language which provides these features. Oberon 2 is an extension of Oberon [5] the main feature of which is type extension [6]. Oberon, in turn, was based on Modula2 [7] Object oriented languages of this kind seem to us to be natural vehicles for the implementation of software systems based on abstract syntax tree (AST) representations. We are therefore interested in reasoning about the efficiency of the code produced ....
Wirth, N., "Type Extension", ACM Trans. on Prog. Lang. and Systems, Vol 10, No 2, pp 204-214, April 1988.
....instance. Although this notation may seem strange, it offers much in terms of simplicity: the entire development, including the notions of Rep, can be carried out without the need of recursive types, dealt by Amadio and Cardelli (1992) or extensible records (Cardelli, 1988, Mitchell, 1988, Wirth 1988) which are implementation dependent; however, expressiveness is sacrificed. Using recursive types the above expression can have any desirable formulation as in RationalFun : Rep F(Rep) with ( new: Integer,Integer) Rep ; etc. where F can be the functor RationalFun itself. This ....
Wirth, N. (1988). Type Extensions. ACM Transactions on Programming Languages and Systems, pp.
No context found.
Wirth, N.: Type Extension. In ACM Transactions on Programming Languages and Systems, Vol. 10, No. 2, April 1988, pp. 204--214.
No context found.
N. Wirth, `Type extensions', ACM Transactions on Programming Languages and Systems, 10, 204--214 (1988).
No context found.
N. Wirth. "Type Extensions". ACM Transactions on Programming Languages and Systems 10(2): 204-214, April 1988. Ada 95 Rationale Index: 1
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