Home Original page

prePEP: Money data type

John Roth newsgroups at jhrothjr.com
Sat Oct 18 14:55:13 EDT 2003 
"Paul Rubin" <http://phr.cx@NOSPAM.invalid> wrote in message
news:7xy8vixw9n.fsf at ruckus.brouhaha.com...
> "John Roth" <newsgroups at jhrothjr.com> writes:
> > Like I said, you do it your way. That is, write the necessary COBOL
> > code to round it the way you want. Ths is not as easy as it sounds
> > since COBOL is completely lacking in the basic abstraction facilities
> > such as subroutines with parameters within a single Procedure Division.
>
> That's bizarre, is it really done like that in the actual real world?!
> I thought Cobol had built-in arithmetic, like "add gin to vermouth
> giving martini".  Does it have "operator overloading", so that the add
> statement acts differently depending on how you've implemented
> rounding?

It has builtin arithmetic, including its own version of rounding. Operator
overloading? I don't think anyone had ever heard of such a thing in 1958,
and I'm certain that the Navy wouldn't have accepted it if they had; their
concern was to get something out of draftees on a two year enlistment.

If I had to implement an odd rounding policy like: if the last digit is 4 or
greater, round up, then I'd have to do the add into a (not so) temporary
variable, and then follow it with the necessary code to do the round.
In practice, the COBOL coder would do the add into a specified variable,
then invoke (PERFORM) a parameterless subroutine to do the rounding
into another variable, and finally copy (MOVE) that temporary into its
final resting place.

If you've never done COBOL, you have no idea how absolutely clueless
the language is compared to even the most impoverished Algol class language.
It's still around partially because of PHB momentum, but also because
mainline languages have never discovered that fixed length character fields
and precise control of decimal arithmetic are highly beneficial for certain
kinds of applications.

One of the few benefits of static typing is that type declarations can
include
things like precision (part of COBOL and PL/1) and rounding policy (which
is not part of either language.)

This is why money types, like date types[1], aren't standard. There's too
much
variance in how you have to handle the details to admit of standardization
into
a one-size-fits-all solution.

John Roth

[1] Date types are hard to get right, as the new date module in 2.3
demonstrated.
The arbitrary choice of 1AD as the oldest date that could be handled makes
an otherwise admirable piece of work completely useless for my purposes,
and removes what would be a major reason for me to migrate my personal
programs to 2.3.
More information about the Python-list mailing list