Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!xanth!mcnc!rti!bcw
From: bcw@rti.UUCP (Bruce Wright)
Newsgroups: comp.lang.misc
Subject: Re: colon-equal vs equal
Summary: PL/I example is flawed
Message-ID: <2687@rti.UUCP>
Date: 3 Jan 89 03:21:26 GMT
References: <3300001@uxg.cso.uiuc.edu> <3290002@hpctdls.HP.COM> <2567@ficc.uu.net> <1988Dec30.025022.2883@tmsoft.uucp>
Organization: Research Triangle Institute, RTP, NC
Lines: 102

In article <1988Dec30.025022.2883@tmsoft.uucp>, mason@tmsoft.uucp (Dave Mason) writes:
> If you want to flame a language, try PL/I:
> 	if if = then then then = else else else = if;
> (there may be some ';' missing, but this is an otherwise legal statement!)
> The problem is that there aren't any REAL keywords.  The parser must be a zoo!

Actually the statements would be written:

	if if = then then then = else ; else else = if ;

Because of the use of the ";" character, the parser is not nearly as bad as
it looks like at first (though I would be the first to admit that it's a bit
more complex than something like Pascal where all the keywords are reserved).

The motivation for not having reserved words (which PL/I shares with, for 
example, FORTRAN) can be seen very clearly in COBOL, where EVERYTHING is
reserved;  this makes each edition of the standard invalidate TONS of programs
which happened to use words which are now reserved!  The latest edition of
the PL/I standard (ANSI X3.74-1987) uses this feature of the language to add
a case statement (named SELECT in PL/I) which did not exist in earlier
standards (it had been a nonstandard extension in IBM PL/I).  If the language
had had reserved keywords, this would have invalidated existing programs.

There is some argument for not adding new constructs to a language, but
instead designing new language from the ground up when certain design
features show themselves to be useful.  The major problem with this is that
it invalidates even more code than an approach like PL/I or FORTRAN - and
this can impose a major economic burden.  No question that you get a more
elegant language as a result;  but as long as there is such an economic
cost you will see interest in extending existing languages.

> (...and while we're PL/I bashing, how about:
> 	i = 25/3;
> which assigns some WEIRD value like 5 to i because of weird default typing &
> coercion rules!)

Not true.  The value assigned to i will be a FIXED DECIMAL number looking 
something like

	8.33333333333333

where the number of 3's depends on the maximum numeric precision supported
by the implementation.  If i is an integer value of some kind (does not
have any places to the right of the decimal point), this is truncated to
8;  if i is floating point an appropriate approximation is selected.

What you are probably thinking of is the expression:

	i = 25 + 1/3 ;

which on the older PL/I standard required the raising of the FIXEDOVERFLOW
condition!  The problem is that by the PL/I rules for division, the "1/3"
has a higher basic precision than the "25" (in fact it has the maximum
precision supported by the implementation), and it runs out of digits in
a rather counterintuitive way.  The newer standard adjusted the meaning of
the "/" operator to fix this and other problems with "/", at the risk of
some incompatibility with older programs which were not conforming to
standard usage and which relied on encountering such exceptions.

So the situation is not as bad as you make it sound, though it is a bit
odd.  The basic problem is that fixed-point arithmetic (as opposed to
integer and floating point arithmetic) is a fishy operation to begin with;
if you want to see a real crock the designers of Ada got it even worse!

> But there are some 'features' :-) in the language: e.g. substr is a function
> that takes part of a string, and bit is a function that converts an integer
> into a string of bits:
> 	substr(bit(i),6,17) = substr(bit(j),3,17))
> transfers a 17 bit field between part of two integers.  Details may be off,
> as it's been about 5 years since I wrote my one (1) PL/I program (2000 lines!),
> but the principle's right.

Sorry but the principle is not right.  "BIT" cannot be used as a pseudo-
variable (as a target on the left-hand side of an assignment) in standard 
PL/I, though it is possible that the compiler you encountered would allow
it.  It is possible to use "UNSPEC" in a similar context;  the use of this
function/pseudovariable (which converts its argument to its internal format)
automatically makes the program nonportable, and is probably questionable
programming style as well (exception would be in some system programming
applications where this type of escape mechanism might be needed).  C has
similar capabilities for bit manipulation (as does Ada in its verbose way), 
so if that's what you're complaining about you probably should include those
languages as well.

The PL/I definition of arithmetic is unnecessarily complex, but its
definition of strings is one place I think that the designers did reasonably
well.  It's not as powerful as, for example, SNOBOL, but once you become
familiar with the capabilities of PL/I string handling, the FORTRAN/Pascal/C
models, although different from each other, all seem about equally infuriating.

> I think the committee that designed the language
> was on acid most of the time.

Doubtful.  However there is one comment apropos to large languages that I
heard once:

	Algol-68 and PL/I have often been accused of being languages
	which have everything but the kitchen sink included in them.
	The designers of Ada decided to avoid this criticism by including
	the kitchen sink as well.

						Bruce C. Wright