sbigham@dukeac.UUCP (Scott Bigham) (11/10/88)
[Line-eater virus infects DoD computers. Film at 11.]
If there's someone out there on the ANSI X3J9 Pascal committee, I've a few
questions (others are welcome to answer, but I figured someone on the
standards committee would be more in a position to know):
-The following lines cause compile-time errors:
procedure joe(fred:array[1..10] of integer);
function alice:^integer;
function harvey:structure; {where structure is a record type}
Granted, all of these can be gotten around with appropriately chosen type
definitions, but, naive programmer that I am, I can't see why they shouldn't
be able to compile as is. Comments?
-What's the official position on passing procedures/functions as formal
parameters or using them as record fields?
-What's the position on variable length strings (ie. what will the "standard"
implementation of such look like)?
-People have complained about lack of good file handling in Pascal. Maybe
I've been biased by VMS Pascal, but I don't see what it's missing.
Anyone care to enlighten me? [As if I had to ask... :-)]
I'd dearly love to hear what's going on in the Pascal committee, so I'll know
what my favorite programming language is going to end up looking like. I
doubt I'm alone, either. Talk to us, X3J9!
sbigham
--
Scott Bigham "The opinions expressed above are
Internet sbigham@dukeac.ac.duke.edu (c) 1988 Hacker Ltd. and cannot be
USENET sbigham@dukeac.UUCP copied or distributed without a
...!mcnc!ecsgate!dukeac!sbigham Darn Good Reason."bobdi@omepd (Bob Dietrich) (11/15/88)
In article <1096@dukeac.UUCP> sbigham@dukeac.UUCP (Scott Bigham) writes: >[Line-eater virus infects DoD computers. Film at 11.] > >If there's someone out there on the ANSI X3J9 Pascal committee, I've a few >questions (others are welcome to answer, but I figured someone on the >standards committee would be more in a position to know): I'll try to answer, but these comments do not represent any official statement or interpretation of the ANSI X3J9/ IEEE Joint Pascal Committee [end of standards Miranada statement]. > >-The following lines cause compile-time errors: > >procedure joe(fred:array[1..10] of integer); > >function alice:^integer; These two examples run afoul of name type compatibility. If you have the following definitions type t1 = array[1..10] of integer; t2 = array[1..10] of integer; t3 = ^ integer; t4 = ^ integer; t1 is not the same type as t2, nor is t3 the same type as t4, even though the pairs have the same structure. A type denoter (which follows the = in a type definition or the : in a variable declaration) always creates a new type distinct from any other type, even if it does not have an explicit name. In your examples, you have created two new types, which are not compatible or assignment compatible with any other types (since they're unique). Therefore, nothing can be created that can be assigned to the parameter or function result (value parameters follow assignment rules). What you've created cannot be used, and was therefore made a violation. At first, name type compatibility may seem less straight-forward than structural compatibility, but as you get more complicated examples, it is much easier to deal with name compatibility > >function harvey:structure; {where structure is a record type} Originally Pascal was defined to only allow simple types and pointers to be returned as function results. This simplifies implementation, since there's only one or two (usually) computer words that need to be reserved for the function result, and the compiler doesn't have to deal with variable-sized return values and their complications. For Extended Pascal, however, utility has won out over implementation cost and your example will be valid. > >Granted, all of these can be gotten around with appropriately chosen type >definitions, but, naive programmer that I am, I can't see why they shouldn't >be able to compile as is. Comments? > >-What's the official position on passing procedures/functions as formal > parameters or using them as record fields? (Not an official position) Procedures and function parameters are legal in the current standard. If your implementation doesn't have them, it's deficient. Procedure variables (i.e., as record fields) were not put into Extended Pascal, although some of us wanted them. > >-What's the position on variable length strings (ie. what will the "standard" > implementation of such look like)? Extended Pascal will offer fixed and variable length strings. The former is upward-compatible with Pascal. Variable length strings have concepts of a maximum length and a current length, and are built on top of the schema (parametric type) concept. The two forms are compatible. There are several string functions, as well as concatenation and selection of a substring. For more details see the draft. > >-People have complained about lack of good file handling in Pascal. Maybe > I've been biased by VMS Pascal, but I don't see what it's missing. > Anyone care to enlighten me? [As if I had to ask... :-)] People will always complain if they cannot simply say "doit" as their program. I don't know what you mean by "good", but Extended Pascal has added direct access file types and a couple of other features. You can associate an index with a file type and then randomly position that file for reading, writing, or updating in place. You can also inquire the current or last position of the file, and whether it is empty. There is a procedure to do updating on a normal file, and to position a file at its end so that it may be appended to. Even more importantly, there are procedures to set and inquire the binding of environment-specific characteristics of a file, such as the external file name. > >I'd dearly love to hear what's going on in the Pascal committee, so I'll know >what my favorite programming language is going to end up looking like. I >doubt I'm alone, either. Talk to us, X3J9! Unfortunately, there's not many people on the committee (maybe only one) that get usenet news. I've been trying to keep people informed, but I'm paid to do other things. There's also been press releases from time to time, as well as articles in SIGPLAN Notices. Certainly we could do more, but it takes effort and time. Any volunteers? As with any standard, you shouldn't take the word of a small number of people. Get a copy for yourself and read it. If you can't afford it, get your department or library to pay. > >Scott Bigham "The opinions expressed above are >Internet sbigham@dukeac.ac.duke.edu (c) 1988 Hacker Ltd. and cannot be >USENET sbigham@dukeac.UUCP copied or distributed without a >...!mcnc!ecsgate!dukeac!sbigham Darn Good Reason." Bob Dietrich Intel Corporation, Hillsboro, Oregon (503) 696-2092 usenet: uunet!littlei!ihf1!bobd or tektronix!tessi!agora!ihf1!bobd or tektronix!ogcvax!omepd!ihf1!bobd or tektronix!psu-cs!omepd!ihf1!bobd
alk@ux.acss.umn.edu (11/17/88)
Where can the ANSI committe standards publications be purchased? My local newsstand rarely seems to carry anything with an X3J# label on it. thanks one and all --utterly, alk.