Path: utzoo!utgpu!water!watmath!clyde!att!alberta!ubc-cs!uw-beaver!cornell!mailrus!uflorida!novavax!proxftl!bill
From: bill@proxftl.UUCP (T. William Wells)
Newsgroups: comp.lang.c
Subject: Re: Third public review of X3J11 C
Message-ID: <642@proxftl.UUCP>
Date: 28 Aug 88 23:01:41 GMT
References: <8365@smoke.ARPA> <225800053@uxe.cso.uiuc.edu> <8374@smoke.ARPA> <509@accelerator.eng.ohio-state.edu> <891@l.cc.purdue.edu> <4203@adobe.COM> <525@accelerator.eng.ohio-state.edu>
Reply-To: bill@proxftl.UUCP (T. William Wells)
Organization: Proximity Technology, Ft. Lauderdale
Lines: 27
Summary:
Expires:
Sender:
Followup-To:
Distribution:
Keywords:

In article <525@accelerator.eng.ohio-state.edu> rob@kaa.eng.ohio-state.edu (Rob Carriere) writes:
: And having done so, you might then find that there is a language that
: does almost everything you want, could do everything you want with
: *only small changes*, and is already better than anything else around.
: Can you blame people for then trying to get these minor changes done?
: I am not talking about anything like a PL/1 syndrome, because I like C
: for its simplicity, and I'd much rather do some work than have the
: language bloated, but there are a couple of minor changes that would
: greatly improve the utility of C in the numerical field.

So, keeping within the Spirit of C :-), what are the *small*
changes that one could make to the dpANS that would make it an
ideal :-) language for numerical computing?  Perhaps if we could
boil down these into a coherent recommendation, we could get them
fixed in some later standard.  Anyone who wants to bat that
around should probably start posting in a new series of messages,
to separate it from these anti-ANSI flames.

: Rob Carriere
: Face it, C is just to damn *_GOOD_* for you systems guys to keep it
: all to yourselves... :-)

Amen to that.

---
Bill
novavax!proxftl!bill