Adapting software to multiple usage patterns

[Keith Thompson]

How many times in this group we are left with interpreting the
obscure wordings of the C standard?

Not to speak about the buffer overflow error in the C standard
in the code of the asctime() function. Not to speak about functions
described in the library that will never be able to have correct
behavior unless they are lucky: YES gets() is in the C standard.

The C standard is an important document, but it is nowhere
near what we could call a coherent formal system, and I do not
think that that was the intent anyway.

What do asctime() and gets() have to do with the question of
whether C is a formal system? You dislike them, fine, so do I.
But asctime() in particular is perhaps the *most* formally defined
entity in the entire standard, since it's required to behave in a
manner consistent with a specific C implementation.

The behavior of a call to asctime() or gets() is undefined in
certain cases. Are you suggesting that a formal system can have
no instances of undefined behavior? (I'm not all that familiar with
formal systems; if that's part of the definition, then there's little
hope for defining *any* real-world language as a formal system.)

The circumstances in which the behavior of a call to asctime() is
undefined can be unambiguously determined by reading its description
in the standard, and two sufficiently careful independent readers
will reach exactly the same conclusion about what those cases are.
That's formal enough for me. Sure, asctime() has its problems,
but a lack of formality isn't one of them.

 

[James Dow Allen]

Really?  You think a loop containing

sum += *(double *)dv->lpVtbl->GetElement(dv,i);

which has an explicit cast, two indirections and a pointer dereference
is as clear as

double mean = accumulate(vec.begin(),vec.end(),0.0) / vec.size();

FWIW, Jacob's form seems clearer to me than Gareth's, if only
because the meaning of the unfamiliar "GetElement" is at least
slightly easier to guess than that of the unfamilar "accumulate".
Also, C lacks ".begin", ".end" and that suits my Spartan taste
fine.

But different people have different tastes, and different learning
methods (e.g. I like maps, but am usually mystified when getting
verbal directions).

Go and ask a newbie programmer who knows neither C or C++ what they
think each bit of code does.

Would his/her opinion be relevant?

James D. Allen

 

[Dennis \(Icarus\)]

Gareth Owen a écrit :

The time is right now, when the C++ people start realizing that
a simpler language is not a mistake but an advantage. Ask any C++
programmer, the complexity of that language is over their heads.

No, it's not.

Dennis

 

[Tim Rentsch]

There's an assumption in there that the two documents define
the same language. Do they?

A very valid question!

In fact, it can not be answered, because to answer it, a
formal meta-system (meta-calculus) would be required that
contains both the >>non-formal<< specification and the
formal specification and then defines the rules for when
they are deemed to >>define the same language<<. [snip elaboration]

The meta-discussion need not be carried out in a formal
system -- it can be just ordinary conversation. In fact
this describes most mathematical proofs; very few proofs
are written in such a precise way that they can be verified
by a computer program. But even in this case, no conclusion
can be reached (ie, and agreed on by all parties) unless the
"informal" description is sufficiently precise so that there
is no question about what it describes -- in other words, so
that it too would be a formal system.

 

[Tim Rentsch]

Just a note in passing that this subset is almost the same as
the subset of "strictly conforming programs." (Trivia question:
how is it different?)

Broadening the comment. There might be a case for defining a
subset of C that is its core. This subset should be supported by
all variations of compilers hosted or non hosted. This set of core
values could be very useful in making the language portable.

The problem with this is that the defined subset (presumably
defined by some sort of formal specification, but let's skip
that for now) either will be too small to be practically
useful or the question of whether a program is in the
subset becomes difficult to answer (and in general is
undecidable). Furthermore, almost all real programs exhibit
some degree of implementation-specific behavior, so any
subset that excludes programs with such behavior will
rule out essentially all programs of interest.

 

[Dik T. Winter]

>
> It does have a bit of a bump, though.

But it is of course named after somebody, as the only part in the standard
library.

 

[Richard Tobin]

Agreed, but that's not camel case.

[/QUOTE]

It does have a bit of a bump, though.

That's just because your display doesn't do a proper uppercase underscore.

-- Richard

 

[Richard Bos]

Broadening the comment. There might be a case for defining a
subset of C that is its core. This subset should be supported by
all variations of compilers hosted or non hosted. This set of core
values could be very useful in making the language portable.

We already have that. It's called "freestanding implementation".

Richard

 

[Richard Bos]

It does have a bit of a bump, though.

It's dromedary-case.

Richard

 

[Richard Bos]

The people using spanners are alive, but spanners don't seem to need to change
much.

Yes, but don't you see that this is wrong? Spanners are outdated and
backwards. What we need is a tool that can tighten nuts _and_ drill
holes _and_ drive in nails _and_ make builders' tea.

It's not that we should do "nothing". It's that this particular thing does
not appeal, for pretty much the same set of reasons we've pointed out all
along.

Also, where it _does_ appeal, it has been done a couple of decades ago.

Richard

 

[Richard Bos]

Gareth Owen a écrit :

Of course. At the end both libraries will have the same speed.
You can buy a Rolls Royce, or you can buy a small car. C is
simpler than C++, easier to learn and to master. C++ is the Rolls,
C is the small car and both go at the same speed in the CPU/RAM
traffic jams.

Sure. But what we're trying (for the N!th time) to tell you is that what
you're doing is like bolting the boot of the Rolls Royce to the rear end
of the Deux Chevaux, even though the ingine cannae pullit, capt'n and
besides, most of us would like to continue to fit our cars into our
less-than-chateau-size garages.

Richard