How would you design C's replacement?

J

James Kuyper

Am 05/01/2012 10:21 AM, schrieb Ian Collins:

yes, I know all of that

first, I think that this will not easily convince the C committee

second, this is all useless complication, why the hell they didn't
invent another keyword, something like C usually does "_Auto" if it
must or even more descriptive "_Autotype"?

The purpose of using such reserved names is to avoid breaking existing
code. Since auto is already a keyword, it's not in use as a user-defined
identifier. Since it's current meaning is pointless, it's also almost
completely unused as a keyword, too. Therefore, auto and _Auto would
both be just about equally effective in avoiding breaking existing code.
It changes something that's currently an embarrassment for C, into a
useful keyword. Also, there's a policy governing both the C and C++
committees, to avoid gratuitous differences between the languages;
adopting the same new meaning for auto that C++ has adopted would remove
such a difference.
third, I am probably a rare animal, but I occasionally use that in
macros for which I want to be sure that they end up in function scope

I agree - that's a rare usage. It's not a sufficiently compelling use
case to justify resisting such a change.
 
J

Jens Gustedt

Am 05/01/2012 10:47 AM, schrieb Ian Collins:
Maybe the C++ committee has a more echo-friendly recycling policy! They
definitely have better aesthetic sense.

Admittedly the _Bool things etc are ugly. But there is a good reason
for it and usually they come with a #define in a standard header file
(such as "bool") that makes it easy to hide them behind something that
is more eye-friendly.
I've never come across that use auto before. Care to enlighten me?

there are cases where I declare variables inside a macro and where it
must be guaranteed that such a macro doesn't end up being used in
file scope. I then just make the fact that it is an automatic
variable explicit by prefixing it with 'auto'.
I think you are confusing regular constants with const static members of
classes.

perhaps, these complicated rules for C++ always confused me.

Suppose I'd have the following in a header file

struct toto { unsigned a; };
struct toto const totoZero = { 0 };

Would this result in multiple symbol errors when included in C++ or
not? In C it definitively would.

The way around in C is with defines

#define totoZeroInit { 0 }
#define totoZero (struct toto const)totoZeroInit

or even

#define totoZero (struct toto const)((struct toto const)totoZeroInit)

to have an rvalue. Still you'd have to be sure where to use
totoZeroInit and totoZero.

In what I proposed this would be

register struct toto const totoZero = { 0 };

and this then could be allowed in any context where a "value" of type
struct toto is required.

Jens
 
R

Rui Maciel

Keith said:
If we're trying to come up with something better than #include, I'd
rather create a new mechanism that isn't part of the preprocess, and
doesn't look like it is (#pragma).

For example, this:

#include <stdio.h>

could be replaced by:

import stdio;

This would make all the declarations in the stdio "module" visible; it
would be up to the implementation to determine how to do that. There's
no implication that "import" performs a textual replacement.

There's plenty of precedent for this kind of thing in other languages.

I don't expect (or, probably, even advocate) that a future C standard
will have such a feature, but it's probably part of my own hypothetical
never-to-be-fully-defined C-like language.


That would be nice. Other programming languages, such as Google's Go,
appear to support a package system which looks a bit like that.

http://golang.org/ref/spec#Package_clause


Rui Maciel
 
R

Rui Maciel

Malcolm said:
The issue is that it needs to be accepted as a standard by someone with
the weight to make everyone use it.

Anyone can write typedef float[3] vect3; The hard part is getting everyone
to use the same typedef for their 3d libraries.

Why is it necessary to force everyone to use a specific data structure in
their 3D libraries? It might be convenient in some cases, but convenience
isn't the same as a necessity.


Rui Maciel
 
T

tom st denis

Discussing whether such a language could be considered an high level
assembly language or not would essentially be the same as discussing whether
a particular shade of grey could be considered light or dark grey.

Rui Maciel

I dunno, there are expressions and statements in C that are not
handled by any opcode from any CPU I know of.

Tom
 
R

Rui Maciel

tom said:
I dunno, there are expressions and statements in C that are not
handled by any opcode from any CPU I know of.

The same applies to high level assembly, or assembly code which also
includes macros.


Rui Maciel
 
T

tom st denis

If that was true, and it wasn't in fact possible to get any improvement in
any project intended to fix the shortcomings of a previous one, then
nowadays no programming language would be better than the very first
incantation of Fortran.

The joke [in this context] is a lot of people have claimed to
"improve" C but yet C persists despite them. Sure it's evolved in its
own right over the years but for the most part a program written 30
years ago in portable C is likely to both compile and function
correctly today.

The XKCD joke overall though is that often you'd have many competing
semi-compatible standards for the same thing. Shawn Hargreaves
(author of the Allegro game lib) apparently said this about the VESA/
VBE standards of the 90s. Many vendors implemented "VESA BIOS" but
they weren't necessarily all compatible. Nowadays you see this
manifest in how HTML is pushed. Each vendor has their own inventions
they bring up, some end up in W3 others are just added despite the
process.
 
B

BGB

Full C++ is extremely complex to parse, but the C with classes subset
shouldn't present too many problems (see cfront) and provides a
worthwhile superset of C.

yes, but there is the issue that if "__cplusplus" is defined, a bunch of
C++ related stuff starts piling in from system headers.

this could still be looked into though.
 
T

tom st denis

The same applies to high level assembly, or assembly code which also
includes macros.

Which high level assembler are you using? Things like NASM/YASM/GAS/
etc may have macros but the underlining statements are still opcode
mnemonics.

C can do things like

foo[somefunc(value1,value2)].something[blah?4:1] ^= 19;

Try writing that as a single statement in your "high level assembler."

Tom
 
B

BGB

Discussing whether such a language could be considered an high level
assembly language or not would essentially be the same as discussing whether
a particular shade of grey could be considered light or dark grey.

the problem is that "level of abstraction" is a fairly subjective
measure in general.

a better way of classifying it is not whether it is higher or lower
level, but whether it maps directly to CPU instructions (ASM), or
whether it maps to operations on typed values (languages like C, Java, ...).

at which point there is no longer a fairly direct mapping between
source-code and CPU instructions (either directly via opcodes, or
indirectly via macros or similar), it is no longer ASM.

granted, ASM can also be considered relative to the target, for example,
ASM for JVM bytecode is still an assembler, despite not being for the
underlying HW but rather for a VM running on said HW.


there is also a considerable level of complexity involved in the
conversion between C and ASM (type handling, register allocation, ...),
that typically doesn't exist in a macro-assembler.

....
 
B

Ben Pfaff

Rui Maciel said:
Ben said:
No language is perfect and so anyone assigning the tasks of
fixing "all [C's] problems and shortcomings" is setting an
impossible goal.

That didn't dissuade sompe people from investing their time designing what
they defined as "a better C", and a number of them managed quite well to
succeed in developing good programming languages.

I don't object to improving C, but making it perfect is
impossible.
 
L

lawrence.jones

Ben Pfaff said:
jacob navia said:
Le 30/04/12 20:25, (e-mail address removed) a ??crit :

C is perfect?

No language is perfect and so anyone assigning the tasks of
fixing "all [C's] problems and shortcomings" is setting an
impossible goal.

Exactly.
 
B

BGB

Quite true.

I suspect that the way the C programming language handles "packages" can't
be made any simpler than it already is. The library headers are stored
somewhere (anywhere) in the file system, and so are the object files, if
there are any. Then, to be able to build our software with them, we only
need to configure the compiler to search for those header and object files
where we left them.

I suspect that this is only an issue when automatic build systems make this
to be harder than it is, and needs to be.


well, it is a little nicer on Linux than it is on Windows (especially if
using MSVC), but even then, on Windows headers and libraries are found
via environment variables ("Include" and "LIB" or similar).

MS sets them up via a brain-dead batch-file.

and it is fairly problematic, say, to be able to interface MSVC (or even
Visual Studio) with the DirectX SDK (vs it being more automatic, like
what would be expected from MS).

most applications and libraries, similarly, also tend to have their own
directories for headers, libraries, and binaries (typically installed
somewhere under "C:\Program Files" or "C:\Program Files (x86)", but
sometimes things like "%HOMEPATH%\AppData\..." or similar).

so, typically this may mean things like creating new batch files, which
include other stuff in the various environment variables (such as by
chaining to the old batch files and adding new stuff afterwards).

however, there are merits to the Windows strategy as well.


on Linux, there is another problem:
it is problematic to store libraries somewhere not part of the standard
OS paths. so, it goes to the extreme in the opposite direction.


maybe some sort of "library registry" could make sense, with libraries
registering themselves with the OS or compiler or similar.

maybe, a compiler extension for "do I have X?" could also make sense:
#define MYAPP_USE_GTK _HAS_LIBRARY("gtk")

in addition maybe to something to indicate to link-in libraries from
within headers and source-files:
__use_library__("gtk");


which could (probably) largely eliminate the need for auto-configuration
and manually specifying libraries as command-line options.

other more speculative options are also possible (like if functionality
currently handled by "make" were integrated into the compiler, ...).


hmm (foo_main.c):
<--
#include <stdio.h>

#ifdef _BAR_CC_
__use_file__(
"base/foo_a.c",
"base/foo_b.c",
"base/foo_c.c");

__use_library__(
"somelib1", "somelib2");
....
#endif

int main()
{ ... }
-->

likewise, the compiler could also use and invoke external tools, ...

then, the compiler is invoked something like: "barcc foo_main.c", and
itself proceeds to build the whole rest of the project.


or such...
 
M

Malcolm McLean

בת×ריך ×™×•× ×©×œ×™×©×™, 1 במ××™ 2012 13:44:53 UTC+1, מ×ת Rui Maciel:
Why is it necessary to force everyone to use a specific data structure in
their 3D libraries? It might be convenient in some cases, but convenience
isn't the same as a necessity.
The trivial is important.

One of the great leaps forwards in the industrial revolution was when standard thread sizes were developed. So any nut would fit any bolt. Previously the nuts and bolts have been cut together, so the nut had to match the bolt..

To the artisan, this seems like a fairly trivial advantage. It means he cankeep his nuts in a separate box from his bolts, but it's no real hardship to store them in pairs. When you scale up to factory production, however, it releases something. One man can drive in the bolts, a man twenty places down on the assembly line can place the nuts on the bolts and fix them.

Using standard structures to specify 3d points is like saying that every nut must fit every bolt.
 
L

Lanarcam

Le 29/04/2012 18:17, Rui Maciel a écrit :
If you were given the task to design a replacement for the C programming
language intended to fix all its problems and shortcomings, what would you
propopose?
My responses will probably be OT, they are the result of many years
chasing elusive and costly bugs in the domain of real time embedded
systems. My wish list:

- prevents writing at wrong memory locations by the use of wild
pointers or out of bound array indices.

- erasing of the stack memory resulting in wild jumps.

- prevents mistaking one structure with another by the
use of improper casts.

- overrun of integral types. The language should define
types such as uint32_t, int16_t, etc.

- errors in comparison instructions resulting in an
assignation, if (a = b) instead of if (a == b)

- no dangling pointers after free()
 
B

BartC

Ben Pfaff said:
jacob navia said:
Le 30/04/12 20:25, (e-mail address removed) a écrit :

C is perfect?

No language is perfect and so anyone assigning the tasks of
fixing "all [C's] problems and shortcomings" is setting an
impossible goal.

A perfect language wasn't mentioned. Any new language would have it's own
problems.

However, if you *did* have to devise a new language to be used for the same
kinds of things, would you do everything exactly the same? Assume the
existence of a translator from C to this new language, so you don't have to
worry about compatibility.
 
J

James Kuyper

Ben Pfaff said:
jacob navia said:
Le 30/04/12 20:25, (e-mail address removed) a écrit :
If you were given the task to design a replacement for the C
programming
language intended to fix all its problems and shortcomings, what would
you
propopose?

That the person assigning the task get their head examined. :)

C is perfect?

No language is perfect and so anyone assigning the tasks of
fixing "all [C's] problems and shortcomings" is setting an
impossible goal.

A perfect language wasn't mentioned. Any new language would have it's own
problems.

True: but a language that fixed ALL of "[C's] problems and shortcomings"
would be just about as impossible as one that had no problems or
shortcomings of its own. The best one can hope for is to fix most of the
more important problems and shortcomings, without introducing too many
new ones, and even that would be a daunting task.

More importantly, the problem to be solved is underspecified. What some
people consider to be a problem with C, is precisely what someone else
considers to be a strength of C. Depending upon context, they could both
be right - so the context needs to be specified.
 
K

Keith Thompson

Rui Maciel said:
Discussing whether such a language could be considered an high level
assembly language or not would essentially be the same as discussing whether
a particular shade of grey could be considered light or dark grey.

I disagree. In my opinion (and I'm not 100% certain that this
is standard terminology), the distinction between an assembly
language and a non-assembly language is fairly unambiguous.
As I said upthread, an assembly language program specifies CPU
instructions; a program in a non-assembly language, including C,
specifies run-time behavior.

You can have hybrids, of course. A lot of C compilers support
some kind of inline machine or assembly code. And there could be
assemblers that don't *unambiguously* specify the CPU instructions
to be generated, though I've never used such a thing myself.

But given your description upthread:

| Another issue we might consider is that if we were given the
| task of designing an assembly language which should be able to
| generate code for multiple architectures, I suspect we would end
| up with a language which, in terms of features, wouldn't be much
| different than C's core language.

I don't see how such a language could reasonably be called an assembly
language. In fact, it sounds like you're describing C.

There are other approaches to the same goal. For example, you might
have an assembly-like language that specifies instructions for a
virtual machine, which are then translated into native machine code.
But that's radically different from C, so it's not what you were
describing.
 
K

Keith Thompson

Rui Maciel said:
The same applies to high level assembly, or assembly code which also
includes macros.

Assembly code that uses macros still unambiguously specifies the CPU
instructions to be generated; it just does so indirectly.

I'm not sure what you mean by "high level assembly"; can you cite an
example?
 
K

Keith Thompson

James Kuyper said:
No, it is not that simple. Backwards compatibility is an important goal,
but it's only one of the goals the committee needs to take into
consideration. While auto technically is a C keyword, it is never
needed, and therefore is almost never used; as a practical matter the
only sense in which it is a keyword is that it's not available for use
as a user-defined identifier. As a result, there's essentially no
backwards compatibility issue. What little code there is that currently
does use 'auto' would mostly become easily identified syntax errors
under the proposed new meaning.

As I understand it, C++ introduced a new use for the "auto" keyword
*without* breaking existing uses.

(The new form of "auto" lets you declare an object without explicitly
specifying its type; the type is inferred from the initializer.)

For example:

{
auto int x = 42; /* old-style "auto", useless but legal */
auto y = x; /* new-style "auto" */
}

It's no more problematic than C's habitual re-use of "static".
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,898
Latest member
BlairH7607

Latest Threads

Top