Browse Prior Art Database

Forming and Defining PL/1 Complete Attribute Sets

IP.com Disclosure Number: IPCOM000075661D
Original Publication Date: 1971-Oct-01
Included in the Prior Art Database: 2005-Feb-24
Document File: 2 page(s) / 15K

Publishing Venue

IBM

Related People

Wolf, P: AUTHOR

Abstract

The data-type of a PL/1 variable is represented by a complete set of attributes. This complete set of attributes is established from the variable's declaration (being either explicit or contextual), the default attributes (taken either from an applicable DEFAULT statement or from the SYSTEM defaults), and from implied attributes.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 50% of the total text.

Page 1 of 2

Forming and Defining PL/1 Complete Attribute Sets

The data-type of a PL/1 variable is represented by a complete set of attributes. This complete set of attributes is established from the variable's declaration (being either explicit or contextual), the default attributes (taken either from an applicable DEFAULT statement or from the SYSTEM defaults), and from implied attributes.

When defining three attribute sets, a Declared Attribute Set (DAS) containing the variable's declared attributes, a Default Attribute Set (DTAB) containing the variable's default attributes, and an attribute set called CAS destined to receive the Complete Attribute Set, then a complete attribute set can be formed by the following algorithm: The Declared AS is inspected for an attribute which is distinctive in so far that it determines into which class the variable falls, for example, into the FILE class, or into the arithmetic class, or into the string class, etc. Further the DAS is then searched through for the attributes which are additionally necessary to form a complete set in the particular class into which the variable had fallen; the same being done for optional attributes in that class. If such an attribute is found it is transferred from the DAS to the CAS, that means it is erased in the DAS and is set in the CAS. When finally an attribute set is complete, all attributes should have been shifted from the DAS into the CAS. If there are still some attributes left in the DAS, they are in conflict with the CAS and can be diagnosed as declaration errors. If, during the attribute completion process, a necessary or optional attribute is not found, the DTAS is inspected. If the attribute is found, its presence is indicated in the CAS.

The above process can be described by a formal language which consists of instructions of the form (testDAS, attribute).

The above instruction tests whether the DAS contains the attribute specified by "attribute". If so, the instruction causes the attribute to be transferred from the DAS to the CAS.

The algorithms forming a complete attribute set are generally such that each instruction has two possible successors, one if the attribute tasted for was found, and one if the attribute was not found.

The method of denominating the successors of an instruction chosen here is similar to the method applied in the BACKUS-NAUR description of a syntax. There is a special symbol OR, which initiates the instruction to be taken as a successor of an instruction resulting in FALSE; for example, of a (testDAS, attribute) where the 'attribute' is not present. Absence of the initiating OR symbol, on the other hand, indicates that the instruction is the one to be taken in the TRUE case. Example: DATATYPE IS (TESTDAS, BINARY), SCALE OR, (TESTDAS, DECIMAL), SCALE.

This 'sentence' of the language means: the datatype of a variable can be BINARY or DECIMAL. It can also be understood to describe a routine for testing for these attributes. The above...