Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!harvard!seismo!brl-tgr!gwyn
From: gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>)
Newsgroups: net.lang.c
Subject: Re: C needs BCD (ANSI People: Please Listen)
Message-ID: <5565@brl-tgr.ARPA>
Date: Thu, 1-Nov-84 23:15:37 EST
Article-I.D.: brl-tgr.5565
Posted: Thu Nov  1 23:15:37 1984
Date-Received: Sat, 3-Nov-84 07:56:56 EST
References: <218@x.UUCP> <163@desint.UUCP> <229bf5db.8e4@apollo.uucp>
Organization: Ballistic Research Lab
Lines: 18

> I think implementing BCD like strings would NOT be a good idea.  People
> who use it will want to use it just like any other type, and I don't think
> that's unreasonable.  It is certainly something that I can see it being
> worth-while to support from the standpoint of spreading the use of C.

The same argument could be made for adding geometric, alegbraic, database,
and other primitive data types to the language.  Since one can invoke
functions (or even use a preprocessor) to extend the language as needed
for different application areas, these facilities are in principle already
supported by C, although not in a standard way across systems unless one
ports his own libraries (which is what I recommend).  It would be nice to
have standard libraries for these things widely available, but people are
getting stingy about sharing their code if it has commercial value.

C, like UNIX, was designed to offer powerful, general access to system
facilities rather than to try to directly address every application area.
Let's keep C a "high-level assembler" and fix its problems without trying
to make it a "rich" language like PL/I or (to some extent) ADA.