Pascal Standards FAQ (Rev. 001, 3-Apr-1995)
John
Reagan
Application Compilers and Environments
Digital Equipment Corporation
Disclaimer: The opinions and statements expressed by me are not necessarily those of Digital Equipment Corporation.
Contents
This FAQ contains various questions that are frequently asked about the
various Pascal standards.
Changes since Rev. 000
- New information for ISO online services
- What are the different Pascal standards?
- Who creates the standards?
- Anymore standards in progress?
- How do I get copies of the standards?
- How to find compilers for each standard?
- Comparison of Borland Pascal to the Pascal
standards
- Various suggestions for enhancements/changes to the
Pascal standards
- Required Interfaces to Extended Pascal
- History of Pascal Standards
Thanks to the following folks for contributions to the FAQ:
There are currently 3 different documents that can be classified as Pascal
standards: Unextended Pascal, Extended Pascal, and the Object-Oriented
Extensions to Pascal.
The unextended Pascal standard was completed in 1983 and closely resembles
the Pascal in the Jensen and Wirth Pascal User-manual and report. There were
a few notable differences such as defining a ormal-parameter list on
procedure-parameter definitions.
Originally, unextended Pascal was actually 2 standards. An ANSI/IEEE
standard (ANSI/IEEE770X3.97-1993) and an ISO standard (ISO 7185 : 1983).
There were 2 standards for mostly political differences that I won't get into
here. For the most part, the ISO standard was a superset of the ANSI/IEEE
standard and included the conformant array feature. See the foreword of
Extended Pascal for some additional history of the development of unextended
Pascal.
In 1989, ISO 7185 was revised to correct various errors and ambiguities
found in the original document. Also, the ANSI/IEEE770X3.97 standard was
replaced with a "pointer" to the ISO 7185 standard. So finally in 1989,
there was only 1 unextended Pascal standard in the world.
The unextended Pascal standard (ISO 7185 : 1990) is still in force as a
valid ISO language standard.
The Extended Pascal standard was completed in 1989 and is a superset of ISO
7185. The Extended Pascal standard is both an ANSI/IEEE and ISO/IEC standard.
Both standards are identical in content with minor editorial differences
between the IEEE and ISO/IEC style guiles.
The ANSI/IEEE number is ANSI/IEEE 770X3.160-1989. The ISO/IEC number is
ISO/IEC 10206 : 1991.
Here is part of the foreword from the Extended Pascal standard to provide a
short summary of the new features in Extended Pascal.
- Modularity and Separate Compilation. Modularity provides for separately-
compilable program components, while maintaining type security.
- Each module exports one or more interfaces containing entities (values,
types, schemata, variables, procedures, and functions) from that module,
thereby controlling visibility into the module.
- A variable may be protected on export, so that an importer may use it but
not alter its value. A type may be restricted, so that its structure is not
visible.
- The form of a module clearly separates its interfaces from its internal
details.
- Any block may import one or more interfaces. Each interface may be used
in whole or in part.
- Entities may be accessed with or without interface-name qualification.
- Entities may be renamed on export or import.
- Initialization and finalization actions may be specified for each module.
- Modules provide a framework for implementation of libraries and non-Pascal
program components.
Example:
Module employee_sort interface;
Export employee_sort = (sort_by_name,sort_by_clock_number,
employee_list);
Import generic_sort;
Type
employee = record
last_name,first_name : string(30);
clock_number : 1..maxint;
end;
employee_list(num_employees : max_sort_index) =
array [1..num_employees] of employee;
Procedure sort_by_name(employees : employee_list;
var something_done : Boolean);
Procedure sort_by_clock_number(employees : employee_list;
var something_done : Boolean);
end.
- Schemata. A schema determines a collection of similar types. Types may be selected statically or dynamically from schemata.
- Statically selected types are uses as any other types are used.
- Dynamically selected types subsume all the functionality of, and provide
functional capability beyond, conformant arrays.
- The allocation procedure NEW may dynamically select the type (and thus the
size) of the allocated variable.
- A schematic formal-parameter adjusts to the bounds of its actual-
parameters.
- The declaration of a local variable may dynamically select the type (and
thus the size) of the variable.
- The with-statement is extended to work with schemata.
- Formal schema discriminants can be used as variant selectors.
Example:
Type
SWidth = 0..1023;
SHeight = 0..2047;
Screen(width: SWidth; height: SHeight) =
array [0..height, 0..width] of boolean;
Matrix(M,N: integer) = array [1..M,1..N] of real;
Vector(M: integer) = array [1..M] of real;
Color = (red,yellow);
Color_Map(formal_discriminant: color) = record
case formal_discriminant of
red: (red_field : integer);
yellow : (yellow_field : integer);
end;
Function bound : integer;
Var
s : integer;
begin
write('How big?');
readln(s);
bound := s;
end;
Var
My_Matrix : Matrix(10,10);
My_Vector : Vector(bound); { Notice the run-time expression! }
Matrix_Ptr : ^Matrix;
X,Y : integer;
begin
readln(x,y);
new(Matrix_Ptr,X,Y);
end.
- String Capabilities. The comprehensive string facilities unify fixed-
length strings and character values with variable-length strings.
- All string and character values are compatible.
- The concatenation operator (+) combines all string and character values.
- String may be compared using blank padding via the relation operators, or
using no padding via the functions EQ, LT, GT, NE, LE, and GE.
- The functions LENGTH, INDEX, SUBSTR, and TRIM provide information about,
or manipulate, strings.
- The substring-variable notation makes accessible, as a variable, a fixed-
length portion of a string variable.
- The transfer procedures READSTR and WRITESTR process strings in the same
manner that READ and WRITE process textfiles.
- The procedure READ has been extended to read strings from textfiles.
- Binding of Variables.
- A variable may optionally be declared to be bindable. Bindable variables
may be bound to external entities (file storage, real-time clock, command
lines, etc.). Only bindable variables may be so bound.
- The procedures BIND and UNBIND, together with the related type
BINDINGTYPE, provide capabilities for connection and disconnection of bindable
internal (file and non-file) variables to external entities.
- The function BINDING returns current or default binding information.
- Direct Access File Handling.
- The declaration of a direct-access file indicates an index by which
individual file elements may be accessed.
- The procedures SEEKREAD, SEEKWRITE, and SEEKUPDATE position the file.
- The functions POSITION, LASTPOSITION, and EMPTY report the current
position and size of the file.
- The update file mode and its associated procedure UPDATE provide in-place
modification.
- File Extend Procedure. The procedure EXTEND prepares an existing file for writing at its end.
- Constant Expressions. A constant expression may occur in any context
needing a constant value.
- Structured Value Constructors. An expression may represent the value of an array, record, or set in terms of its components. This is particularly
value for defining structured constants.
- Generalized Function Results. The result of a function may have any
assignable type. A function result variable may be specified, which is
especially useful for functions returning structures. A function call may be directly array-index, field-selected, or pointer-dereferenced without having to use an intermediate variable.
- Initial Variable State. The initial state specifier of a type [or record field] can specify the value that variables [, or fields, or variant
selectors] are to be created with.
- Relaxation of Ordering of Declarations. There may be any number of
declaration parts (labels, constants, types, variables, procedures and
functions) and in any order. The prohibition of forward references in
declarations is retained.
- Type Inquiry. A variable or parameter may be declared to have the type of another parameter of another variable.
- Implementation Characteristics. The constant MAXCHAR is the largest value of type CHAR. The constant MINREAL, MAXREAL, and EPSREAL describe the range of magnitude and the precision of real arithmetic.
- Case-Statement and Variant Record Enhancements. Each case-constant-list may contain ranges of values. An OTHERWISE clause represents all values not listed in the case-constant-lists.
- Set Extensions.
- An operator (><) computes the set symmetric difference.
- The function CARD yields the number of members in a set.
- A form of the for-statement iterates through the members of a set.
- Date and Time. The procedure GETTIMESTAMP and the functions DATE and
TIME, together with the related type TIMESTAMP, provide numeric
representations of the current date and time and convert numeric
representations to strings.
- Inverse Ord. A generalizations of SUCC and PRED provides an inverse ORD capability.
- Standard Numeric Input. The definition of acceptable character sequences read from a textfile includes all standard numeric representations defined by ANSI X3.42-1975.
- Non-Decimal Representation of Numbers. Integer numeric constants may be expressed using bases two through thirty-six.
- Underscores in Identifiers. The underscore character (_) may occur within identifiers and are significant to their spelling.
- Zero Field Widths. The total field width and fraction digits expressions in write parameters may be zero.
- Halt. The procedure HALT causes termination of the program.
- Complex Numbers.
- The simple-type COMPLEX allows complex numbers to be expressed in either
Cartesian or polar notation.
- The monadic operators + and - and dyadic operators +, -, *, /, =, [and] <>
operate on complex values.
- The functions CMPLX, POLAR, RE, IM, and ARG construct or provide
information about complex values.
- The functions ABS, SQR, SQRT, EXP, LN, SIN, COS, [and] ARCTAN operate on
complex values.
- Short Circuit Boolean Evaluation. The operators AND_THEN and OR_ELSE are logically equivalent to AND and OR, except that evaluation order is defined as left-to-right, and the right operand is not evaluated if the value of the expression can be determined solely from the value of the left operand.
- Protected Parameters. A parameter of a procedure or a function can be
protected from modification within the procedure or function.
- Exponentation. The operators ** and POW provide exponentation of integer, real, and complex numbers to real and integer powers.
- Subranges Bounds. A general expression can be used to specify the value of either bound in a subrange.
- Tag Fields of Dynamic Variables. Any tag field specified by a parameter to the procedure NEW is given the specified value.
- Conformant Arrays. Conformant arrays provide upward compatibility with
level 1 of ISO 7185, Programming languages - PASCAL.
After the Extended Pascal standard was completed, the committee took up the task of adding object-oriented features to Extended Pascal. Actually, the work applies to both Extended Pascal and unextended Pascal, but to get the full benefit from the object-oriented features, certain features from Extended Pascal must also be utilized.
This work was done as an ANSI Technical Report. Unlike the 2 previous standards, the technical report is not full of "standardize", but rather is more informal and readable than a full-bodied standard. This report was completed in 1993.
Features from the technical report include:
- A CLASS definition with support for ABSTRACT and PROPERTY classes. Abstract classes are place holders in the class hierarchy. An object cannot be created for an abstract class. Property classes provide characteristics, attributes, or properties of another class. An object can be tested to see whether or not is has a property.
- Multiple inheritance from at most one concrete or abstract class and zero or more property classes.
- Method definitions can be marked with ABSTRACT or OVERRIDE.
- Constructors and destructors with zero or more parameters.
- A predefined ROOT class containing a predefined constructor (CREATE), a predefined destructor (DESTROY), and two predefined methods (CLONE and EQUAL).
- Predefined property class TEXTWRITABLE with methods READOBJ and WRITEOBJ.
- CLASS VIEWs provide a new class type that is a partially opaque view of an existing class type. Views are used to provide visibility, security, and protocol between public and private uses of the class.
- The object model is a reference model. This means that you create and destroy objects explicitly. Objects can be thought of as if they were accessed indirectly through references.
- A membership operator, IS.
Would you believe magic elves? No, I guess not...
The Pascal standards are development and maintained by the American committee, X3J9, and the International working group, WG2. Most of the standarizers actually belong to both committees.
During its peak, the committee met at least 4 times a year for a week at a time. The location of the meetings floated around from member to member trying to alternate east-coast vs west-coast. The WG2 meetings tried to alternate between North America and UK/Europe.
Recently, the committee's work has slowed down and the meetings average about 1 or 2 per year with very rare meetings in the the UK.
The committee is open to the public. To become a voting member on X3J9 you just have to satisfy some attendance/participation requirements (very easy) and be a member of X3 by paying dues (X3 dues can be waived for those unable to pay). Basically, anybody with a brain may attend (and if you've been to some previous meetings, you'll note that we sometimes waive that requirement too :-) )
If you are interested in attending a Pascal meeting, drop me a note at reagan@hiyall.enet.dec.com and I can give you information on the next meeting's location.
Over the past years, many different vendors, user-groups, acedemics, etc. have participated in XJ39. Here is a quick list (not intended to be a total list) of participants: Digital Equipement Corportation, Apple Computer, Microsoft, Tandem Computers, Sun Microsystems, Intel, Siemens Nixdorf, IBM, Hewlett Packard, Edinburgh Portable Compilers, Prospero Software Ltd. University of Bochum, Borland International, US Air Force, University of Teesside, Visible Software, US Census Bureau, Symantec, Unisys, GTE, Control Data Corporation, Cray Research Inc., E-Systems, ACE - Associated Computer Experts bv, Stanford Linear Accelerator Center, Central Michigan University, Pace University, St. Peter's College, Prime Computer, Queens University, Research Libraries Group, Florida International University, Apollo Computer, NCR Corporation, Data General, and various individuals representing themselves. (Well, technically almost all members of the committee represent themselves and not their employers, but I thought people would recognize the names of the companies and not the names of the individuals.)
Recently, the committee has been working on an exception handling model that is similar to what you might see in C++ or Modula-3. We hope to produce another ANSI Technical Report on this in the future. However, we're in need of more people to participate in our work. In the past, most of the work was physically done at the meetings, but I think that in the future, we'll have to do work by e-mail or newsgroups in a more informal fashion and only have physical meetings to consolidate the final work.
The unextended Pascal and Extended Pascal standards are both copyrighted by the IEEE in the US and ISO/IEC in other contries.
You can obtain copies from the IEEE, your countries standards body, University libraries, corporate libraries, or the ISO/IEC in Genhva Switzerland. Also, there is a Standards FAQ posted montly in News.Announce which helps finding who to contact. It can also be found at ftp.uni-erlangen.de:/pub/doc/ISO/. You can also Telnet to info.itu.ch with name "gopher".
Here is some contact information:
Philips Business Information 1-800-777-5006
Document Center 1-415-591-7600
ANSI 1-212-642-4900
Attention: Customer Service
11 West 42nd Street
New York, NY 10036
ISO Sales
Case Postale 56
CH-1211 Geneve 20
Switzerland
email: sales@isocs.iso.ch
http://www.iso.ch/welcome.html ! in English
http://www.iso.ch/welcomef.html ! en Frangais
I do not think that the IEEE has republished the unextended Pascal standard since it was essentially replaced with a pointer to the ISO 7185 standard. The IEEE may still have old copies lying around. The IEEE order number is SH08912. The ISBN number is 0-471-88944-X. I know that the revised ISO 7185 is available (I have a copy from BSI in the UK).
For Extended Pascal, the IEEE order number is SH13243 and the ISBN number is 1-55937-031-9. Last time I checked the IEEE's price was around US$55. I'm not sure what the ISO/IEC charges. In addition, I've been told that the GNU Pascal kit at kampi.hut.fi:/jtv/gnu-pascal contains a LeX script for Extneded Pascal. I have no idea about its accuracy.
The Object-Oriented Extensions to Pascal technical report is a ANSI technical report number ANSI/X3-TR-13-1994 (is 13 an omen?) I'm not sure of its copyright status, but it also isn't online in its final form (the editor was using some variant of Word Perfect and said he was unable to provide a readable text form). You can get the technical report from CBEMA in Washington DC. I have no idea at present how to get it outside the United States. I personally have a few hardcopies laying around my office and if you drop me a line at reagan@hiyall.enet.dec.com, I'll see what I can do.
I should point out that the unextended Pascal and Extended Pascal standards are written in a very legalistic form and are not light reading. They really aren't suitable as an implementation guide or learning how to use features from unextended or Extended Pascal. On the other hand, the Object-Oriented Extensions to Pascal technical report is written in a less formal style. The committee is planning on producing "standardese" for the technical report to include in a future revision of the unextended and Extended Pascal standards.
For unextended Pascal, there are dozens of compilers that accept unextended Pascal programs. They range from PCs (Prospero Pascal) to large Digital Alpha machines, IBM mainframes, HP workstations, etc.. Unfortunately, Turbo Pascal does not accept all programs from unextended Pascal (it lacks items such as GET, PUT, procedure parameters, etc.)
The US government performs validation services using the PVS (Pascal Validation Suite). The Pascal Validation Suite is available from Prospero Software in the UK (it was owned by the BSI (British Standards Institute until recently).
For Extended Pascal, only Prospero Pascal claims complete acceptance of Extended Pascal source code. Other vendor's compilers, like Digital, accept portions of the Extended Pascal standard. You'll have to ask your favorite vendor about support.
At present, there is no official Extended Pascal Validation Suite. Now that Prospero has obtained the rights to the Pascal Validation Suite, there is chance for a future EPVS. You'll have to ask Prospero about their plans.
For the Object-Oriented Extensions to Pascal, I know of no compiler that yet claims support of the document. Again, ask your vendor to make sure.
As mentioned earlier, Turbo Pascal does not conform to any of the Pascal standards. If you carefully chose a subset of unextended Pascal, you may be able to port code if you're lucky/careful.
To be fair, Turbo Pascal has some wonderful features that make it very powerful in the environments in which it runs. However, those same features are of little use on non Windows/DOS platforms and probably are not good candidates for standardization.
There are several Turbo Pascal features which are semantically similar to features in unextended Pascal or Extended Pascal. Here is a list of mappings between Turbo Pascal features and Extended Pascal features:
- Case constructs
- Extended Pascal uses otherwise instead of else.
Borland Pascal:
case c of
'A' : ;
'B' : ;
else ...;
end;
Extended Pascal:
case c of
'A' : ;
'B' : ;
otherwise ...;
end;
- Missing cases cause Extended Pascal compilers to halt. In the case statement above if you had no otherwise clause and char c had the value 'C', you got an error (note, this would be unnoticed in Borland Pascal).
- Procedure and function types and variables
Here is an area of subtle differences. Turbo Pascal has true procedure/function types but doesn't have standard Pascal's procedural/functional parameters.
Borland Pascal:
Type
CompareFunction = function(Key1, Key2 : string) : integer;
Function Sort(Compare : CompareFunction);
begin
...
end;
Extended Pascal
Function Sort(Compare : function(Key1, Key2 : string) : integer);
begin
...
end;
Moving from Turbo Pascal to Extended Pascal might be difficult if the Turbo Pascal program saves, compares, trades, etc. procedure values. For example, an array of procedure values isn't possible in Extended Pascal. Moving the other way is a little easier as show by the above examples.
- Strings
- Borland Pascal's string type has a special case, namely string without a length meaning the same as string[255]. There is no default in Extended Pascal so you have to change all string types to string(255). Example:
Var
s : string;
becomes:
Var
s : string(255);
Note also that you have to use parentheses instead of brackets.
- A nice pitfall is the pointer to string as in:
Type
PString = ^String;
In Extended Pascal this is a pointer to a schema type!! Don't forget to translate this to:
Type
string255 = string(255);
PString = ^string255;
If you indeed want to use String as a schema pointer you can define things like:
Type
MyStr : ^String;
begin
New(MyStr, 1024);
end;
to allocate 1024 bytes of string space.
- As you could see above, Extended Pascal has no 255 byte limit for strings. It is however save to assume a limit of about 32000 bytes. At least Prospero's Extended Pascal limits strings to 32760 bytes. GNU Pascal seems to allow larger strings. DEC Pascal limits strings to 65535 bytes.
- Constant variables
- Extended Pascal translates Borland's gruesome:
Const
i:integer = 0;
to:
Var
i : integer value 0;
Much nicer ain't it?
- Even nicer is that you can assign initialization values to types. Like:
Type
MyInteger = integer value 0;
Var
i : MyInteger;
All variables of type MyInteger are automatically initialized to 0 when created.
- Constant arrays of type string are translated from:
Const
MyStringsCount = 5;
Type
Ident = string[20];
Const
MyStrings : array [1..MyStringsCount] of Ident = (
'EXPORT', 'IMPLEMENTATION', 'IMPORT', 'INTERFACE',
'MODULE');
to:
Const
MyStringsCount = 5;
Type
Ident = string(20);
Var
MyStrings : array [1..MyStringsCount] of Ident value [
1:'EXPORT'; 2:'IMPLEMENTATION'; 3:'IMPORT';
4:'INTERFACE'; 5:'MODULE'];
There seem to be pros and cons to each style.
Some folks don't like having to specify an index since it requires renumbering if you want to add a new item to the middle. However, if you index by an enumerated type, you might be able to avoid major renumbering by hand.
- Variant records
The following construction is not allowed in Extended Pascal:
Type
PersonRec = record
Age : integer;
case EyeColor : (Red, Green, Blue, Brown) of
Red, Green : (Wears_Glasses : Boolean);
Blue, Brown : (Length_of_lashes : integer);
end;
The variant field needs an explicit type. Code this as:
Type
EyeColorType = (Red, Green, Blue, Brown);
PersonRec = record
Age : integer;
case EyeColor : EyeColorType of
Red, Green : (Wears_Glasses : Boolean);
Blue, Brown : (Length_of_lashes : integer);
end;
- Units
- You can translate units almost automatically to Extended Pascal Modules, taking into account some differences of course.
Extended Pascal does not automatically export everything named in a module, but you have to create seperate export clauses.
For example translate the following unit:
Unit A;
Interface
Uses
B, C;
Procedure D;
Implementation
Procedure D;
begin
end;
end.
to this module:
Module A interface;
Export
A = (D);
Import
B;
C;
Procedure D;
end.
Module A implementation;
Procedure D;
begin
end;
end.
You can have one or more export clauses and the name of an export clause doesn't have to be equal to the name of the module.
You also see in this example how to translate the Borland Pascal "uses" clause to the Extended Pascal "import" clause.
- Borland Pascal allows you to have code in a unit that is executed once, at startup, to initialize things. You can translate this to Extended Pascal's "to begin do ..end" structure.
Borland Pascal:
Unit A;
Interface
Implementation
begin
{ do something }
end.
Extended Pascal:
Module A interface;
end.
Module A implementation;
to begin do begin
{ do something }
end;
end.
Extended Pascal also has a "to end do .... end" so you can translate Exit handlers also.
- Files
Extended Pascal treats files quite differently as Borland Pascal. I'm not going to treat file pointers, Get and Put here, but instead I focus on special Extended Pascal features.
In Borland Pascal you can read any text file as follows:
Var
t : text;
Line : string;
begin
Assign(t, 'MYTEXT.TXT');
Reset(t);
while not eof(t) do
begin
readln(t, Line);
writeln(Line);
end;
end;
The Assign function associated the textfile T with the file MYTEXT.TXT.
In Extended Pascal, files are considered entities external to your program. External entities, which don't need to be files, need to be bound to a variable your program. Any variable to which external entities can be bound needs to be declared bindable. So the variable declaration of t becomes:
Var
t : bindable text;
Extended Pascal has the bind function that binds a variable with an external entity. Here is an Extended Pascal procedure that emulates the Assign procedure in Turbo Pascal.
Procedure Assign(var t : text; protected Name : string);
Var
b : BindingType;
begin
unbind (t);
b := binding (t);
b.Name := Name;
bind (t, b);
b := binding (t);
end;
Comments: the unbind procedure unbinds a bindable variable fromits external entity. If it is not bound, nothing happens. Thebinding function initializes b. We call binding to set some fields of the BindingType record. Next we set the name field to the name of the file. Calling bind will bind t to the external entity. If we now call binding again, we get the current state of t's binding type. We can now check for example if the bind has succeeded by:
if not b.bound then
{ do error processing }
Note that Prospero's Pascal defaults to creating the file if it does not exists! You need to use Prospero's local addition of setting b.existing to true to work-around this.
I've not worked with binary files enough, so no advice yet on how to access them, but you access them much the same.
As last an example of getting the size of a file.
Function FileSize(filename : String) : integer;
Var
f : bindable file [0..MaxInt] of char;
b : BindingType;
begin
unbind(f);
b := binding (f);
b.Name := filename;
bind(f, b);
b := binding(f);
SeekRead(f, 0);
if empty(f) then
filesize := 0
else
filesize := LastPosition(f) + 1;
unbind(f);
end (*file_size*);
Prospero's Extended Pascal for DOS has a bug in this case. Replace the MaxInt in the type definition of f by a sufficiently large integer. Prospero's 32-bit Extended Pascal and GNU Pascal work correctly in this case.
If you have comments, suggestions, opinions, etc. about future Pascal standards work, please speak up! Send them to the committee and we'll put them on the agenda. However, to be honest, without a person who has an interest in the new feature, they tend to dry up and die. So, if you REALLY want a feature in the Pascal standards, be prepared to write up CONVINCING arguments about standarizing. I'll warn you now not to bias them to any particular system or hardware. If what you suggest won't work (at least conceptually) on all machines from Crays, Alphas, Pentiums, OS/2, OpenVMS, DOS, NT, PowerMacs, etc., then you'll have a very hard time to get it in the standard. You don't have to prove that its implementable (although it helps) or even easy to implement... That doesn't mean that you can't suggest something that is implementation defined (MAXINT for example), but such a feature better have some redeeming reason to be included in the standard.
We can certainly discuss potential changes here in comp.lang.pascal, but in my opinion, the amount of Turbo Pascal-specific information might make it hard to carry on a discussion. If so, then lets try to have some key in the subject line so we can quickly spot them. Alternatively, if the comp.std.pascal newsgroup goes ahead, then that would be the perfect spot for new feature discussions for the Pascal standards.
Here are a few changes/additions to Extended Pascal that have bounced around the newsgroup (I may or may not support each of the following items or even know what they mean, I'm just writing them down).
- optional parameter to HALT procedure
- allow repeating of procedure/function declaration in module implementation (as already suggested in the OOP document)
- allow to test for file existence (add an 'existing' field to BindingType or something like that)
- allow type-casts
- provide for a "total export" option so you don't have to specify each item in an interface
- provide true procedure/function types
I think that each of these items could be discussed and produce some positive suggestions.
The Extended Pascal standard includes 2 concepts that provide hooks for interfaces to things outside of Pascal.
Firstly, Extended Pascal has an IMPORT declaration that brings in an interface. Extended Pascal's interfaces correspond to Turbo Pascal's units.
When Extended Pascal was being worked on, the committee asked itself if there should be any required interfaces or required bindings (other than for file variables). At first, there was of talk about all sorts of require interfaces (for sorting, for screen mangement, etc.). However, any such talk quickly deteriorated when we started talking about things like keyboards, joysticks, vector processors, etc. Just as one couldn't imagine a joystick on a Cray, we couldn't imagine a vector processor on a 286 DOS machine. So the idea of REQUIRED interfaces was quickly dismissed. Next the committee said "what if we specify an interface and say 'if you provide it, you must provide at least this much'". That had quite a bit of support, but when push came to shove, it also vanished from the standard leaving absolute no hint of any required interfaces.
I certainly think we could discuss interface definitions that would be 'if you provide it, you must provide at least this much'.
Recently, there was some early discussion about a keyboard interface. I think that would be a good starting point. Here again, I would say that any proposed interface must deal with multiple types of keyboards. Like those that return multiple-bytes for each key pressed, for keyboards in different countries that have other characters on keys that aren't in the "normal" Latin-1 character set, etc..
Other interfaces might include a printing package, screen package, I/O package, GKS, X-windows, an object-oriented visual environment, networking, etc..
Secondly, Extended Pascal has a BIND statement that binds a variable to an external entity. Extended Pascal uses BIND to bind a file variable to an external file such that it can then be processed with READ, WRITE, etc.. This feature is much less "procedural" than using interface (Extended Pascal does not provide operator overloading and therefore importing an interface can only provide access to procedures, functions, variables, types, and constants, but not operators).
One could imaging binding an integer variable to an I/O port and every use of the variable would read from the port and every write to the variable would write to the port. You might even want to combine interfaces and bindings. The possibilities (and discussions) are endless...
Here is part of the foreword from the Extended Pascal standard to provide some history of it (and of unextended Pascal).
In 1977, a working group was formed within the British Standards Institution (BSI) to produce a standard for the programming language Pascal. This group produced several working drafts, the first draft for public comment being widely published in 1979. In 1978, BSI's proposal that Pascal be added to ISO's program of work was accepted, and the ISO Pascal Working Group (then designated ISO/TC97/SC5/WG4) was formed in 1979. The Pascal standard was to be published by BSI on behalf of ISO, and this British Standard referenced by the International Standard.
In the USA, in the fall of 1978, application was made to the IEEE Standards Board by the IEEE Computer Society to authorize project 770 (Pascal). After approval, the first meeting was held in January 1979.
In December of 1978, X3J9 convened as a result of a SPARC (Standards Planning and Requirements Committee) resolution to form a US TAG (Technical Advisory Group) for the ISO Pascal standardization effort initiated by the UK. These effors were performed under X3 project 317.
In agreement with IEEE representatives, in February of 1979, an X3 resolution combined the X3J9 and P770 committees into a single committee called the Joint X3J9/IEEE P770 Pascal Standards Committee (Throughout, the term JPC refers to this committee.) The first meeting as JPC was held in April 1979. The resolution to form JPC clarified the dual function of the single joint committee to produce a dpANS and a proposed IEEE Pascal Standard, identical in content.
ANSI/IEEE770X3.97-1983, American National Standard Pascal Computer Programming Language, was approved by the IEEE Standards Board on September 17, 1981, and by the Amterican National Standards Institute on December 16, 1982. British Standard BS6192, Specification for Computer programming language Pascal, was published in 1982, and International Standard ISO 7185 (incorporating BS6192 by reference) was approved by ISO on December 1, 1983. Differences between the ANSI and ISO standards are detailed in the Foreword of ANSI/IEEE770X3.97-1983. (BS6192/ISO 7185 was revised and corrected during 1988/1989; it is expected that ANSI/IEEE770X3.97-1983 will be replaced by the revised ISO 7185.)
Following the decision that the first publication of a standard for the programming language Pascal would not contain extensions to the language, JPC prepared a project proposal to SPARC for an Extended Pascal Standard. When approved by X3 in November 1980, this proposal formed the charter for Project 345.
JPC immediately formed the Extension Task Group to receive all proposals for extensions to the Pascal language, developed the content of proposals so that they were in a form suitable for review by JPC, fairly and equitable reviewed all proposals in light of published JPC policy, and provided a liaison with the public in all matters concerning proposed extensions to the Pascal language.
X3 issued a press release on behalf of JPC in January 1980 to solicit extension proposals or suggestions from the general public. At this time, JPC had already prepared a list of priority extensions; public comment served to validate and supplement the priority list. Criteria for evaluationg extensions were established and include machine indepedence, upward compatibility, conceptual integrity, rigorous definition, and existing practice as prime objectives. Extension proposals submitted by the public and by the JPC membership were developed and refined. JPC procedures guaranteed that proposals would be considered over at least two meetings, affording adequate time for review of the technical mertis of each proposal.
By June of 1983, twelve extensions had been designated by JPC as candidate extensions and were published as the Candidate Extension Library. Ongoing work was described in Work in Progress, published with the Candidate Extension Library. This effort served as an interim milestone and an opportunity for the public to review the effort to date.
In 1984, BSI also started work on extensions to Pascal, with an initial aim of providing extensions in a few areas only. In 1985, the ISO Pascal Working group (then designated ISO/TC97/WC22/WG2, now ISO/IEC JTC1/SC22/WG2) was reconvened after a long break to consider proposals from both ANSI and BSI in an international forum. Thereafter WG2 met at regular intervals to reconcile the national standarization activites in ANSI and BSI and to consider issues raised by the other experts participating in WG2.
The Work in Progress document, along with other proposals subsequently received, continued its development until June 1986. The process of reconciling individual candidate extensions among themselves was begun in September 1984 and continued until June 1986. During this phase, conflicts between changes were resolved and each change was reconsidered.
Working drafts of the full standard were circulated withing JPC and WG2 to incorporate changes from each meeting.
The candidate extensions were then integrated into a draft standard that was issued for public review. The Public Comment Task Group (PCTG) was formed to respond to the public comments and recommended changes to the draft. To promote a unified response on each comment issue, PCTG included members from both WG2 and JPC. All responses and recommended changes required final approval by JPC and WG2. PCTG recommended several substantive changes that were subsequently approved as changes to the draft. These changes were incorporated and a new draft was produced for a second public review.
The goal of JPC's Project 345 was to define an implementable, internationally acceptable Extended Pascal Standard.
This Standard was to encompass those extenions found to be:
- Compatible with ANSI/IEEE770X3.97-1983, American National Standard Programming Language Pascal, and
- Beneficial with respect to cost.
JPC's approved program of work included:
- Solicitation of proposals for extended language features;
- The critical review of such proposals;
- Synthesis of those features found to be acceptable individually and which are mutually consistent into a working proposed standard;
- Interface with all interested standards bodies, both domestic and international;
- Submission of the working draft to ISO/TC97/SC22/WG2;
- Synthesis and submission of a draft proposal ANS consistent with any international standard developed;
- Review and correction of the dpANS in light of any comment received during Public Comment and/or Trial Use periods.
[Return to Contents]
This FAQ webified by Bill Catambay
| |
|
