Gpc

gpc@gnu.de

5400 discussions

Re: Type extension
by Adriaan van Os 27 Nov '02

27 Nov '02

> Seriously, what would be the benefit of adding it? Compatibility for > some existing code, or the guarantee that such records will not > contain any methods, or anything else? Nothing more than a clarification (not wanting OOP methods, but the type extension only) > I currently don't see an easy way out. Unless someone has a > suggestion, I think that kills it (i.e., there must be a syntactic > difference between "inheritable" and normal records). You are right, there … [View More]

2 1

Probs with variant records
by Wood David 26 Nov '02

26 Nov '02

I've had this happen with DEC Pascal too. Limiting accessible record components seems useful, but in your example, what if aType changes from Circle to Rect. Does a previously set value for Radius become inaccessible? If aType returns to Circle, is the value erased or is the previous value accessible once again? Regards David Wood -----Original Message----- From: Eike Lange [mailto:eike.lange@uni-essen.de] Sent: Tuesday, November 19, 2002 9:11 AM To: Subject: Probs with variant records … [View More]

4 3

Type extension
by Adriaan van Os 26 Nov '02

26 Nov '02

The variable-records discussion on this list has revealed the difficulties of checks on variable records. As a sidebar, I recall that Niklaus Wirth has replaced variant records later (in Oberon) with the much more powerful notion of type extensions. Type extensions can easily be checked, both compile-time and run-time. Adriaan van Os ------------------- [taken from a document by Niklaus Wirth, entitled "From Modula to Oberon"] Type extension The most important addition is the facility … [View More]of extended record types. It permits the construction of new types on the basis of existing types, and establishes a certain degree of compatibility between the new and old types. Assuming a given type T = RECORD x, y: INTEGER END extensions may be defined which contain certain fields in addition to the existing ones. For example TO = RECORD (T) z: REAL END Ti = RECORD (T) w: LONGREAL END define types with fields x, y, z and x, y, w respectively. We define a type declared by T' = RECORD (T) <field definitions> END to be a (direct) extension of T, and conversely T to be the (direct) base type of T'. Extended types may be extended again, giving rise to the following definitions: A type T' is an extension of T, if T'= T orT' is a direct extension of an extension of T. Conversely, T is a base type of T', if T = T' or T is the direct base type of a base type of T'. We denote this relationship by T' -> T. The rule of assignment compatibility states that values of an extended type are assignable to variables of their base types. For example, a record of type TO can be assigned to a variable of the base type T. This assignment involves the fields x and y only, and in fact constitutes a projection of the value onto the space spanned by the base type. It is important to allow modules which import a base type to be able to declare extended types. In fact, this is probably the normal usage. This concept of extensible data type gains importance when extended to pointers. It is appropriate to say that a pointer type P' bound to T' extends a pointer type P, if P is bound to a base type T of T', and to extend the assignment rule to cover this case. It is now possible to form data structures whose nodes are of different types, i.e. inhomogeneous data structures. The inhomogeneity is automatically (and most sensibly) bounded by the fact that the nodes are linked by pointers of a common base type. Typically, the pointer fields establishing the structure are contained in the base type T, and the procedures manipulating the structure are defined in the same (base) module as T. Individual extensions (variants) are defined in client modules together with procedures operating on nodes of the extended type. This scheme is in full accordance with the notion of system extensibility: new modules defining new extensions may be added to a system without requiring a change of the base modules, not even their recompilation. As access to an individual node via a pointer bound to a base type provides a projected view of the node data only, a facility to widen the view is necessary. It depends on the ability to determine the actual type of the referenced node. This is achieved by a type test, a Boolean expression of the form t IS T' (or p IS P') If the test is affirmative, an assignment t':=t(t'of typeT') or p':= p(p'of type P') should be possible. The static view of types, however, prohibits this. Note that both assignments violate the rule of assignment compatibility. The desired assignment is made possible by providing a type guard of the form t' := t(T') (p' := p(P')) and by the same token access to the field z of a TO (see previous examples) is made possible by a type guard in the designator t (TO).z. Here the guard asserts that t is (currently) of type TO. In analogy to array bound checks and case selectors, a failing guard leads to program abortion. Whereas a guard of the form t(T) asserts that t is of type T for the designator (starting with) t only, a regional type guard maintains the assertion over an entire sequence of statements. It has the form WITH t: T DO StatementSequence END and specifies that t is to be regarded as of type T within the entire statement sequence. Typically, T is an extension of the declared type of t. Note that assignments to t within the region therefore require the assigned value to be (an extension) of type T. The regional guard serves to reduce the number of guard evaluations. As an example of the use of type tests and guards, consider the following types Node and Object defined in a module M: TYPE Node = POINTER TO Object; Object = RECORD key, x, y: INTEGER; left, right: Node END Elements in a tree structure anchored in a variable called root (of type Node) are searched by the procedure element defined in M. PROCEDURE element(k: INTEGER): Node; VAR p: Node; BEGIN p:= root; WHILE (p # NIL) & (p.key # k) DO IF p.key < k THEN p:= p.left ELSE p:= p.right END END; RETURN p END element Let extensions of the type Object be defined (together with their pointer types) in a module M 1 which is a client of M: TYPE Rectangle = POINTER TO RectObject; RectObject = RECORD (Object) w, h: REAL END; Circle = POINTER TO CircleObject; CircleObject = RECORD (Object) rad: REAL; shaded: BOOLEAN END After the search of an element, the type test is used to discriminate between the different extensions, and the type guard to access extension fields. For example: p:= M.element(K); IF p # NIL THEN IF p IS Rectangle THEN ... p(Rectangle).w ... ELSIF (p IS Circle) & ~p(Circle) shaded THEN ... p(Gircle).rad ... ELSIF ... The extensibility of a system rests upon the premise that new modules defining new extensions may be added without requiring adaptations nor even recompilation of the existing parts, although components of the new types are included in already existing data structures. The type extension facility not only replaces Modula's variant records, but represents a typesafe alternative. Equally important is its effect of relating types in a type hierarchy. We compare, for example, the Modula types TO' = RECORD t: T; z: REAL END; TV = RECORD t: T; w: LONGREAL END which refer to the definition of T given above, with the extended Oberon types TO and T1 defined above. First, the Oberon types refrain from introducing a new naming scope. Given a variable rO of type TO, we write rO.x instead of rO.t.x as in Modula. Second, the types T, TO', and T1' are distinct and unrelated. In contrast, TO and T1 are related to T as extensions. This becomes manifest through the type test, which asserts that variable rO is not only of type TO, but also of base type T. The declaration of extended record types, the type test, and the type guard are the only additional features introduced in this context. A more extensive discussion is provided in [2]. The concept is very similar to the class notion of Simula 67 [3], Smalltalk [4], Object Pascal [5], C++ [6], and others, where the properties of the base class are said to be inherited by the derived classes. The class facility stipulates that all procedures applicable to objects of the class be defined together with the data definition. This dogma stems from the notion of abstract data type, but it is a serious obstacle in the development of large systems, where the possibility to add further procedures defined in additional modules is highly desirable. It is awkward to be obliged to redefine a class solely because a method (procedure) has been added or changed, particularly when this change requires a recompilation of the class definition and of all its client modules. We emphasise that the type extension facility - although gaining its major role in connection with pointers to build heterogeneous, dynamic data structures as shown in the example above - also applies to statically declared objects used as variable parameters. Such objects are allocated in a workspace organized as a stack of procedure activation records, and therefore take advantage of an extremely efficient allocation and deallocation scheme. In Oberon, procedure types rather than procedures (methods) are connected with objects in the program text. The binding of actual methods (specific procedures) to objects (instances) is delayed until the program is executed. The association of a procedure type with a data type occurs through the declaration of a record field. This field is given a procedure type. The association of a method - to use Smalltalk terminology - with an object occurs through the assignment of a specific procedure as value to the field, and not through a static declaration in the extended type's definition which then "overrides" the declaration given in the base type. Such a procedure is called a handler. Using type tests, the handler is capable of discriminating among different extensions of the record's (object's) base type. In Smalltalk, the compatibility rules between a class and its subclasses are confined to pointers, thereby intertwining the concepts of access method and data type in an undesirable way. In Oberon, the relationship between a type and its extensions is based on the established mathematical concept of projection. In Modula, it is possible to declare a pointer type within an implementation module, and to export it as an opaque type by listing the same identifier in the corresponding definition module. The net effect is that the type is exported while all its properties remain hidden (invisible to clients). In Oberon, this facility is generalized in the sense that the selection of the record fields to be exported is arbitrary and includes the cases all and none. The collection of exported fields defines a partial view - a public projection - to clients. In client modules as well as in the module itself, it is possible to define extensions of the base type (e.g. TextViewers or GraphViewers). Of importance is also the fact that non-exported components (fields) may have types that are not exported either. Hence, it is possible to hide certain data types effectively, although components of (opaquely) exported types refer to them. ------------------- [View Less]

2 3

gpc supports gcc-3.2.1
by Russell Whitaker 25 Nov '02

25 Nov '02

Hi all Now that gcc-3.2.1 has just been released so downloaded it and tried it with gpc: 1. Patch for 3.1.1 works with some comlaints about offsets: expr.c: function.c: hunk 2 4858 offset 2 hunk 2 314 offset 1 hunk 4 4910 offset 2 hunk 3 5491 offset 1 hunk 6 5038 offset 2 hunk 4 5510 offset 1 stor-layout.c: tree.c: hunk 3 1569 offset 27 hunk 3 4745 offset 59 hunk 5 1704 offset … [View More]

3 2

Probs with variant records
by Eike Lange 25 Nov '02

25 Nov '02

Hi Folks! I'm not sure wether it's a feature or a bug but I've read, that setting a case selector in variant records makes some variants unavailable from this point. The following program demonstrates, that setting a case selector allows further overwriting of unselected variants: program Fail3; type TGeoType = (Circle, Rect); TGeometry = record X, Y: Integer; case aType: TGeoType of Circle: (Radius: Integer); Rect: (Width, Height: Integer) end; var Geometry: … [View More]

6 16

Re: Delphi compatibility
by Markus Gerwinski 25 Nov '02

25 Nov '02

Marco van de Voort wrote: > Ever wondered that this might be simply to avoid problems with the RAD scanning part, > and the fact that the syntax highlighting is done by the compiler itself? > > You are so obsessed with putting a C stamp on Delphi that you miss the obvious :-) Just didn't know this particular problem... vi doesn't give me syntax highlighting anyway. ;-) But yes, since I was forced to work with Delphi for a year, I might be a little bit obsessive about it.

1 0

Probs with recursive operator
by Eike Lange 25 Nov '02

25 Nov '02

Hi Folks! The following operator calls itself recursive: program Operator1; operator + (a, b: Integer) = c: Integer; begin WriteLn ('Play it again, Sam.'); c := 2 * a + b end; begin WriteLn ('2 + 3 = ', 2 + 3) end. Is there a way to tell my new operator, which '+' should be used in the operator's body? I know, I could cast or use other types in the operator's body, but the code would become bloated. Are user-defined operators intended to be used with user-defined types only? Eike

2 1

GPC with Emacs 21
by Florian Lindner 21 Nov '02

21 Nov '02

Hello, I'm looking for a tutorial or How-To for using GPC with Emacs 21 and pascal-mode. Thx, Florian

2 1

Re: Probs with variant records
by Emil Jerabek 21 Nov '02

21 Nov '02

On Wed, Nov 20, 2002 at 11:37:16AM -0500, CBFalconer wrote: > Emil Jerabek wrote: > > On Tue, Nov 19, 2002 at 04:55:47PM -0500, CBFalconer wrote: > > > "J. David Bryan" wrote: > > > > On 19 Nov 2002 at 12:00, CBFalconer wrote: > > > > [...] > > > > > > Now, where is the compiler going to get the values of minval and > > > maxval? To do so it would have to read a, and translate that > > > somehow into minval and … [View More]maxval at run time. Where are those > > > tables stored? Nothing insists that a be a valid initialized > > > value before storing something in onebyte. Remember, onebyte and > > > twobyte have the same offsets. They can store different > > > subranges. a may have been set in another procedure far, far > > > away. > > > > Don't understand this. The problem was to check that the component > > accessed is valid, which is as simple as ``r.a = 1?'' in your > > example. Anyway the range check which you seem to be talking about > > is also easy: the code stores something into r.twobyte, > > hence the value should be range-checked against the definition > > of twobyte, i.e. minval = -5 and maxval = 512. These bounds are > > known at compile time, and they have nothing to do with the current > > value of r.a. > > Sorry, no, that is not the problem. The problem is to check the > storage into twobyte, IN ISOLATION. To check that such storage is > possible requires READING the a value. There is no guarantee that > a has already been initialized, AFAIK. At run time, even if a can > be read, there is no place to find the twobyte limits. The > compiler tables have long been discarded. To use them would > require storing them (or a subset) in the object code, and could > take a great deal of space. Consider a record type with 100 Checking that an assignment to the twobyte variant is legal does require reading the value of a, and I can't imagine any useful run-time check which wouldn't need to read some value :-) Once again, range check on the _value_ which is assigned to rcd.twobyte is an independent problem, and it needs only to know the bounds for the twobyte variant, not the whole (possibly large) table of such bounds for other variants. But maybe J. Bryan's last two posts explain this more clearly. > variants. The table must consist of at least 100 each minima and > maxima. This is done all over again for each potential variant > record type. Code has to be generated to access and index that > table for every store into a variant item. We would probably also > need to maintain a value for a outside it's normal range to > indicate it has not been set, which forbids access to any variant. > > It gets worse. The variants may be arrays of different sizes of > differently sized components. Now we have to check the index > value against some table and then check against the component > limits. We do this at run-time, without the benefit of compiler > symbol tables. Or the variants may have variants. > > Note again the fact that the 'a' need not have been initialized > when the twobyte storage is done. > > This would be Microsoftian code bloat. I am not saying it is > impossible, just that it is neither trivial nor really practical. > Range (or any other run-time) checking is always a code bloat. Its purpose is to assist debugging, and then it doesn't matter much that the code is huge and slow. > Let's do the easy stuff first. Range checking of indices and > subranges, thinking of characters and booleans as subranges of > integers. That will uncover most of the errors. > > BTW, I believe something similar has already arisen in the usage > of variant 10206 strings, where there is a need to store a > capacity for each variant. In this case gpc has chosen to > allocate completely separate storage areas for each variant, just > to get the effect of such a table. I have other ideas on this, > which don't belong in this thread. > > > > > > In addition, the compiler knows that it is storing a twobyte > > > value. If it got it from something of appropriate type it knows > > > it need not do a check on this store, and can totally elide the > > > CHK operation. No such efficiencies if we have to read and > > > translate the a value first. > > > > > > Without that check the only differences for storing onebyte and > > > twobyte are the (known at compile time) values of minval and > > > maxval, and quite possibly the operand of STI, which specifies the > > > size of the thing to be written. > > > > > > In other words full checking here is a monstrous can of worms. > > > > > > Checking that the variant selector is in range never enters into > > > it (except when storing that value at some other time). The names > > > > Yes, it does. Here, the ``range'' was 1 .. 1, but the ISO 10206 > > standard permits a general range (or list of ranges) in such a situation. > > I am not really familiar with the 10206 spec, much more familiar > with 7185, so I'll take your word on the otherwise usage and the > range ranges. That just makes the problem more intractable. Yes. But I think this feature is rarely used in practice, it's probably included in the standard just to make the syntax of variant records parallel to case statements. Emil > Permitting them in the variant CASE means they need to be > available in the executable code CASE, but the converse does not > necessarily apply. Which is not germane anyhow. > > -- > Chuck F (cbfalconer(a)yahoo.com) (cbfalconer(a)worldnet.att.net) > Available for consulting/temporary embedded and systems. > <http://cbfalconer.home.att.net> USE worldnet address! > [View Less]

1 0

Bug with Card
by Eike Lange 20 Nov '02

20 Nov '02

Hi Folks! The following program does not work: program Fail1; var MySet: Set of Char = ['b', 'a', 'r']; begin WriteLn (Card (MySet)); { works } WriteLn (Card (['f', 'a', 'i', 'l'])) { fails } end. GPC-Version: ============ gpc 20021111, based on gcc-2.95.2 19991024 (release) Error: ====== ../../../gcc-2.95.2/gcc/p/rtscall.c:333:actual_set_parameters: failed assertion 'TREE_CODE (TREE_TYPE (TREE_TYPE (val))) != VOID_TYPE' fail1.pas: In main program: fail1.pas:8: … [View More]

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

Gpc