Language transitions

[Bob Dietrich]

> 
> Of course this is by no means the only problem with Pascal's I/O.  Other
> major ones include:
>   - no random access
>   - no way to open a file with a specified name from with the program.
> 	reset(input,'foo') is an extension. It is not in the standard.  
>   - no I/O of enumerated types (nor input of Booleans)
>   - the representation of files other than text is not defined.  This
> 	means that you can't write records onto a tape and expect to
> 	read the tape on a different system.
> I have never seen a program that I needed to write that could be written
> in standard Pascal.

General comment: Good article, Charles.

I guess I'm not certain what sorts of programs you need to write, although
having seen (and used) your systems programming extensions to the DEC-10
compiler, I have my suspicions. If, indeed, you want to do very environment-
specific things in "standard" Pascal, and cannot do so, I'm not surprised.
A standard should be implementable on a broad variety machines, and fails if
what it specifies cannot be implemented.  From where I sit (at my micro-
programmable PERQ), I have access to one or more of the following machines,
using Pascal: CDC Cyber, DEC-10, DEC-20, DEC VAX, IBM 3080, Motorola
68000, Intel 8086, National 32000, and a few others. There's more than one OS
available for several of these. However, there's not much either the hardware
or the various OS's agree upon in a consistent manner.

As far as the problems you cite, JPC has approved Candidate Extensions for the
first two items. The second two pose problems of definition and semantics. I/O
of enumerated types has been suggested, but no one has taken the time or effort
to try and define what this really means. It certainly poses additional
problems for error recovery on user input mistakes.

I'm not sure what you mean when you say that the representation of files other
than text is not defined. The closest thing textfiles have defined as far as
representation goes is that they are sequences of characters broken into lines.
Nothing is specified about character set, length of lines, representation of
the line marker, etc., in keeping with the separation of the language from its
implementation. What would you want for any file? Do you want character values
specified as EBCDIC?  ASCII?  Do you want a standard to require files of records
to be aligned on 8-bit boundaries (on a DEC-10/20 with 36-bit words?) ? I feel
I'm not understanding your point. I am very much in favor of portability, but
specifying a language so that it can be implemented on a wide variety of
machine/OS combinations is difficult.

                                              Bob Dietrich
                                              Tektronix, Inc.
                                              (503) 629-1727
{ucb or dec}vax!tektronix!robertd             uucp address
robertd at tektronix                             csnet address
robertd.tektronix at rand-relay                  arpa address