How would you design C's replacement?

[BartC]

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++!

 

[Rui Maciel]

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.

Speaking of missing the point:

You, again, failed to notice that in a significant number of applications,
C++ already replaced C.

And C++ was developed as "a better C".

So, by missing this fact, you failed to notice that a language was already
"set out to replace C", and was quite successful at that. Or do you actually
believe that C++ wasn't successful?

Then, regarding the D programming language.

It D was developed to try to replace C++, not C. In fact, in the overview
section of the official site[1], C++ is mentioned about 50 times in a
section which contains about 250 lines of text.

So, you end up with something like D if you set out to replace C++. That's
extensively covered in D's overview section.

The only thing we can take from D's relative popularity shortcomings is
that, as a replacement for C++, it failed to provide any meaningful benefits
over C++.

But that says nothing about C, doesn't it?

<snip/>


Rui Maciel

[1] http://dlang.org/overview.html

 

[88888 Dihedral]

Bartæ–¼ 2012å¹´5月14日星期一UTC+8上åˆ12時39分09秒寫é“：

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++!

There are p2c and f2c programs available long time ago.
Tiny C is good to be embeded in some risc architectures.
One can't assume that programs in a system with HDs in tera bytes can
work with i-phone or i-pad.

 

[James Kuyper]

On 05/14/2012 11:49 AM, Kenneth Brody wrote:
....

Now, if you were to propose eliminating them from the language (by default,
at least), you still need a way to handle source that contains them. I
would suggest something like:

#pragma STDC TRIGRAPH (ON|OFF)

The default would be "OFF". Any source file that used trigraphs would
simply put:

#pragma STDC TRIGRAPH ON

A platform where trigraphs are actually needed (rare as those might be
nowadays) is likely to be one where "#" is not an available character.
That should be

??=pragma STDC TRIGRAPH ON

 

[Ben Pfaff]

On 05/14/2012 11:49 AM, Kenneth Brody wrote:
...

A platform where trigraphs are actually needed (rare as those might be
nowadays) is likely to be one where "#" is not an available character.
That should be

??=pragma STDC TRIGRAPH ON

But that would only work if trigraphs were already on!

 

[James Kuyper]

But that would only work if trigraphs were already on!

That was my point, but I forgot to make it. One alternative is to create
a special case for source code files whose first three characters are
??=. I don't approve of such special-casing, but it would be feasible.

 

[Ben Pfaff]

That was my point, but I forgot to make it. One alternative is to create
a special case for source code files whose first three characters are
??=. I don't approve of such special-casing, but it would be feasible.

Well, they could use %ragma instead.

 

[Tim Rentsch]

I know ("hope"?) you're writing tongue-in-cheek, but there really is
no "perfect programming language", nor can there be.

THERE ISN'T????? Now things are looking really bad...

 

[Tim Rentsch]

Well, they could use %ragma instead.

Or perhaps more simply, _Pragma

 

[jacob navia]

Le 14/05/12 20:56, Tim Rentsch a écrit :

Or perhaps more simply, _Pragma

Or perhaps they *could* BUY THE CORRECT HARDWARE ?????????

Can anyone point out WHERE exists a computer that

1) Can't understand ASCII
2) Can't have a PC connected to it through the network

And no, 3270 do not count since any mainframe can be accessed from a PC.

 

[Walter Banks]

Or perhaps more simply, _Pragma

It seems like it would be easier to leave them alone.

Next, NEXT reason to change C

Changing a language established over 25 years is very difficult.

w..

 

[Keith Thompson]

That was my point, but I forgot to make it. One alternative is to create
a special case for source code files whose first three characters are
??=. I don't approve of such special-casing, but it would be feasible.

I wouldn't want to require it to be the very first three characters
of the file; it should be able to follow empty lines, whitespace,
and comments. And it probably should apply only to the current file,
not to any #included files.

Any change that disables trigraphs by default will break existing
code that depends on them. Adding a single line to the top of each
affected source file *seems* easy enough, but managing all those
source code changes could be a nightmare.

On the other hand, perhaps the compatibility problem is more
theoretical than real. If, say, C2020 disabled trigraphs by default
(with or without providing a way to enable them), it would only
break code on systems that (a) actually need trigraphs, and (b)
have compilers that are upgraded to support the C2020 standard.
In practice, that may well be the empty set. And there's no reason
a C2020 compiler for such a platform couldn't have an extension
that solves the same problem trigraphs solve. (I'm ignoring code
that deliberately uses trigraphs on systems that don't actually
require them; is there any significant amount of such code outside
test suites?)

One problem with

??=pragma STDC TRIGRAPH ON

and similar suggestions is that they make code that uses them
incompatible with *earlier* versions of the standard. You could
permit

??=if __STDC_VERSION__ >= 202001L
??=pragma STDC TRIGRAPH ON
??=endif

but that's even uglier.

Perhaps a stylized comment could be used to enable trigraphs; if the
first comment in a source file contains, say, "ENABLE TRIGRAPHS",
then trigraphs are enabled.

There are a multitude of possible solutions to the "trigraph
problem". There seem to be exactly zero *clean* solutions, and I'm
beginning to think that the actual magnitude of the problem doesn't
justify any of them. I think we're just going to have to live with
trigraphs -- unless the committee can be persuaded to just remove
them from the language altogether.

 

[Jens Gustedt]

Am 14.05.2012 22:33, schrieb Keith Thompson:

I wouldn't want to require it to be the very first three characters
of the file; it should be able to follow empty lines, whitespace,
and comments. And it probably should apply only to the current file,
not to any #included files.

probably you just missed this elsethread, but there is a reasonable
solution in just using _Pragma, so such exceptional parse rules are
really not necessary.

Jens

 

[BartC]

Tim Rentsch wrote:

It seems like it would be easier to leave them alone.

Next, NEXT reason to change C

That's hardly changing the language. It's barely tinkering with it.

Changing a language established over 25 years is very difficult.

Other long-established languages don't seem to have much of a problem in
keeping with the times (Fortran for example).

 

[James Kuyper]

Am 14.05.2012 22:33, schrieb Keith Thompson:

probably you just missed this elsethread, but there is a reasonable
solution in just using _Pragma, so such exceptional parse rules are
really not necessary.

You responded to a message from Keith, but the only text that you quoted
was written by me, so I assume it was directed at me.

I knew about _Pragma(), but didn't bother thinking about it in this
context, I was concentrating mainly on pointing out the problem with
Kenneth Brody's suggestion. That there are better work-arounds for the
problem is something I should have thought about, and mentioned - but I
didn't.

 

[James Kuyper]

On 05/14/2012 05:37 PM, Robert Wessel wrote:
....

That being said, I think something like the "_pragma trigraphs(on)"
option mooted above would be a perfectly reasonable compromise.

You've got the syntax wrong. _Pragma("string literal") is equivalent to

#pragma string literal

C99 was the first version of the standard to introduce standard-defined
pragmas, and it also established naming conventions which should be
adhered to by any additional pragmas that are proposed. Every standard
pragma has a name which is all capitals, and contains at least two
words, the first of which is "STDC". Those which turn a feature either
on or off do so by simply appending "ON" or "OFF" to the pragma's name.

Therefore, that should be _Pragma("STDC TRIGRAPHS ON")

 

[Walter Banks]

That's hardly changing the language. It's barely tinkering with it.


Other long-established languages don't seem to have much of a problem in
keeping with the times (Fortran for example).

I was joking to a point. This thread (Trigraphs) does demonstrate the
difficulty of making changes. Each simple change has implications ad side
effects

w..

 

[Keith Thompson]

On 05/14/2012 05:37 PM, Robert Wessel wrote:
...

You've got the syntax wrong. _Pragma("string literal") is equivalent to

#pragma string literal

C99 was the first version of the standard to introduce standard-defined
pragmas, and it also established naming conventions which should be
adhered to by any additional pragmas that are proposed. Every standard
pragma has a name which is all capitals, and contains at least two
words, the first of which is "STDC". Those which turn a feature either
on or off do so by simply appending "ON" or "OFF" to the pragma's name.

Therefore, that should be _Pragma("STDC TRIGRAPHS ON")

The standard says:

A unary operator expression of the form:
_Pragma ( string-literal )
is processed as follows:
[snip]

Which implies (I think) that _Pragma(...) may appear only in a context
where an expression is permitted.

In particular, it implies that you can't have a _Pragma as the first line of
a source file.

But the example, showing a way of rewriting a #pragma directive as an
equivalent _Pragma(), doesn't support that interpretation, nor does the
C99 Rationale. The phrase "unary operator expression" is also a bit
odd; the grammatical construct is a "unary-expression".

I'll post to comp.std.c and see if I can get some clarification.

 

[Ben Pfaff]

I was joking to a point. This thread (Trigraphs) does demonstrate the
difficulty of making changes. Each simple change has implications ad side
effects

I think that this thread most effectively demonstrates the
difficulty of removing features.

 

[Tim Rentsch]

Le 14/05/12 20:56, Tim Rentsch a @C3{A9}crit :

Or perhaps they *could* BUY THE CORRECT HARDWARE ?????????

Can anyone point out WHERE exists a computer that

1) Can't understand ASCII
2) Can't have a PC connected to it through the network

And no, 3270 do not count since any mainframe can be accessed from a PC.

I wasn't advocating anything about trigraphs, just
mentioning an alternate way to request a C pragma.