How would you design C's replacement?

Kenny McCormack wrote:

> 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

Bartæ–¼ 2012å¹´5月14日星期一UTC+8上å�ˆ12時39分09ç§ ’寫é�“：
> "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

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.

On 5/11/2012 2:16 PM, jacob navia wrote:
[... trigraphs ...]
> So, it would be better if the bug was corrected at its source: the
> badly specified C standard, that specifies those trigraphs!
[...]

With all due respect, there's a world of difference between "bug" and "bad
design choice". While some might call the latter "broken as designed", it's
not a "bug".

Note that, years ago, I was "bitten" by trigraphs. I forget the specifics,
but I believe that it was a filename wildcard which contained a valid
trigraph sequence, which wasn't "working". Once I found out what trigraphs
were, I fixed my code, and didn't give them a second thought.


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

at the top, and any conforming compiler would be compelled to enable them.

This might be extended to include some sort of "push/pop" ability, so that
you could wrap trigraph-related code without forcing a particular setting
afterward.

--
Kenneth Brody

On 5/11/2012 10:12 PM, Tim Rentsch wrote:
> Ben Pfaff<blp@cs.stanford.edu> writes:
[...]
>> 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...

I know ("hope"?) you're writing tongue-in-cheek, but there really is no
"perfect programming language", nor can there be. At least, not "perfect"
in everyone's eye, as you'll probably never even get a simple majority of
programmers to agree on what their "perfect" language consists of. (NB:
"DWIM".)

--
Kenneth Brody

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

James Kuyper <jameskuyper@verizon.net> writes:

> 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

But that would only work if trigraphs were already on!

On 05/14/2012 12:50 PM, Ben Pfaff wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
>
>> 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
>
> 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.

James Kuyper <jameskuyper@verizon.net> writes:

> On 05/14/2012 12:50 PM, Ben Pfaff wrote:
>> James Kuyper <jameskuyper@verizon.net> writes:
>>
>>> 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
>>
>> 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.

Well, they could use %ragma instead.

Kenneth Brody <kenbrody@spamcop.net> writes:

> On 5/11/2012 10:12 PM, Tim Rentsch wrote:
>> Ben Pfaff<blp@cs.stanford.edu> writes:
> [...]
>>> 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...
>
> 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...

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

> James Kuyper <jameskuyper@verizon.net> writes:
>
>> On 05/14/2012 12:50 PM, Ben Pfaff wrote:
>>> James Kuyper <jameskuyper@verizon.net> writes:
>>>
>>>> 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
>>>
>>> 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.
>
> Well, they could use %ragma instead.

Or perhaps more simply, _Pragma

Le 14/05/12 20:56, Tim Rentsch a écrit :
>> Well, they could use %ragma instead.
>
> 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.

Tim Rentsch wrote:

> Ben Pfaff <blp@cs.stanford.edu> writes:
>
> > James Kuyper <jameskuyper@verizon.net> writes:
> >
> >> On 05/14/2012 12:50 PM, Ben Pfaff wrote:
> >>> James Kuyper <jameskuyper@verizon.net> writes:
> >>>
> >>>> 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
> >>>
> >>> 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.
> >
> > Well, they could use %ragma instead.
>
> 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..

James Kuyper <jameskuyper@verizon.net> writes:
> On 05/14/2012 12:50 PM, Ben Pfaff wrote:
>> James Kuyper <jameskuyper@verizon.net> writes:
>>
>>> 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
>>
>> 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.

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.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Am 14.05.2012 22:33, schrieb Keith Thompson:
> James Kuyper <jameskuyper@verizon.net> writes:
> 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

"Walter Banks" <walter@bytecraft.com> wrote in message
news:4FB16978.A6E1C5F4@bytecraft.com...

> Tim Rentsch wrote:

>> Or perhaps more simply, _Pragma
>
> 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).

--
Bartc