SCOUG-Programming Mailing List Archives

<< Previous Message << >> Next Message >>

Date:	Sun, 10 Aug 2003 20:29:09 PDT7
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	< "scoug-programming@scoug.com" > scoug-programming@scoug.com >
Subject:	SCOUG-Programming: Object-Oriented Programming

Content Type: text/plain

"In other words, the compiler implementors got to the
language lawyers and had them insert some 7-point type in
the language specification. So as far as the distinction
between the C "float" and the PL/I "decimal float(5)" --
surprise, there is none on many implimentations! The compiler
writer is free to use the machine's native floating point
representation -- No matter how broken it might be. (Subtle
jab at the S/360 architecture.)

Greg,

That's the beauty about facts: the interpretations that
result. The implementers on got to the language lawyers
after the users laid out the terms of the contract. The
implementers did as they were told. Something entirely
different from C where the implementers dictated their
"tastes" upon the users.

I don't work in floating point. As far as I know the whole
thing works to some IEEE 488(?) industry standard. You,
however, reinforced my point about the deficiencies in "int",
"long", "short", "single", "double", or any other word that
doesn't express either underlying data type (decimal or
binary) or precision. I neglected to mention the 36-bit binary
format of the IBM 7090 series.

Regardless of the importance of radix in your view the real
issue lies in the programmer being able to declare data in a
machine-independent way. If a particular machine did not
support it "natively", the implementers had to write the
software to provide the support the programmer had stated.

Thus an application that "dcl b fixed bin (31);" would port
source code and data to any machine regardless of the
bit-sizes supported by its registers. While 8, 16, 32, 64, and
128 have a certain "harmony" to them in terms of integer
powers of two, as you point out we had machines of 24- and
36-bit as well as 18, 20, and 56.

Standard C that says its 32-bit or "short" for 16, or "long" for
64(?) misses the mark. It doesn't allow for anything else.
Moreover it assumes that it is binary, never decimal. And that
binary variables must always express integer, not real
numbers. So a simple thing like "dcl b fixed bin (20,6);" is
simply not expressible in C. If you wanted to express it in C,
the programmer would have to furnish the logic to do so. If
he had elsewhere "dcl c fixed bin (16, 4);" and wanted to "d =
b + c;", he would have to furnish the logic to do that also. He
wouldn't in PL/I as the users got to the language lawyers
first.

Ultimately it gets down to the mapping between the problem
set and the solution set. Does the problem set dictate the
choices of the solution set? Does the problem set data types
and operators dictate the choices of the solution set? Does
the problem specifier dictate the choices in the solution?

The previous paragraph illustrates the user's desire that the
problem set fixes the terms of the contract. It's a world that
the user uses. He doesn't want to have to change it to suit
software. If he uses fixed decimal arithmetic to run his
business, he doesn't want to see floating point used instead.

The point is that we "PL/I" people, including Bob and Peter,
are not use to having some implementers view of the universe
crimp our style. We therefore consider it important that terms
of the solution set come directly from the problem set.

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"rollin@scoug.com".

=====================================================

Return to [ 10 | August | 2003 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.