How would you design C's replacement?

Le 11/05/12 17:36, Tim Rentsch a écrit :
> Ben Pfaff<blp@cs.stanford.edu> writes:
>
>> Tim Rentsch<txr@alumni.caltech.edu> writes:
>>
>>> Personally, I don't see why anyone (who doesn't use trigraphs)
>>> would care much one way or the other whether C has them. If
>>> someone is concerned that trigraphs may occur unintentionally
>>> in, eg, strings, it takes all of maybe 30 minutes to write
>>> a tool to scan for them (or less if we can just use grep).
>>> Just run the tool as part of regular compilation, flagging
>>> the "error". Problem solved.
>>
>> If you use GCC, -Wtrigraphs (part of -Wall) solves the problem
>> without even spending those 30 minutes.
>
> Right. In fact I have -Wtrigraphs set in my own standard build
> environment, and it's been there so long I'd forgotten that I did.
> And I presume most other implementations provide a similar option.
> So I guess the suggestion was made just for those unfortunate
> souls whose compiler isn't so equipped.

So, you propose to mask the bug in the language by making all compilers
be non-conformant.


GREAT!

In article <jmhpq75muo4p0s51hasi7hcir3vfk2fshl@4ax.com>,
Robert Wessel <robertwessel2@yahoo.com> wrote:
....
>Either that or the advantages of being a mainstream language compared
>to something as fringe a D are almost always overwhelming, no matter
>what the technical merits are. D might well be the greatest thing
>since sliced bread (or not), but I don't know enough to judge.

Rui completely missed the point, as I've come to expect from him.

But just to make it clear, what I was arguing was that *if* you were going
to set out to replace C, you'd end up with something like D. That it hasn't
happened, tells you something about the wisdom of trying to replace C.

To be clear, the whole point is that D is C without the bugs, while C++ is C
embraced, expanded, enhanced, while keeping (most of) the bugs.

The bugs are what make C C. And, no, I'm not here to argue about what is
and isn't a bug in C - except to say that I do agree with what Walter says
about it on his site (which I haven't read in several years, so don't bother
nitpicking me on specifics). But the one I remember the best is the idea
that there should be no warnings. A construct should either be correct or
wrong (a syntax error); that C has so much stuff that is "warning" level is
(in this view) a bug.

--
"We should always be disposed to believe that which appears to us to be
white is really black, if the hierarchy of the church so decides."

- Saint Ignatius Loyola (1491-1556) Founder of the Jesuit Order -

jacob navia <jacob@spamsink.net> writes:

> Le 11/05/12 17:36, Tim Rentsch a écrit :
>> Ben Pfaff<blp@cs.stanford.edu> writes:
>>
>>> Tim Rentsch<txr@alumni.caltech.edu> writes:
>>>
>>>> Personally, I don't see why anyone (who doesn't use trigraphs)
>>>> would care much one way or the other whether C has them. If
>>>> someone is concerned that trigraphs may occur unintentionally
>>>> in, eg, strings, it takes all of maybe 30 minutes to write
>>>> a tool to scan for them (or less if we can just use grep).
>>>> Just run the tool as part of regular compilation, flagging
>>>> the "error". Problem solved.
>>>
>>> If you use GCC, -Wtrigraphs (part of -Wall) solves the problem
>>> without even spending those 30 minutes.
>>
>> Right. In fact I have -Wtrigraphs set in my own standard build
>> environment, and it's been there so long I'd forgotten that I did.
>> And I presume most other implementations provide a similar option.
>> So I guess the suggestion was made just for those unfortunate
>> souls whose compiler isn't so equipped.
>
> So, you propose to mask the bug in the language by making all compilers
> be non-conformant.

A compiler is allowed to issue a diagnostic for anything it
likes.

Tim Rentsch <txr@alumni.caltech.edu> writes:

> Keith Thompson <kst-u@mib.org> writes:
>> Trigraphs are an effective refutation to the claim that C is perfect.
>>
>> But nobody ever made such a claim, so ...
>
> So it's important to keep trigraphs in C, in case
> someone ever does?

The existence of trigraphs means that no future version of C can
be perfect. If the future version has trigraphs, then it is
marred by their presence. If it does not have trigraphs, then it
falls short of perfection by failing to be backward compatible.

jacob navia <jacob@spamsink.net> writes:

> Le 11/05/12 17:36, Tim Rentsch a @C3{A9}crit :
>> Ben Pfaff<blp@cs.stanford.edu> writes:
>>
>>> Tim Rentsch<txr@alumni.caltech.edu> writes:
>>>
>>>> Personally, I don't see why anyone (who doesn't use trigraphs)
>>>> would care much one way or the other whether C has them. If
>>>> someone is concerned that trigraphs may occur unintentionally
>>>> in, eg, strings, it takes all of maybe 30 minutes to write
>>>> a tool to scan for them (or less if we can just use grep).
>>>> Just run the tool as part of regular compilation, flagging
>>>> the "error". Problem solved.
>>>
>>> If you use GCC, -Wtrigraphs (part of -Wall) solves the problem
>>> without even spending those 30 minutes.
>>
>> Right. In fact I have -Wtrigraphs set in my own standard build
>> environment, and it's been there so long I'd forgotten that I did.
>> And I presume most other implementations provide a similar option.
>> So I guess the suggestion was made just for those unfortunate
>> souls whose compiler isn't so equipped.
>
> So, you propose to mask the bug in the language by making all compilers
> be non-conformant.

Please read my comments again. I didn't propose, nor do I
propose, any such thing. What I did say was that anyone
who is concerned about undesired trigraphs can easily prevent
them while still using compilers that accept trigraphs. I
am not advocating making any changes to any compilers.

> GREAT!

That's sarcasm, isn't it? If you have something to say,
I'd prefer you say it straight out.

Le 11/05/12 18:41, Tim Rentsch a écrit :
.. What I did say was that anyone
> who is concerned about undesired trigraphs can easily prevent
> them while still using compilers that accept trigraphs.

Easily?

Who knows about trigraphs?

How can you knwow that a trigraph in a comment van make for a syntax
error 365 lines later?


int fn(void)
{
for (int i=0; i<100;i++) // is this is correct??/
{
.. 365 lines of code
}
}

This code produces
/tmp $ g++ trigraphs.c
trigraphs.c:4:49: warning: trigraph ??/ ignored, use -trigraphs to enable

So the compiler is non conforming

Most compilers do ignore trigraphs but many don't. You are just saying:

Instead of correcting the bug at the source (the bad specifications)
let's accept a workaround that masks the bug

Tim Rentsch <txr@alumni.caltech.edu> writes:

> Please read my comments again. I didn't propose, nor do I propose,
> any such thing

It's Jacob. What you actually said is pretty much irrelevant.

jacob navia <jacob@spamsink.net> writes:

> /tmp $ g++ trigraphs.c
> trigraphs.c:4:49: warning: trigraph ??/ ignored, use -trigraphs to enable
>
> So the compiler is non conforming

You have to add -trigraphs to run in conforming mode (in that
respect). So?

Le 11/05/12 19:49, Gareth Owen a écrit :
> Tim Rentsch<txr@alumni.caltech.edu> writes:
>
>> Please read my comments again. I didn't propose, nor do I propose,
>> any such thing
>
> It's Jacob. What you actually said is pretty much irrelevant.

You are like that. What I actually said is that it is not the
compiler's task to correct the language.

Mr Rentsch said:

"
What I did say was that anyone
who is concerned about undesired trigraphs can easily prevent
them while still using compilers that accept trigraphs.
"
No, it is not easy (you have to KNOW about trigraphs in the first place)
then it is not the task of compilers to correct the bugs in the
language!

The fact that that option EXISTS is already the proof that the bug in
the language exists.

Le 11/05/12 19:50, Ben Pfaff a écrit :
> jacob navia<jacob@spamsink.net> writes:
>
>> /tmp $ g++ trigraphs.c
>> trigraphs.c:4:49: warning: trigraph ??/ ignored, use -trigraphs to enable
>>
>> So the compiler is non conforming
>
> You have to add -trigraphs to run in conforming mode (in that
> respect). So?

So, it would be better if the bug was corrected at its source: the
badly specified C standard, that specifies those trigraphs!

That is what I am arguing. Mr Rentsch says that it is
"
What I did say was that anyone
who is concerned about undesired trigraphs can easily prevent
them while still using compilers that accept trigraphs.
"
No, it is not easy (you have to KNOW about trigraphs in the first place)
then it is not the task of compilers to correct the bugs in the
language!

The fact that that option EXISTS is already the proof that the bug in
the language exists.

jacob navia <jacob@spamsink.net> writes:

> Le 11/05/12 18:41, Tim Rentsch a @C3{A9}crit :
> . What I did say was that anyone
>> who is concerned about undesired trigraphs can easily prevent
>> them while still using compilers that accept trigraphs.
>
> Easily?
>
> Who knows about trigraphs?
>
> How can you knwow that a trigraph in a comment van make for a syntax
> error 365 lines later?
>
>
> int fn(void)
> {
> for (int i=0; i<100;i++) // is this is correct??/
> {
> .. 365 lines of code
> }
> }
>
> This code produces
> /tmp $ g++ trigraphs.c
> trigraphs.c:4:49: warning: trigraph ??/ ignored, use -trigraphs to enable
>
> So the compiler is non conforming
>
> Most compilers do ignore trigraphs but many don't. [snip]

Again, the scenario you're describing is not what I was
suggesting: 'while still using compilers that accept
trigraphs.' Please try to read more carefully.

jacob navia <jacob@spamsink.net> writes:

> Le 11/05/12 19:49, Gareth Owen a @C3{A9}crit :
>> Tim Rentsch<txr@alumni.caltech.edu> writes:
>>
>>> Please read my comments again. I didn't propose, nor do I propose,
>>> any such thing
>>
>> It's Jacob. What you actually said is pretty much irrelevant.
>
> You are like that. What I actually said is that it is not the
> compiler's task to correct the language.
>
> Mr Rentsch said:
>
> "
> What I did say was that anyone
> who is concerned about undesired trigraphs can easily prevent
> them while still using compilers that accept trigraphs.
> "
> No, it is not easy (you have to KNOW about trigraphs in the first place)
> [snip]

Surely anyone who is concerned about trigraphs already knows
about them. It would be nice if you would respond to what I
actually write, rather than just repeating your "trigraphs
are bad" talking points.

Ben Pfaff <blp@cs.stanford.edu> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>
>> Keith Thompson <kst-u@mib.org> writes:
>>> Trigraphs are an effective refutation to the claim that C is perfect.
>>>
>>> But nobody ever made such a claim, so ...
>>
>> So it's important to keep trigraphs in C, in case
>> someone ever does?
>
> The existence of trigraphs means that no future version of C can
> be perfect. If the future version has trigraphs, then it is
> marred by their presence. If it does not have trigraphs, then it
> falls short of perfection by failing to be backward compatible.

That's true! Now I am forever doomed to be closely familiar
with an imperfect programming language. Oh wait.. maybe
the next revision will change the language so much it
will be completely unrecognizable. So there is still hope...

On Wed, 02 May 2012 12:12:55 -0700, BGB <cr88192@hotmail.com> wrote:

<snip: = versus ==>

> far more common problems are things like:
> mistyping function names;
> messing up the number or types of function arguments;
> accidentally doing bad type conversions;
> ...
>
> in GCC there were options to make the compiler reject the code more
> readily in these cases, but annoyingly MSVC is a bit more prone to let
> it through (usually just giving warnings), without options to turn up
> the strictness.
>
Huh? Every MSVC I've used, back to 1998, had /W<level> and /WX.
Finding the 'official' place in the IDE to set them might be a little
work, but you can always insert manual settings if necessary.

>
> this isn't to say that a person needs Java levels of strictness (where
> every implicit type-conversion is an error, ...), but the compiler being
> like "oh well, whatever" about implicit conversions between pointers and
> integers or similar (or between incompatible pointer types) is probably
> a bit too lax.
>
Java allows essentially the same implicit conversions as C++, allowing
for the minor differences between their primitive type and object
hierarchy, and the major difference in the way arrays work.
It is (mandatorily) stricter about initializing local variables before
they are used -- and always initializing objects and arrays. And
(optionally) more vocal about shadowing, dead stores, and such, than
most C (or C++) compilers I have used -- although C compilers
certainly can and may have such warnings, and some do.

C89 (and later) requires a cast to convert between pointers and
integers, or pointers that aren't to 'nearly' the same type or void.

"Kenny McCormack" <gazelle@shell.xmission.com> wrote in message
news:jojcpt$rao$1@news.xmission.com...
> In article <jmhpq75muo4p0s51hasi7hcir3vfk2fshl@4ax.com>,

> To be clear, the whole point is that D is C without the bugs, while C++ is
> C
> embraced, expanded, enhanced, while keeping (most of) the bugs.

D isn't C without bugs. There's a whole bunch of language enhancements in
there too. It's more of a redesigned C++, so it's a much more complex
language.

Also it deliberately breaks backwards compatibility, and not in minor ways
either (for example, there's no macro preprocessor, so that's 99% of
existing C that don't work even after translating #includes and simple
#defines).

As for why it is not yet mainstream: it if really is that much better, then
those companies that do use it, will have a competitive advantage; they
would probably rather everyone else stuck to C or C++!

--
Bartc