Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!brutus.cs.uiuc.edu!wuarchive!wugate!uunet!kddlab!titcca!sragwa!wsgw!socslgw!diamond
From: diamond@csl.sony.co.jp (Norman Diamond)
Newsgroups: comp.lang.misc
Subject: Re: PL/I and Reserved Words
Keywords: PL/I keywords
Message-ID: <11012@riks.csl.sony.co.jp>
Date: 26 Oct 89 02:15:51 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> <31036@news.Think.COM>
Reply-To: diamond@ws.sony.junet (Norman Diamond)
Organization: Sony Computer Science Laboratory Inc., Tokyo, Japan
Lines: 29

In article <31036@news.Think.COM> barmar@kulla (Barry Margolin) writes:

[in PL/I]
>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".

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.

>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.

>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.

-- 
Norman Diamond, Sony Corp. (diamond%ws.sony.junet@uunet.uu.net seems to work)
  Should the preceding opinions be caught or     |  James Bond asked his
  killed, the sender will disavow all knowledge  |  ATT rep for a source
  of their activities or whereabouts.            |  licence to "kill".