🚀 go-pugleaf

In article <11012@riks.csl.sony.co.jp> diamond@ws.sony.junet (Norman Diamond) writes:
>In article <31036@news.Think.COM> barmar@kulla (Barry Margolin) writes:
>[in PL/I]
>>  Where a C programmer would say
>>"short" we'd say "fixed bin (17)", and "fixed bin (35)" was equivalent to
>>"long".
>Yes, and suddenly some object size grows from <whatever> to <whatever>,
>passing the 2**17 boundary.  That kind of thing takes a lot of searching.

If you compile with size checking enabled during testing you'll find it
easily.

>>The main problem with PL/I precisions in systems programming is that they
>>tended to be machine dependent.
>
>Well, systems programming is always machine dependent.  You deliberately
>choose halfwords and fullwords, so when you convert, you know what to
>convert to what.  I'd say this is the easy case.

Well, it's even more machine dependent than it needs to be.  Unix gets by
without requiring the systems programmer to specify exact precisions most
of the time.  Has Unix been ported to machines with different sizes of
integer types?

>>In applications programming the precisions
>>are more likely to be related to the problem domain rather than to the
>>architecture, so it's probably not as much of a problem.
>I'd say this case is much harder.  Wirth got this one right.

You keep saying this.  Wirth has designed at least two languages; which one
are you talking about?  Pascal and Modula-2 both have range types, which
are very similar to PL/I's precision option.  FIXED BIN (n) is the same as
the range -2^n .. 2^n-1, and FIXED BIN (n) UNSIGNED is like 0 .. 2^n-1.
Yes, the newer languages permit you to specify more specific ranges, but
they're generally implemented the same as the above two classes of types.
You have the same problem with overflow as in PL/I.

What PL/I is really missing is user-defined types.  Some of this can be
done using a preprocessor, and some other cases can be handled using LIKE,
so it's not a major stumbling block (unfortunately, we didn't have a
preprocessor in Multics PL/I, so we only used the LIKE feature).

X3J1 almost proposed some major additions to PL/I a few years ago.  They
were going to standardize a CASE statement, as well as some of the other
glaring omissions from the language (I don't know any details).  But they
ended up just reaffirming the old spec.  There probably wasn't enough new
PL/I compiler development going on.

Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar