As a Deccie (Digital Equipment Corporation), badge 150693,  from 1983 till 1998, I worked for 7 years as software engineer. The computer languages I used ranged from RS-11M PDP-11 assembler, Fortran to VAX/VMS assembler. But the most work was done with the excellent VAX/VMS Pascal compiler and one of the many Digital softwrae products like FMS (Forms Management systems), CMS (Code Management System, a kind of GIT) and many more.

The VAX/VMS Pascal compiler started life, as many Pascal compilers, as one of the P4 descendents, a compiler/interpreter combination. It was Standard Pascal compliant.  But some enhancements later it produced native VMS applications with the standard VAX/VMS calling standard and gained modularity. So it could be linked to the objects produced by any of the wide range of Digital compilers. It came with the standard excellent Digital documentation.

I wrote, with my team, many systems in VAX/VMS Pascal. One of my customers was the largest social security agency, GAK. The product GAKsaus we made for them was an advanced system management system, wrapped around the Digital DCL commandline  utilities such as Backup, disk management etc.

When I was part of the Localization Engineering team I wrote many tools to aid in batch translation. With compiler techniques parsing and string substitution it was possible to do large amounts of automated translation, the tools VAX Translation Tools were used all over the world in DEC engineering.

I want to name two persons that helped me a lot with programming in VAX/VMS Pascal: my local collegue Theo De Klerk and the chief VAX/VMS  Pascal compiler architect John Reagan.
Not only were Theo and I born and raised in the same town,Weesp, I worked with Theo in the Educational Services and later in Software Services.  Theo liked Pascal also and went sofar as writing the definite guide on it: Writing VAX-VMS Applications Using Pascal, published by Digital Press.

How to write high-quality professional applications in PASCAL for the VAX/VMS  This exciting book is the first to actually explain how to write high- quality professional applications on VAX/VMS. With numerous programming examples to illuminate the text, it offers a clear, detailed methodology highlighting those aspects of VMS that every well-written application must address. You’ll find: * Full working program examples throughout, drawn from real-life development situations * A thorough discussion of the VAX calling standard * Detailed discussion of how to use the many VMS system services and Run Time library routines * A practical approach based on actual experience and _written specially from the programmer’s point of view

Being inside DEC, as a member of the Local Engineering staff,  did bring some advantages: easy access to engineering where the software products were developed. I do remember having conversations (via VAX Notes and email, we had very advanced communication and collaboration tools within DEC worldwide) with the main architect, John Reagan.

Interview with a Pascal Architect John Reagan.

Editorial Note by Bill Catambay

A long time proponent of the Pascal programming language, and a big fan of the OpenVMS operating system, I decided it was time to learn what I could from Compaq’s John Reagan, the architect of Compaq Pascal for OpenVMS. John provides some great insight into the art of compiler making which should be of interest to software developers everywhere, regardless of your preferred programming language or platform. The interview was performed via e-mail.

The Interview
Date of Interview: 2-18-00
Interviewee: John Reagan,
Compaq Pascal Compiler Project Leader,
Compaq Computer Corporation
Subject: Compaq Pascal Compiler

Q: Which compilers are you involved with development, and to what degree?
A: I’ve worked only on the Pascal compiler directly. In a consulting role, I’ve worked with the BASIC, COBOL, C, and Fortran compiler groups to some degree. I’m also the current developer for the MACRO-32 compiler that runs on OpenVMS Alpha that converts VAX assembly code into Alpha object files.

Q: How long have you been working on compilers?
A: I started with Digital in 1983 on the Pascal compiler. I was a Pascal user prior to joining Digital and the first task assigned to me was answering a bug report that I had submitted as a Pascal customer. If you look in the “VAX Pascal Bug Reporting Log Book”, I submitted bugs #2, #3, and #4 against the VAX Pascal compiler. I was one of the first serious users of the compiler back in 1981. I became Project Leader in 1985 and have been in that position ever since. During the past 17 years, I have designed and implemented many of the features in the compiler (first as VAX Pascal, then as DEC Pascal, and finally as Compaq Pascal). Most recently, I designed and co-implemented the conditional compilation facility in Compaq Pascal.
At this point in time, I think I have the longest tenure of anybody on any compiler here at Compaq. Nobody else has been on a single compiler for 17 years except me. I also have the distinction that I’ve never moved cubicles in my 17 years!

I have also represented Digital (now Compaq) on the X3J9 Pascal Standards Committee. I am the secretary of the committee and the chairman of the Maintenance Task Group, the subgroup of the committee designated to track and correct problems in the published standards. I contributed many pieces to the Extended Pascal standard and the Object-Oriented Report.

Q: What was your background prior to working on DEC compilers?
A: I graduated from Purdue University with a BS in Computer Science in 1981.
After graduation, I worked for 2 years at the Oak Ridge National Laboratory in Oak Ridge, TN doing computer support for fusion energy research. At Oak Ridge, I was introduced to PDP-8s, PDP-11s, PDP-10s, and VAX hardware as well as RSX, TOPS-10, and VMS. As part of a port of some F77 code from a PDP-11 to a VAX, I asked for permission to rewrite some code from Fortran to Pascal in an attempt to improve the code and diagnose long outstanding problems. Pascal’s strong typing and run-time checking allowed me to find the logic and programming errors in a short time. It was during this time that I was exposed to VAX Pascal and began my long history with Pascal.

While at Oak Ridge, I attended my first DECUS symposium in St. Louis in 1983. I met with the current VAX Pascal project leader to introduce myself and to discuss bugs that I had found. During a conversation, I mentioned that I was interested in compilers and had taken a “traditional” compiler writing course back at Purdue. One thing led to another and in just a few months, I found myself moving from Tennessee to New Hampshire.

Q: Are there any books you recommend for designing compilers?
A: Here are several classics that influenced me as well as a recent book from Bob Morgan that is still available and well done.
Data Structures and Algorithms by Aho, Hopcroft, and Ullman
Algorithms + Data Structures = Programs by Niklaus Wirth (out of print)
Software Defect Removal by Robert Dunn (out of print)
Compiler Construction for Digital Computers by David Gries (out of print)
Building an Optimizing Compiler by Robert Morgan
Very few people come into the world of compilers knowing compilers. Most compiler courses taught in university are “toy” compilers. While useful, they have to be limited to fit within the course timeframe and resources available. “Industrial strength” compilers are much larger and more complicated. For example, Compaq Pascal is comprised of 192 different modules with a total of 457,000 lines (and doesn’t include the common optimizer and code generator for the Alpha machines).

When I interview people to work on compilers, I want to know if they can think and solve problems. A compiler is nothing more than a long sequence of table lookups, tree inserts, sorts, linked-list removals, etc.. It’s these basic techniques, in the right order (that’s the hard part), that make up a compiler.

Q: If you could name the top three issues vital to a successful compiler tool, what would they be?
A: I’ll give 4 since I couldn’t decide which one to throw out!
A test system that’s easy to use and provides good coverage of the compiler’s code. You should invest the time to make sure it does. Our test system has saved us on several occasions from shipping a compiler that would have broken existing programs. That is the #1 rule: don’t break existing programs. Also, make sure that new tests are added to the test system for each bug found/fixed as well as new features.

Code reviews and test reviews. Doing reviews sometimes makes people’s skin crawl. I don’t rely on much formality, but just informal review of code and tests. There have been many times when one of us, while looking at some code, has said “I wonder what would happen if…” It’s these comments that often result in better code and more complete tests.

Good programming skills for defining good interfaces and data structures. Clean and simple interfaces often result in code that is easier to read and easier to debug.

Know when to stop. When designing or implementing any new feature, you have to know when you are complete. We have a saying: “Better is the enemy of done.”

Q: You’ve worked with both the C and Pascal compilers, so can you tell us which builds the more efficient executables, and why?
A: I’ve never actually worked on the C compiler. I know who does and we’ve talked on many occasions.
The strong-typing of Pascal makes is easier for an optimizer to understand the program and provide better generated code. That isn’t to say it can’t be done for C, but it just takes more work. In the early days of OpenVMS Alpha and the previous state of the code generator, it was easy to write Pascal programs that would generate better code than their C equivalents. In the past few years, the C compiler folks down the hall and the optimizer team have worked very hard to get good code from the C programs as well. I’d guess that today the code for both the Pascal and C versions of an algorithm are similar.

The point is that Pascal can produce efficient code and provide the additional benefit of strong-typing and optional run-time checks. You need not switch from Pascal to C just to get performance (at least on Compaq’s OpenVMS or Tru64 UNIX platforms where our compiler runs).

Q: What do you see in the future for Compaq Pascal?
A: To be honest, Pascal has fallen into a niche area. It doesn’t have the flash or cachet of C++ or Java. The Extended Pascal standard (in 1989) and the Object-Oriented Extensions report (in 1993) has provided only minimal benefit to the language. Unless multiple vendors implement any particular standard, it has no real benefit. The Pascal committee hasn’t met for several years.
For people writing new applications, I would still ask them to consider Pascal. There are many reasons why it still might be the best language to use.

I see Compaq Pascal remaining to be a strong compiler with support for new machines, new versions of the operating system, and new versions of the optimizer/code generator. As for new features, we certainly will add as many as we can given the resources we have available. Just let us know what you’d like to see and perhaps we can do it. As for new targets, I personally would like to see Compaq Pascal ported to other targets (such as Windows NT and Windows 2000). However, it takes a critical mass of support to get that to happen. Customer feedback is very important to us.

There are still countless Pascal users in the field and I would like to thank each of them for their support (after all, it pays my salary).