Ada (was: D (was: Quo vadis,

[Frank Heckenbach]

J. David Bryan wrote:

> This raises a point of interest to me.  When GPC development stalled, I had
> to decide whether to continue with GPC as it was, switch to another Pascal 
> compiler, or switch languages.  I have programmed in Pascal for thirty 
> years; it was my fifth language, after BASIC, Algol 60, FORTRAN IV, and 
> SNOBOL, and of those, it is the only one in which I have continued to 
> develop new programs.  This was due primarily to the existance of GPC, and 
> especially its good support for ISO 10206.
> 
> For a number of reasons, I elected to switch to Ada, as implemented by the 
> GNU Ada compiler (GNAT).  I had studied the language shortly after it was 
> introduced in 1983 but did not use it seriously until a GCC version became 
> available.  I found the transition from Pascal to Ada to be quite easy, 
> because many of the implementation concepts are similar.  For several 
> years, I've done all of my new work in Ada instead of Pascal.
> 
> I would think that translating from Pascal to Ada would have some 
> advantages over C++.  For example, Ada inherently supports scalar subrange 
> types and range checking.  I'm not that familiar with C++, but I don't 
> believe that subranges are supported.

No, not directly. However, range-checks are a rather minor issue --
for comparison, it took me a few days to implement them in GPC,
while the object models took weeks or months (I'm not sure exactly
how much work Peter and Waldek spent on them), exceptions
implemented from scratch would take weeks, and templates probably
much longer. So it's these "big things" that matter most. You might
think checked subranges are more important because they're more
fundamental (which they are), but they're just not so difficult to
implement. For the 3 big things I mentioned, I know C++ has them
already. I don't know if Ada does, perhaps you can give us some
information here, e.g., is its object model comparable to those GPC
supports or that of C++; does Ada supported exception handling and
how; does it support something like templates (IOW, how can one
implement, say, a generic list, applicable to any given type, with
strong type-checking).

> Other examples would be nested procedures, packed arrays and records, and
> string slice access, all of which are inherently supported by Ada.

Nested routines are the only serious lack in C++ I see so far.
Packed arrays/records and array slices can be implemented in C++
code with moderate effort (much easier than the current TREE_NODE
implementation in GPC, which is messy and inefficient, as you note
below).

> In short, I would expect that the closer mapping of Pascal to Ada
> constructs would result in a simpler translator than if the target
> language differed more significantly from Pascal.  In many cases,
> the emitted Ada code could be nearly identical to the Pascal code.

I fear this might only be true for more traditional Pascal, while I
stated that I'm particularly interested in more "modern" features
that I know from C++. Of course, if Ada also supports them, it would
make it more interesting.

> GNAT is well supported by AdaCore Technologies, whose large customers 
> (e.g., Boeing, Lockheed) drive compiler improvements and bug fixes back 
> into the GCC code base.  So the compiler is in good shape, and it maintains 
> compatibility with the current GCC release.  (One metric that I considered 
> when switching from GPC to GNAT was that a packed array access that 
> generated about 175 instructions in GPC generated only 15 for the 
> equivalent code in GNAT.)  GNAT is also well-supported by GDB.

I don't doubt any of that, and for manually porting your code, Ada
was probably the better choice than C++ for you, and might be for
many other users.

Kevan Hashemi wrote:

> I agree that a Pascal to C++ translater would be just fine. But on the
> other hand, that means that we need people who enjoy programming in both 
> Pascal and C++ to support the project. Anyone who fits that description 
> is not going to have much use for the product, because they might as 
> well program in C++ in the first place.

That may be the case. So far it looks I might be almost the only
one, and in this case it's probably indeed easiest if I just port my
programs to C++.

> The people who are dedicated to GPC are people who greatly prefer to 
> program in Pascal. Most such people dislike programming in C++.

I'd speculate that most of them actually don't know C++ too well
(neither did I until a few years ago). C has a bad name here, partly
for good reasons, and partly for historical competition. C++ seems
to inherit this bad name mostly because of its similar name, indeed.
Yes, it contains all of C's misfeatures, but as I said before, so
does GPC in the form of "BP extensions". Let's do a quick check
(note: not all of the listed points I consider pure misfeatures,
some of them have their use, though I think they're often overused,
in both languages, when better alternatives are available):

- Untyped pointers: check

- Untyped memory operations (e.g., memory copy, fill): check

- Untyped files: check

- Arbitrary type casts: check

- Hidden type casts by abusing unions (variant records): check

  (Plus hidden type casts by "absolute" variables, a BP misfeature
  that even C doesn't have.)

- Zero-based, manually memory-managed strings with clumsy support
  functions: check ("PChar" and the "Strings" unit)

- Mixup between arrays and pointers: check (if only for "PChar")

- Always-0-based arrays: check ("open array" parameters)

- Unchecked array ranges: check (by turning off range-checking,
  which BP allows locally, and which is sometimes used intentionally
  for "dirty stuff")

- goto: check (even in standard Pascal)

So, yes, one can write dirty C-style programs in C++, but so can one
do in BP and therefore GPC. However, high-level C++ looks quite
different. E.g., there's a string type (which is internally a
template in C++, while it's a compiler built-in in GPC, which is a
difference mostly invisible to the programmer) which similar string
operations as in Pascal (from "+" to "substr" to various find
operations), range-safe and with dynamic memory management (so you
can have strings of unbounded length, which GPC can't do yet -- at
best you can have "^String", but then you have to manage its
allocation yourself).

The C++ object model is a little higher-level than the various
Pascal models (I explained the automatic con-/destructors which are
easier to use and less error-prone than Pascal's explicit calls).

And of course, a simple list (using the STL template) is no
comparison to a hand-made list in Pascal (or a general list abusing
type-casts or other dirty tricks).

The only major drawback I see is the lack of modules.

Of course, the syntax is quite different from Pascal (and quite
similar to C), but for me that's just not an issue -- it just looks
different, and I can't even say GPC's syntax is much cleaner in
total (with all the BP mess mixed in).

> So who is going to write this translator? Not me. Is Frank going
> to write it on his own?

I'd like to, but someone would have to pay my bills for the next
several years. ;-)

> It may be ten times as much work to re-write the compiler in Pascal, but 
> we may find that we have a hundred times as much developer time available.
> 
> One way to proceed is for Frank to estimate how many developer hours are 
> required for a Pascal compiler in Pascal, and for a Pascal to C++
> translator, then we poll the list to see how many hours people are
> prepared to dedicate to each project. If only one of them gets enough
> hours, then we have only one practical solution.

What exactly do you mean by "Pascal compiler in Pascal"? What would
its output be?

John L. Ries wrote:

> The more I think about it, the clearer it is to me that the Pascal to C++
> translator is the option discussed that I like the least.  I actually 
> would prefer a Pascal to Ada translator more than Pascal to C++, because 
> if I had to abandon Pascal, I think I'd be much more comfortable 
> programming in Ada than in C/C++

That's not quite what I was talking about. I meant a converter as a
compiler replacement, i.e. you would write your source in Pascal,
and to build it, convert to C++ and compile it (so C++ is just a
mostly invisible intermediate step, like assembler code is now).

You seem to mean a permanant conversion to another language, so
you'd maintain your code in the new language afterwards. For this
purpose, Ada or Modula-2 might be more suitable for many Pascal
programmers. (For me probably it would probably still be C++, if
only because I know it better now, and such code could integrate
better with my other recently-written C++ code. But for this
purpose, I wouldn't write a complete converter -- it's not worth the
effort -- maybe a small tool for the most boring parts of the
conversion, perhaps just a sed script for some obvious syntax
changes.)

Frank

-- 
Frank Heckenbach, f.heckenbach at fh-soft.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE  D101 CD02 4C9D 0FE0 E5E8