🚀 go-pugleaf

In article <64919@sun.uucp> dgh%dgh@Sun.COM (David Hough) writes:
>I comment in detail upon the following aspects of the proposed standard...

One very important thing to be aware of is that X3J11 intends to get
the proposed standard wrapped up (formally adopted) as soon as possible.
When the third-round comments are reviewed at the September meeting, it
is highly likely that all suggestions for substantive changes to the
proposed standard will be rejected unless they remedy a proven serious
deficiency.  The reason is that any non-editorial change would necessitate
yet another public review, therefore delay in publishing the official
standard.  This process could go on forever, but there is a strong desire
to adopt a "good enough" standard in a timely fashion rather than working
toward a "perfect" standard that is too late to matter.  Many of us feel
that the current draft is "good enough", perhaps modulo editorial nits.

I don't mean to discourage comments on the draft; however, you should be
advised that you'll need some extremely strong arguments for making any
substantive changes.  Examples showing that the current draft is badly
broken would help.

In article <8358@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>I don't mean to discourage comments on the draft; however, you should be
>advised that you'll need some extremely strong arguments for making any
>substantive changes.  Examples showing that the current draft is badly
>broken would help.

The draft may not be 'badly broken' but is missing out on the opportunity
to make C a convenient language for numerical computing as well.  It is a
pity that many of the 'real programmers' feel that any change that would
allow C to be the language of choice for 'non-real programmers'
(scientists) somehow would hurt their feeling/interests. I did not
participate in the debates about the power operator, noalias, conformant
arrays etc., because I was scared by some the vehemence of the 'defender
of the faith'.  It is sad that never seemed to be enough time to discuss
some recommendations in detail. There are many scientist that I know
(mostly younger people) who really came to like C, and we are using it
despite its problems and deficiencies as far as numerical computing is
concerned.

I strongly feel that it is an unacceptable situation that many of us has
to program around these problems, although some of them could be easily
fixed. Much of today's (computational) science is done in a workstation
environment, mostly under Unix. In the future this is going to be even
more so, especially now that the supercomputer manufacturers are adopting
Unix, too. The best compilers in these environments are the C compilers,
period. Since the manufacturer often uses the same compilers for his own
development, the user can be fairly confident that most of the bugs have
already been eliminated. So there will be ever more scientist who program
in C. Why is it such a good idea to have a growing amount of code around
that contains ugly, difficult to understand "fixes"?

The power operator is a small issue, I agree. Noalias (no flames please, I
am afraid of you) is definitely going to come, since the vector machines
need it. Only that it will come in many (vendor specific) colors and
flavors. Conformant arrays?  We (scientists) need them very much and I do
not see how they would mean any grand problem for C --and the end of the
western civilization-- in the simple version proposed by David Hough (see
his "Comments on Proposed ANSI C Standard").

All these problems could be solved, of course, by the inclusion of the
following statement into the Draft:

"Scientist and other non-real programmers are not allowed to use the
programming language C".

(The funny thing is that some scientist would actually like to see this
statement, not only in the Draft, but everywhere).

Joseph D. Reger,	joseph@chromo.ucsc.edu

Why was this announcement posted to comp.lang.fortran?

In article <4566@saturn.ucsc.edu> joseph@chromo.ucsc.edu (Joseph Reger) writes:
>The draft may not be 'badly broken' but is missing out on the opportunity
>to make C a convenient language for numerical computing as well.

I happen to use C for numerical programming, despite occasional flaws
such as those you mention, primarily because it offers much better
support for data structures than do other alternatives such as FORTRAN.
I agree that there are some changes that could make C more convenient
for such applications.  Hough's suggestions are for the most part good
ones, but they haven't been receiving sufficient committee support.

The fundamental problem is that IT IS MUCH TOO LATE to be making
significant changes to the proposed standard.  Look at all the trouble
the last-minute addition of "noalias" caused.  The public review
period is intended as a REVIEW of work done by the committee, not as
an opportunity for language design.  Where were all these scientific
users of C when the design work was being done?  By leaving that up
to people who didn't think the flaws you perceive were significant,
you did not get those flaws addressed in the proposed C standard.
It's easy to complain about other people's work; much easier than
helping with the work.  I suggest that you GET INVOLVED in drafting
the NEXT (revised) standard.

Obviously I am not speaking for X3J11 officially here..

In article <6280@haddock.ima.isc.com> karl@haddock.isc.com (Karl Heuer) writes:
>How about the problem with preprocessing numbers, which seems to break the
>perfectly valid expression "0xe+N"?  Which alternative is the Committee likely
>to take:
>[a] Fix it, call it a substantive change, and go through another round.
>[b] Fix it, but call it an editorial change.
>[c] Leave it alone, and expect implementors to ignore the letter of the
>    Standard in favor of doing what is obviously the right thing.
>[d] Leave it alone, and expect users to not write such expressions.
>[e] Other ?

[c] is out, because we really do intend for conforming implementations to
comply with the specifications.

[b] seems most likely, assuming nobody at the meeting claims that they
really thought the intent was to disallow such expressions.  We usually
consider fixing a failure of the wording to properly express the
committee's intent as "editorial" unless a member objects.

>...  This would seem to preclude
>Common Extension A.6.5.2 in a conforming implementation.

I don't think it is promised anywhere that "common extensions" can
be accomplished in a conforming implementation.  In fact most of
them don't seem possible.  I've never wanted this section in the
Standard..

In article <8358@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
responds to David Hough's article (announcing his pending comments to X3J11).
Doug explains that X3J11's intention to get the proposed standard wrapped up
ASAP, and suggests that anything other than editorial changes are very likely
to be rejected.

Based on the replies I saw to the previous review cycle, I'm concerned that
even editorial comments are too likely to be rejected.  Consider the
the Committee's choice not to replace "mantissa" and "value part" with
"significand".  This editing change would bring the standard in conformance
with both IEEE 754/854 and ANSI/IEEE Std 1084-1986 (the IEEE Standard
Glossary of Mathematics of Computing Terminology).

I am also concerned that substantial mistakes are being made in the area of
floating-point support, despite the good critique provided by David Hough
in the previous review cycle.

I found the responses to David Hough's comments in the last review cycle were
often depressingly mechanical, unbalanced, and to my mind, unreasoned.  I
don't understand how <float.h>, demonstably inadequate, arguably wrong, and
lacking prior art, can be accepted.  Compare this to the decision not to
standardize hypot(), a function which exists on both BSD and SysV systems,
a function the Committee called an "invention of limited utility".  Oddly
enough, the complementary atan2() function is standardized; the Committee
explains atan2() "can be used for purposes other than conversion to polar
coordinates", an argument that actually seems to apply more correctly to
hypot().  I could go on, but Hough's letter and the Committee's responses
say it all much better.

I hope that Doug, and the Committee as a whole, will very carefully read
and consider David Hough's comments in this coming review, and perhaps
supply better considered and self-consistent responses than those that
were provided in the previous review cycle.
--
Jim Valerio	jimv%radix@omepd.intel.com, {verdix,omepd}!radix!jimv

In article <8365@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>In article <4566@saturn.ucsc.edu> joseph@chromo.ucsc.edu (Joseph Reger) writes:
>>The draft may not be 'badly broken' but is missing out on the opportunity
>>to make C a convenient language for numerical computing as well.
>
>
>The fundamental problem is that IT IS MUCH TOO LATE to be making
>significant changes to the proposed standard.

It seemed to me - and I admittedly did not follow it from the very beginning -
that it was always MUCH TOO LATE.

>It's easy to complain about other people's work; much easier than
>helping with the work.  I suggest that you GET INVOLVED in drafting
>the NEXT (revised) standard.

I certainly will.

Joseph Reger, 	joseph@chromo.ucsc.edu

In article <8365@smoke.ARPA>, gwyn@smoke.ARPA (Doug Gwyn ) writes:
> In article <4566@saturn.ucsc.edu> joseph@chromo.ucsc.edu (Joseph Reger) writes:
> >The draft may not be 'badly broken' but is missing out on the opportunity
> >to make C a convenient language for numerical computing as well.
> 
> I happen to use C for numerical programming, despite occasional flaws
> such as those you mention, primarily because it offers much better
> support for data structures than do other alternatives such as FORTRAN.
> I agree that there are some changes that could make C more convenient
> for such applications.  Hough's suggestions are for the most part good
> ones, but they haven't been receiving sufficient committee support.
> 
> The fundamental problem is that IT IS MUCH TOO LATE to be making
> significant changes to the proposed standard.  Look at all the trouble
> the last-minute addition of "noalias" caused.  The public review
> period is intended as a REVIEW of work done by the committee, not as
> an opportunity for language design.  Where were all these scientific
> users of C when the design work was being done?  By leaving that up
> to people who didn't think the flaws you perceive were significant,
> you did not get those flaws addressed in the proposed C standard.
> It's easy to complain about other people's work; much easier than
> helping with the work.  I suggest that you GET INVOLVED in drafting
> the NEXT (revised) standard.
> 
> Obviously I am not speaking for X3J11 officially here..

I use C for numerical programming, and then have to edit the resulting .s
file.  All of the languages, including C, are woefully deficient is letting
the user use the capacities of the machines.  If C is to be a good flexible
language, the committee should widely advertise for complaints about the
deficiencies of the language before starting out.

I would have no trouble coming up with pages of these items.  But the last
time I did something like this, in reply to the open invitation to attend
the meeting on the IEEE floating-point convention, was to receive an invi-
tation to attend!  I do not have the time to attend meetings on software.

Another problem is that the language gurus are unsympathetic to ideas which
run counter to their perception of computing needs.  They see integer 
arithmetic as primarily for addressing and looping; I see integer arithmetic
as important for number-crunching.  What about fixed-point (_not_ integer)
arithmetic?  What about the use of overflow?  What about division with
simultaneous quotient and remainder?  What about an operation or function
returning a string of values?  What about table-driven branches?  What 
about inserting new operators, using the processor syntax to specify the
argument structure of these operators?  In fact, what about using the 
easy-to-use hardware operators on most machines?  A good example is &~,
which is more useful than &, and is hardware on many machines, including
the ones for which C was initially written.  Many of those machines do not
even have a hardware &.

How many useful instructions have disappeared from hardware because they
do not occur in the HLLs?  Multiprecision arithmetic needs unsigned
multiplication and division to be efficient, and not floating point
arithmetic.  The presence of a single hardware instruction can be
essential to an algorithm being worthwhile; if the instruction is in
software, it is more likely to appear in hardware.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)

In article <59@radix> jimv@radix.UUCP (Jim Valerio) writes:
>I found the responses to David Hough's comments in the last review cycle were
>often depressingly mechanical, unbalanced, and to my mind, unreasoned. ...

Little birdies tell me that the review of the second-round public comments
was, in general, awfully rushed.  It shows.
-- 
Intel CPUs are not defective,  |     Henry Spencer at U of Toronto Zoology
they just act that way.        | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

In article <4566@saturn.ucsc.edu> joseph@chromo.ucsc.edu (Joseph Reger) writes:
>The draft may not be 'badly broken' but is missing out on the opportunity
>to make C a convenient language for numerical computing as well...

Well, remember two things.  First, that there was opportunity for input
along these lines earlier, and little was received; it is now much too late
for major changes.  Second, that X3J11's mission was to standardize an
existing language, not to invent a new one; they did make some small steps
toward making C friendlier for numerical work, and that is probably about
all one should expect from a standards committee.

If you really want to see C improved as a language for numerical computing,
the first thing to do is to scream at your compiler supplier until he/she/it
does some of the things you want.  Then, when the time rolls around for the
next revision of the C standard, you can propose changes based on *actual
experience*.  This will carry a lot more weight than untried inventions.
Given the time lags involved in all this, if you are serious about it, the
time to start haranguing your supplier is *now*.
-- 
Intel CPUs are not defective,  |     Henry Spencer at U of Toronto Zoology
they just act that way.        | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

In article <59@radix> jimv@radix.UUCP (Jim Valerio) writes:
>I found the responses to David Hough's comments in the last review cycle were
>often depressingly mechanical, unbalanced, and to my mind, unreasoned.

The "mechanical" aspect may be partly due to the existence of a list of
"stock response codes" that the Committee uses for its convenience in
recording answers to issues raised.  In cases where the proposal was
rejected, there is also supposed to be additional explanation.  As it
happens, sometimes the additional explanation is not provided, or the
one provided makes no sense to the response document editor and reviewers,
so we have to try to provide additional explanation that reflects the
Committee's position as best as we understand it.  I will admit that
less-than-perfect responses are sometimes the result.

Also consider that a full rebuttal to a lengthy paper like Hough's
would take far more work than anyone was prepared to do.

>...  Compare this to the decision not to
>standardize hypot(), a function which exists on both BSD and SysV systems,
>a function the Committee called an "invention of limited utility".  Oddly
>enough, the complementary atan2() function is standardized; the Committee
>explains atan2() "can be used for purposes other than conversion to polar
>coordinates", an argument that actually seems to apply more correctly to
>hypot().

Although I favor standardizing hypot(), I have to say that I almost
never have found occasion to use it, unlike atan2() which is the main
inverse-trig function (if you find yourself using some other inverse-
trig function, odds are you made the wrong choice).

>I hope that Doug, and the Committee as a whole, will very carefully read
>and consider David Hough's comments in this coming review, and perhaps
>supply better considered and self-consistent responses than those that
>were provided in the previous review cycle.

I actually supported many of Hough's suggestions.  Unfortunately, out
of perhaps 30 to 40 voting members of the Committee, fewer than a dozen
have significant experience using C for large-scale floating-point
applications.  This makes it hard to "sell" improvements in this area.
Since the majority have little to gain (and their compiler/library work
would be increased) by making such changes, naturally such proposals
have a hard time obtaining the necessary 2/3 majority vote to be adopted.
In fact, only remedies for really glaring deficiencies have much chance
of gaining such a majority.  And at this stage of the process, any
substantive change has very little chance no matter how nice it might
have been if it had been incorporated in the proposed Standard earlier.

In article <887@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
[wish list for HLLs]

I agree that many of the features wished for ought to be in higher-
level languages.  But to put all of them in C would no longer leave
the relatively small, simple, low-level language that C was designed
to be.

Nearly all of the features that Herman Rubin wishes to see *are*
already in HLLs, only not all are in each HLL.  C++ has some.  Ada has
*many* of them, especially fixed point arithmetic and functions
returning structured values.

The real problem is not with C designers.  The real problem is with
Fortran designers, who have always had an explicit mandate to design a
language for scientific computing, and have continued to fail miserably
to achieve this.  In a way the C users who do numerical computing want
to put on C the burden that Fortran was supposedly designed to carry.

The trouble with doing so is that other users will lose.  Each new
feature added to a language increases the complexity of the language
translator, and *all* users, even those who don't need to use these
features, will pay in money, disk space, and CPU time.
-- 
Rahul Dhesi         UUCP:  <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi

Given:
1. ANSI C (as proposed) does not support numerical computing adequately.
2. There is not enough time to fix it for the current standard.

There are several ways of coping:
1. Use Fortran.
2. Hope your compiler vendor comes up with reasonable extensions.
3. Do something to encourage your compiler vendor to come up with
   something reasonable.

I would favor writing a standard for "correct" math extensions to the C
language.  If the standard is adopted by at least one compiler vendor
(or producer so as to include the FSF) then you can show prior art for
the next round of X3J11.  If the "correct" math extensions are simple
enough to implement then many manufacturers will put it into their
compilers.

A proposal for a standard to be produced by an individual, an
independent committee or a committee from one of the user groups (ACM,
IEEE, /usr/group, Usenix, etc...).  A committee could meet in person
or electronically, etc...

Unfortunately, I lack the skills to produce such a document.
----
Paul Haas,  uunet!actnyc!prh (if that doesn't work: haas@msudoc.egr.msu.edu)

Re the numeric problems: I agree with your assessments.  But since
this is largely a library issue, it is possible to cure the problem
even with implementations that are seriously munged.  This is not
enough of an issue to make further delays in the standard.

There's no reason why a revision of the standard cannot begin almost
immediately.  Clearly the folks who need the numeric changes should
get together, formalize their needs, educate the rest of us on their
necessity, and propose it for the revision.

If we insist on making the changes in the *present* proposed standard,
I think we're looking at major delays.  Let's get the standard out
NOW, and tighten down the libraries later.
-- 
Steve Simmons		...!umix!itivax!vax3!scs
Industrial Technology Institute, Ann Arbor, MI.
"You can't get here from here."

In article <4581@saturn.ucsc.edu> joseph@chromo.ucsc.edu (Joseph Reger) writes:
>It seemed to me - and I admittedly did not follow it from the very beginning -
>that it was always MUCH TOO LATE.

X3J11 has been trying to get the %#@%$% thing out the door for quite some
time now.  The combination of lengthy public-review cycles and official
meetings held only quarterly means that a standard which needs *three*
public-review cycles will be in "almost finished, no substantive changes
without a damn good reason" status for a long time.  Sounds like you came
on the scene after that phase started.
-- 
Intel CPUs are not defective,  |     Henry Spencer at U of Toronto Zoology
they just act that way.        | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

In article <3732@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
>
>The real problem is not with C designers.  The real problem is with
>Fortran designers, who have always had an explicit mandate to design a
>language for scientific computing, and have continued to fail miserably
>to achieve this.  In a way the C users who do numerical computing want
>to put on C the burden that Fortran was supposedly designed to carry.

  The Fortran 8x committee has its problems, but lack of features is
not one of them.  The April '87 Fortran draft standard includes a
number of "modern programming language" features, including something
like structures (referred to as derived types) and modules, with
imports and exports.  The real problem with the Fortran
standardization process is the in ability of the Fortran community to
arrive at a standard.  The decade is almost over.  Soon it will be
Fortran 9x.

                           Ian Kaplan

"I don't know what the most popular numeric programming language will
 look like in the year 2000, but it will be named Fortran."

           These opinions are my own.

Sounds like somebody wants an extensible C.

Are you crazy?

Extensibilty implies the gods are mortal and a rational mode system exists.

Shame for mentioning this is comp.lang.c.

In article <887@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
>...  I do not have the time to attend meetings on software.

In other words, you want it fixed, but you can't be bothered investing your
own time and effort in getting it fixed?  Don't expect much sympathy.
Standards are hard work; if you can't be bothered helping with it, those
who do put in long hours on them are likely to feel that you don't really
care all that much.

> What about fixed-point (_not_ integer) arithmetic?

What about it?  Last time I did something along those lines, there wasn't
any formidable difficulty in implementing it on top of integer arithmetic.
That was a long time ago, and the stuff I was doing was specialized and
simple, mind you.

> What about the use of overflow?

A nice idea, but it's hard to make it portable.

> What about division with simultaneous quotient and remainder?

Already in X3J11 C; see div() and ldiv() in section 4.10.6.  If your
compiler supplier doesn't implement them or implements them inefficiently,
complain to him, not to X3J11 or to the net.

>What about an operation or function returning a string of values?

What about it?  Can be done right now, although a bit clumsily, using
pointers; see scanf for an example.  It's not at all clear that adding it
as an explicit construct would improve efficiency; in fact it could well
reduce it.

>What about table-driven branches?

See the "switch" construct, which has been in C all along.  If your
compiler doesn't do this well, again, complain to the supplier.

>What 
>about inserting new operators, using the processor syntax to specify the
>argument structure of these operators?

Again, perfectly possible now if you're willing to live with distasteful
syntax (function calls).  The past experiments with user control of syntax
have mostly been limited successes at best.

>In fact, what about using the 
>easy-to-use hardware operators on most machines?  A good example is &~,
>which is more useful than &, and is hardware on many machines, including
>the ones for which C was initially written...

And which any sensible compiler on those machines will use if you write
x & ~y, just as you'd expect.  See above comments on compiler defects.

>How many useful instructions have disappeared from hardware because they
>do not occur in the HLLs?

How many useless instructions have appeared in hardware because some clot
had the mistaken idea that they could be useful to HLLs?  Exacting a speed
and cost penalty from the customers as a result of the extra complexity,
too.  Such things are always compromises.
-- 
Intel CPUs are not defective,  |     Henry Spencer at U of Toronto Zoology
they just act that way.        | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

In article <9@argosy.UUCP> ian@argosy.UUCP (Ian L. Kaplan) writes:

>  The Fortran 8x committee has its problems, but lack of features is
>not one of them.  The April '87 Fortran draft standard includes a
>number of "modern programming language" features, including something
>like structures ...

>"I don't know what the most popular numeric programming language will
> look like in the year 2000, but it will be named Fortran."

Deja vu. In 1963 a commitee (Share) got together to produce FORTRAN V. It
had structures, if-then-else, switch statements (spelled 'GOTO
<expression>'), eight types of numeric data, and a whole bunch more.  After
the commitee saw what they had wrought, they decided that it was good.  But
FORTRAN V was a bad name.  So they called the language NPL (New programming
Language).  When the Naval Physics Lab complained, the commitee changed the
name again.  And Voila!  PL/I was born.

   Marv Rubinstein

In article <1290@garth.UUCP> smryan@garth.UUCP (Steven Ryan) writes:
>Sounds like somebody wants an extensible C.

It's been done, it works well, and it's readily available:  C++.
-- 
Intel CPUs are not defective,  |     Henry Spencer at U of Toronto Zoology
they just act that way.        | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

In article <1988Aug26.162706.22671@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes:
> In article <1290@garth.UUCP> smryan@garth.UUCP (Steven Ryan) writes:
> >Sounds like somebody wants an extensible C.
> 
> It's been done, it works well, and it's readily available:  C++.

There are gross weaknesses in C++.  It does not allow the introduction of
new operators, for example.  It does not address the problem of multiword
hardware types, using machine dependencies where they can profitably be
used (see the discussion about short x short -> long), and other such
goodies.  I have used one type when C would assume another type; C++ would
complain.  

Fortunately, the newer C++ compilers do not reduce to C; that gave such
atrocious code that if there was another way it would be preferable.

C++ addresses a few of the weaknesses of C.  However, it ignores the worst
of the problems.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)

In article <197@itivax.UUCP> scs@itivax.UUCP (Steve C. Simmons) writes:
>... Clearly the folks who need the numeric changes should
>get together, formalize their needs, educate the rest of us on their
>necessity, and propose it for the revision.

You forgot a couple of major intermediate steps:  convince some compiler
suppliers to implement the changes, and use them for a while to find out
whether they really do the job.  Many people, including me, will remain
unconvinced that your proposals are reasonable unless you've actually tried
them.  Anyone who's actually tried language design (or library-function
design, which is a specialized subcase of language design) can tell you
that intuition is no substitute for experience.

Yes, this is more work.  There ain't no such thing as a free lunch.
-- 
Intel CPUs are not defective,  |     Henry Spencer at U of Toronto Zoology
they just act that way.        | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

>>Sounds like somebody wants an extensible C.
>
>It's been done, it works well, and it's readily available:  C++.

Some people have been asking for access to machine specific features. C is
good at getting at machine features for one particular machine whether they
exist or not.

Query: Does C++ do the same or does it define its machine independent operators
in terms of specific machine features and give programmers access to the same
mechanism?

(Why bother buying an unavailable book if I can con someone else in to doing
my research for me?)

In article <899@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
>> >Sounds like somebody wants an extensible C.
>> 
>> It's been done, it works well, and it's readily available:  C++.
>
>There are gross weaknesses in C++...

I didn't say it was perfect, I said it worked well.  There is a difference.
Nobody expects a language to keep everybody happy.  (Personally I doubt
that any language would keep Herman Rubin happy.)  C++ is a fairly well-done
and highly usable extensible C.

>It does not allow the introduction of new operators, for example.

There is room for debate about whether dynamic alteration of language
syntax is a good idea.  C++ does provide for new operators, provided that
you are willing to use function-call syntax for them.  Call syntax is
admittedly clumsy for anything complicated, but user-defined syntax is
a real minefield for both users and implementors.

>It does not address the problem of multiword
>hardware types, using machine dependencies where they can profitably be
>used (see the discussion about short x short -> long)...

You mean, the current *implementations* do not provide for this.  There
is no reason why the implementation of a C++ type can't use hardware-
specific extensions when they exist.  The client interface can remain
machine-independent, as it generally should be.
-- 
Intel CPUs are not defective,  |     Henry Spencer at U of Toronto Zoology
they just act that way.        | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

In article <1317@garth.UUCP> smryan@garth.UUCP (Steven Ryan) writes:
>Some people have been asking for access to machine specific features. C is
>good at getting at machine features for one particular machine whether they
>exist or not.
>... Does C++ do the same or does it define its machine independent operators
>in terms of specific machine features and give programmers access to the same
>mechanism?

C++ is essentially a superset of C, so it takes the same approach as C.
In both, there is no reason why a perceptive implementor can't provide
machine-specific hooks for users to use to implement packages which have
machine-independent interfaces.  This works rather better in C++, mind
you, because package interfaces are much nicer in C++.
-- 
Intel CPUs are not defective,  |     Henry Spencer at U of Toronto Zoology
they just act that way.        | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

Mr. Rubin has been an active contributor to comp.lang.c for many
months now.  He has argued his points with great vigor and seems 
genuinely interested in proving his case.  However, it seems to me 
that few people share his concern.  

It seems likely that this debate will continue for a very long time.
While that may not be a bad thing, in and of itself, it isn't as 
satisfying as, say, an implementation of the ideas that Mr. Rubin 
has advanced.

I would like to ask Mr. Rubin what he is doing, outside of posting to
this and other USENET newsgroups, to bolster his position.  Is there
any research and/or design work in progress, or is it just talk.  It is
my feeling that such work would be useful, and that everyone would 
benefit.

Perhaps a good first start would be a carefully considered paper that
presents the fundamental issues Mr. Rubin would like to see addressed.

John Sambrook                        Internet: john@nsr.bioeng.washington.edu
University of Washington RC-05           UUCP: uw-nsr!john
Seattle, Washington  98195               Dial: (206) 548-4386

-- 
John Sambrook                        Internet: john@nsr.bioeng.washington.edu
University of Washington RC-05           UUCP: uw-nsr!john
Seattle, Washington  98195               Dial: (206) 548-4386

>I didn't say it was perfect, I said it worked well.  There is a difference.
>Nobody expects a language to keep everybody happy.  (Personally I doubt
>that any language would keep Herman Rubin happy.)  C++ is a fairly well-done
>and highly usable extensible C.

That's a very nice compliment. Complacency is a sign of death.