Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!snorkelwacker!think!kulla!barmar
From: barmar@kulla (Barry Margolin)
Newsgroups: comp.lang.misc
Subject: Re: PL/I and Reserved Words
Keywords: PL/I keywords
Message-ID: <31036@news.Think.COM>
Date: 25 Oct 89 04:52:34 GMT
References: <2958@usceast.UUCP> <4560@bd.sei.cmu.edu> <465396f5.20b6d@apollo.HP.COM> <6614@ficc.uu.net> <4666d281.20b6d@apollo.HP.COM> <10994@riks.csl.sony.co.jp>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 23

In article <10994@riks.csl.sony.co.jp> diamond@riks. (Norman Diamond) writes:
>  Would you really specify precisions on your integers?
>If so, maintenance will kill you.  This is one of the things Wirth got
>perfectly right.

Hmm, when I was a Multics programmer I always specified precisions, and
didn't notice much effect on maintenance.  Where a C programmer would say
"short" we'd say "fixed bin (17)", and "fixed bin (35)" was equivalent to
"long".  And just plain "fixed bin" is like "int" in that the compiler
chooses the most efficient size (on Multics this was 17, a half word, since
arithmetic can be done without overflowing).

The main problem with PL/I precisions in systems programming is that they
tended to be machine dependent.  Had we ever ported Multics to a 32-bit
machine, we'd have had to do lots of global replacements to convert all the
17's and 35's to 15's and 31's.  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.

Barry Margolin, Thinking Machines Corp.

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